RTEMS | grlib/occan: Calculation of Baudrate dividers wrong (#5166)

Jan Sommer (@thesummer) gitlab at rtems.org
Tue Dec 3 08:31:25 UTC 2024



Jan Sommer created an issue: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5166



## Summary

We have a GR712RC and use the *occan* lib for the operation of the CAN core, but had weird results regarding the measured baud rate when calling `occanlib_set_speed`. We used the current RCC from Gaisler and the `rtems-occan` example for testing.

There are 2 errors in the code:

### BRP not correctly calculated

In the data sheet of the GR712RC it states:
![grafik](/uploads/d47f1150b72c68868a5c6ad9caff39e0/grafik.png)

```c
/* calculate scaler */
tmp = ((br->divfactor + tseg) * baud);
sc = (core_hz * 2)/ tmp - core_hz / tmp;
```
Which is the same as `sc = core_hz/ tmp`, so the division by 2 of the core is not correctly calculated.

### BTR1 register values not correct

>From the GR712RC manual the following formulas are given for the TSEG values of the BTR1 register:

![grafik](/uploads/b3ac335f090f39ab51e8d4194bdfe111/grafik.png)

However, `occanlib_set_speed` eventually calls `grlib_canbtrs_calc_timing` which returns the full TSEG values (including the +1).
The subsequent call to `convert_timing_to_btrs` writes these values to the registers without subtracting the +1, resulting in two time segments to many.


## Steps to reproduce

* Call `occanlib_set_speed` (for example use rtems-occan of the RCC as a base).
* Observe the written register values in GRMON
* Measure baud rate on oscilloscope and compare with desired value

## Expected behaviour

Correct baud rate measured.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5166
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20241203/3b854b00/attachment.htm>


More information about the bugs mailing list