search

tzai / sense2can_code

Code projects for the RF-19 SENSE2CAN inline CAN sensor modules
6 stars 5 forks source link

Clock misconfiguration leading to CAN bit rate being a third of what is should be #1

Open 1mozolacal opened 3 years ago

1mozolacal commented 3 years ago

Clock misconfigure issue

As identified here http://www.electronicsworkshop.eu/SAMC21XplainedPro-CAN-Troubleshooting the samC21 can operate and a clock speed of ⅓ of the normal. This is caused by this line in the conf_clocks.h file:

# define CONF_CLOCK_OSC48M_FREQ_DIV SYSTEM_OSC48M_DIV_3

The fix proposed in the webpage is to change SYSTEM_OSC48M_DIV_3 to SYSTEM_OSC48M_DIV_1. This causes issues for the board for unknown reasons; it fails to finish it’s configuration. Instead we will change the CAN configurations in the conf_can.h file. The documentation http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-42464-SAMC21-CAN-BUS-Firmware_ApplicationNote_AT6493.pdf ; as per the documentation “48MHz / (5 + 1) = 8MHz, and each bit is (3 + 10 + 3) or 16 time quanta which is 8MHz / 16 = 500kHz.”. Now our clock because of the division by 3 is not 48MHz but rather 16MHz. Anaylsising the equation that they provided means that simply changing the NBRP value from a 5 to a 1 should remedy this issue.

**sorry for the poor formatting

tzai commented 3 years ago

Hi Calvin, thanks for raising this issue, it definitely seems that the code in this repo is misconfigured. As you identified, there are 2 possible remedies:

  1. Change system clock frequency to 48MHz
  2. Change the CAN bitrate prescalers (NBRP and DBRP) to account for a system clock frequency of 16MHz

The reason the first one didn't work for you is probably because of the lack of wait states. According to the SAMC21 reference manual, you'd need at least flash 2 wait states at 48MHz to prevent it from locking up. See below: image

The second could also work if you don't need to run at 48MHz (which for any simple DAQ application, you probably don't). Also, note that the CAN peripheral app note and documentation (including the default documentation in this repo) is quite wrong and should not be depended on. I found this thread very helpful for understanding this CAN peripheral.

Feel free to open a pull request to get this resolved!