STM32F407 bootloader realibility issues

[Marco Bertoncin]

Posted on April 22, 2017 at 18:52

Hi all,

At my company we have an STM32F407 MCU and we are trying to use the in-built boot-loader. I have read

 - AN2606 - STM32 microcontroller system memory boot mode and

 - AN3154 - CAN protocol used in the STM32 bootloader

The boot loader version that is reported by the Get command is 2.0 (byte 0x20?).

I am trying to find a reliable but fast way to readout and program images to the in built FLASH.

I thought that synchronising with the ACK from the device (0x79) each time this is required by the protocol would have been enough, but it seems that if commands are sent 'too quickly' (even after having waited for the ACK) will cause the bootloader to get into an inconsistent state (I have currently it continuously sending the NACK byte, 0x1F even though nothing is sending to it). This happened if, for example, a read command (0x11) is sent straight after having read the ACK (0x79) from the last group of 8 bytes from the previous read command. I have seen that inserting a 1sec delay before 'starting' the next read makes the process more reliable, but I do not want to hunt for the 'right' delay.

Question 1: is there a requirement for the delay between commands (a part from waiting for the ACK)?

Question 2: is there a way to 'reset' the program, a part from unplugging / plugging back the power cable?

Thanks

Marco

#stm32f407bootloader

[Tesla DeLorean]

Posted on April 23, 2017 at 19:01

Device has a reset pin, can't you use that?

Not sure there is a lot of use of the CAN loader by forum members, but you might get lucky.

Do you have an appropriate HSE crystal? Does CAN behave robustly in normal use, with your own code?

The loader my have different bit sampling points/settings. FLASH is slow, erase especially so, you'd likely want to review the interactions on an analyzer.

You can download your own loader into RAM using the System Loader, and then transfer control to that. If you have serial connectivity you can output debugging/telemetry data from that to better understand that is going on.

[Marco Bertoncin]

Posted on April 24, 2017 at 08:49

Thanks Clive,

I will check about the HSE now.

I do not know about CAN with our own code yet as this project has only just started.

Marco

[Marco Bertoncin]

Posted on May 12, 2017 at 13:15

Nearly forgot this thread ...

For those interested, I have managed to get the bootloader working with CAN bus (50% of the times ...).

The only issue is that it does no always work ... It seems like it is unreliable. I now see all the ACKs and abort if an ACK is missing. Unfortunately, about 50% of the times it terminates 'successfully', but the image does not work (the other 50% it does ...) and if I read out the image from FLASH, using the bootloader, I can see that there are some differences in the binary produced with respect to the binary I have flashed. Not much, maybe 20 bytes in the middle of the image (but not always in the same place ...). Which makes me wonder whether I should really implement a 'verify': I currently just flash, assuming that an ACK means 'all went well'.

Still no one with CAN bus bootloader experience?

Regards

Marco

[Jeroen3]

Posted on May 17, 2017 at 12:43

I wrote my own CAN bootloader once and most programming problems occurred due to cheap implementation of the PC to CAN hardware. I've since then bought Kvaser, which does not use USB CDC, and programming has never failed again.

With a bootloader it's very easy to overrun the buffer of the the virtual serial port all those modules use. Both ways.

[Marco Bertoncin]

Posted on May 18, 2017 at 11:43

Thanks Jeroen3,

It is comforting to know the flashing is reliable...

I will implement a verify.

Marco