Problems when using CN5 on STLINK-V3SET for CAN communication

[Pjaco.1]

We are trying to bootload an STM32L443CCT device using CAN bootloader.

The documentation for the STLINK V3 details that by using jumper JP7 and CN5 to connect, we should be able to communicate with a device which has been triggered into bootloader mode (by using option bytes only - avoiding having to set or clear any hardware pins to select bootloader). The advantage of this is that we should be able to reprogram devices using the standard CAN interface which each device currently uses, without having to take the device apart to program using JTAG or SWD access.

What we are observing is that the T_CAN_TX and T_CAN_RX lines coming out of CN5 are identical, which means that the difference between the signals is essentially nothing. Observing other CAN messages on our bus from other source, it's clear that the CAN_TX and CAN_RX lines should be approximately inverted, yet we are seeing them the same.

We've resorted to using the CN7 connector where we need to use a CAN transceiver, we do at least get reasonable looking data out of the system when running the Cube Programmer, but it's still failing to trigger the in-built bootloader in the STM32 device.

The bootloader version is 9.1, and it does support CAN, and I know it is in bootloader as I have been able to examine the program counter (in system memory region) and option bytes by connecting to the device using SWD. I am able to revert to normal application running by clearing the nBOOT0_SW bit in the option bytes.

My question is this - has anyone else had problems using CN5 for CAN comms? Especially for bootloader?

[Pjaco.1 · Accepted solution]

I should add that reverting to normal operation is achieved by setting the nBoot0_SW bit in the option bytes, not clearing it. My error in previous text. When I apply this modified value it reports "option bytes updated successfully" and resetting results in running of the application rather than the bootloader.

[mskumar_mtech]

Hello

We have developed a CAN based custom Bootloader and we would like to flash the application software using STM32CubeProgrammer and STLINK-V3SET. We have provided 3.3V Supply, ground to STLINK_V3SET module and connected CAN_Tx and CAN_Rx through a CAN transceiver board. Jumper J7 is closed as well. STLINK-V3SET module is detected by the STM32CubeProgrammer when powered and connected through microUSB cable. Selected the STLINK-V3SET module and enabled the CAN interface option with default values. We pressed the connect button, we are getting the following timeout error.

Now we have replaced the STLINK-V3SET with a NUCLEO board (STM32L432). Implemented software and started sending all CAN commands and we could see the positive response from our Custom Bootloader for our CAN commands sent from Nucleo board. Here is the copy of all commands and their responses for your ready reference.

Finally we have concluded that our test set-up is all good including the Transceiver and all hardware connections except STLINK-V3SET, There is something not good in STLINK-V3SET (jumper connections or wiring or firmware in STLINK-V3SET).

Please let me know, if we have any options to fix this issue.

[Zeeshan3154]

Hello Pjaco.1!

Will you please tell me that which CAN transceiver you used?

The ST-Link V3 works fine with CAN Bootloader using direct connections but just as I connect it with CAN tranceivers (one with STlink and one with STM32f4), it does not do anything and a "timeout" error is encountered.

If I remove the connection between RX pin of ST-Link and that of CAN transceiver, I am able to see messages but as I am unable to send any it is just a spectator situation rather than bootloading!

So, by using CAN Transceiver, are you able to send messages to ST-Link and ST-Link acts like it received them? If yes then how please?