cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H735G-DK, cannot get response from CANFD ROM bootloader

anotherandrew
Senior

I have an STM32H735G-DK and a sample CAN application that is working fine.  I am now trying to use the CANFD ROM bootloader in system memory but cannot get any response from it. All the jumpers and solder bridges on the DK are at their default configuration.

I have a Waveshare dual CANFD hat for a raspberry pi connected to the FDCAN1 pins (CN18). My test application works great with this setup, I can send and receive both CAN and CANFD messages all day long without issue. I am absolutely confident that there is no hardware issue at play here because the same hardware with my CAN application running in Flash works. Tested with bitrates from 125k to 1M, and CANFD data switching to 4M.

I have set the boot switch (SW1) from the normal "0 - Flash" to "1 - SYS MEM", and looking at both AN2606 as well as AN5405, it looks like I should be able to set the CAN bitrate to 500kbps and issue a standard CAN message with ID=0x0 to get a response (Section 3.1 in AN5405).

I do note that Section 2 states that Filter ID1 is 0x111 and also see Note 2 at the bottom of page 3 says that the MessageID and FilterID1 must match exactly, but even then I get no response from the ROM bootloader. I have tried different bit rates, standard CAN vs FDCAN frames, standard vs extended CAN IDs, different DLCs... I cannot get this to work. The raspberry pi is not seeing the message acknowledged, leading me to think that there is a missing step somewhere in the hardware initialization of the FDCAN1 peripheral, but since this is all in the system ROM from ST and my Flash is blank... that would be odd.

I have also noticed that AN5405 seems to be missing the "synchronization" section that the older (standard CAN) app note AN3154 has, where it says I should be sending CAN ID 0x079 with any DLC until I get an ACK response, but that also does not work.

I do not have any other hardware connected to the DK, so I am quite sure that the ROM bootloader is not accidentally triggering on the UART or SPI or USB bootloaders.

Does anyone have a *verified* setup, synchronization and communication example with the FDCAN bootloader in the system ROM of this device?

1 ACCEPTED SOLUTION

Accepted Solutions
torwier
Associate

Same problem on NUCLEO-H563ZI.

ROM Bootloader is accessable via UART and is able to download images.

Setup host according to AN5405 FDCAN settings:

 

ip link set can0 type can bitrate 250000 sample-point 0.75 sjw 16 dbitrate 1000000 dsample-point 0.75 dsjw 4 fd on berr-reporting on

 

 On sending request:

 

cansend can0 000##0

 

 the following error shows up:

 

ip  -details link show can0
9: can0: <NOARP,UP,LOWER_UP> mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/can  promiscuity 0 
    can <BERR-REPORTING,FD> state ERROR-PASSIVE (berr-counter tx 128 rx 0) restart-ms 0 
	  bitrate 250000 sample-point 0.750 
	  tq 12 prop-seg 119 phase-seg1 120 phase-seg2 80 sjw 16
	  pcan: tseg1 1..256 tseg2 1..128 sjw 1..128 brp 1..1024 brp-inc 1
	  dbitrate 1000000 dsample-point 0.750 
	  dtq 25 dprop-seg 14 dphase-seg1 15 dphase-seg2 10 dsjw 4
	  pcan: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..1024 dbrp-inc 1
	  clock 80000000numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 

 

 Thank you very much for hints and support.

View solution in original post

6 REPLIES 6
torwier
Associate

Same problem on NUCLEO-H563ZI.

ROM Bootloader is accessable via UART and is able to download images.

Setup host according to AN5405 FDCAN settings:

 

ip link set can0 type can bitrate 250000 sample-point 0.75 sjw 16 dbitrate 1000000 dsample-point 0.75 dsjw 4 fd on berr-reporting on

 

 On sending request:

 

cansend can0 000##0

 

 the following error shows up:

 

