-1

Good day all

I have been trying to migrate from a STM32F407 to a STM32F746. The issue I ran into was using the ST HAL library to initialise the CAN. The code was generated from MX Cube (4.16).

Using a Nucleo-144 STM32F746, I could get past the initialisation code (MX_CAN1_Init()) during debug (ST-Link), but not on the production system using a uLink Pro in debug. It would time out waiting for the CAN peripheral (MSR INAK bit not being cleared).

The CAN pins were not connected to anything, i.e. left floating.

Flip
  • 881
  • 7
  • 13

1 Answers1

-1

Found a solution.

Apparently if the CAN RXD pin is left floating or pulled low, then initialisation function would time out, unless debugging using the ST-Link on the Nucleo board.

I then used the internal pull-up resistors in GPIO and the problem disappeared. Both systems would pass the initialisation code in run mode or debug.

I don't recall if the STM32F407 had a similar issue.

Flip
  • 881
  • 7
  • 13
  • Usually the CAN Rx pin will be driven to the right idle level by the CAN transceiver. Placing pull resistors with incorrect polarity on those lines will bring down the whole bus (been there done that). It is best not to use any pull resistors at all. – Lundin Nov 24 '16 at 09:53
  • @Lundin Having a pull up resistor should not negatively affect the bus as highs are "recessive". So yes, the CAN transceiver should pull it correctly, however for testing of code, where one does not necessarily have the CAN transceiver wired up, not having a pull up on the RXD pin will cause the CAN module to not initialise. I did mention that I do not have a transceiver connected. – Flip Dec 01 '16 at 12:08
  • If you don't have a CAN transceiver, you are usually running in a "loop back" mode anyhow, where the signal doesn't even leave the MCU. Been ages since I realized that fiddling around with such things during the development stage is just harmful. Better to get a transceiver and another node, like a CAN listener adapter, as early on as possible. There isn't much effort involved in fixing that, compared to debugging peculiar behavior caused by not testing with live conditions. Simulators in general should be avoided, when possible. – Lundin Dec 01 '16 at 12:46
  • But yeah, a pull-up resistor should be fine, although it fills no purpose in the final product. A pull-down resistor however (internal or external), leads to disaster. – Lundin Dec 01 '16 at 12:48
  • @Lundin I was using an oscilloscope to verify the bit timings and that the pins were configured correctly as TXD and RXD. One does not need to connect a transceiver for that, and internal loopback won't help with that. The next step was to test with another CAN node, using a transceiver. As noted, a pulldown will simply lead to an uninitialised peripheral. CAN transceivers, in addition to pulling RX high, go into a high impedance mode if the TXD pin is kept low. – Flip Dec 02 '16 at 08:31