ip  -details link show can0
9: can0: <NOARP,UP,LOWER_UP> mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/can  promiscuity 0 
    can <BERR-REPORTING,FD> state ERROR-PASSIVE (berr-counter tx 128 rx 0) restart-ms 0 
	  bitrate 250000 sample-point 0.750 
	  tq 12 prop-seg 119 phase-seg1 120 phase-seg2 80 sjw 16
	  pcan: tseg1 1..256 tseg2 1..128 sjw 1..128 brp 1..1024 brp-inc 1
	  dbitrate 1000000 dsample-point 0.750 
	  dtq 25 dprop-seg 14 dphase-seg1 15 dphase-seg2 10 dsjw 4
	  pcan: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..1024 dbrp-inc 1
	  clock 80000000numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 

 

 Thank you very much for hints and support.

Hi,

Check the following:
In order to have the FDCan2 available on the Nucleo board STM32H563 on the corresponding connector strips, the bridges SB29 and SB12 must be removed.
This is described in document UM3115.

 

jherrmann1_0-1698680857112.png

My anwser of get Command.

jherrmann1_1-1698681117095.png

I hope this helps.

torwier
Associate

Thank you so much. This worked for me, although it might not solve the top post here.

razielGDN91
Associate

@anotherandrew I have the same problem than you with STM32h735G-DK board. I tried to check if some hardware is interfering, to access the bootloader. I try to use another bootloader source like I2C or USART but only STlink/virtualCOM and  USB OTG FS are available without share PINes with another hardware (audio, lcd, ethernet).

To use USB OTG and USART with the bootloader first I changed optional bits BOOT_ADD0(optionbyte) = 0x1FF0 and BOOT_ADD1(optionbyte) = 0x1FF0. I am still working in a solution for this issue. I hope that headache don't breaks me before!!! 

Regards, If you found a solution, share it with us.

 

anotherandrew
Senior

I have finally achieved success.

# configure the CANFD driver on Linux:
sudo ip link set can0 up type can bitrate 250000 sample-point 0.75 sjw 16 dbitrate 1000000 dsample-point 0.75 dsjw 4 fd on

# monitor the CAN bus (in a different window/tab):
candump -tdex can0

# send a standard (11-bit) CANFD frame with BRS set, ID=000 and a 64-byte payload:
cansend can0 000##100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

# it is important to note in the command above the double-hash (##) which tells cansend that this
# will be a CANFD packet, and then the single '1' before the 64-byte payload which sets the Bit
# Rate Switch (BRS) switch in the outgoing packet.

# observe the CAN traffic in the candump window:
(179.707038) can0 000 [64] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
(000.001531) can0 000 [01] 79
(000.000025) can0 000 [01] 0B
(000.000009) can0 000 [01] 11
(000.000009) can0 000 [01] 00
(000.000007) can0 000 [01] 01
(000.000008) can0 000 [01] 02
(000.000008) can0 000 [01] 11
(000.000008) can0 000 [01] 21
(000.000008) can0 000 [01] 31
(000.000999) can0 000 [01] 44
(000.000012) can0 000 [01] 63
(000.000006) can0 000 [01] 73
(000.000005) can0 000 [01] 82
(000.000006) can0 000 [01] 92
(000.000006) can0 000 [01] 79

I can issue various commands, including the ID=0 but with no payload at all and get the expected response.

My CAN network is a little more complicated; I have the STM32H7 of course, a Waveshare "dual CANFD hat" connected to a raspberry pi 4 (where I am executing the commands above), and two CAN (not CAN-FD) monitors for other equipment. The network is terminated with 120R on the ends of the network.

I accidentally accepted your answer, but in hindsight that is fine.

I think your error is that you are sending a CAN FD frame with BRS (Bit Rate Switch) cleared. If you use 

cansend can0 000##1

I think you will have more success. Please see my other comment in this thread; I am communicating with the bootloader now. I have not tried without it yet, but I suspect your specific sample point/sample jump is important.