Problem with our proprietary bootloader. Interface interrupts may come too quickly while flash pages are being deleted and written.

[Carsten1]

Hi everyone,

I have a problem with our proprietary bootloader on STM32L151, STM32L451 and STM32F303 micros.

I transfer the content of a flash page via any interrupt-controlled interface (CAN, UART, USB etc.). If all the data for a flash page is available, it is deleted and then written with this content. The data of the following flash page is collected further in the background with the help of the interface. Sometimes an interrupt is apparently lost, so that part of the data is lost. I suspect that the erasing and writing of the flash page takes longer than the successive interrupts that display the incoming data fragments. According to the specifications, the microprocessor cannot read from the flash memory when an erase or write action is in progress. This means that the microprocessor cannot process the code of the interrupt service routine that shovels the data fragment onto a RAM buffer.

Is this assumption correct? If so, is there a possible solution to the problem or a workaround?

Thanks and Greetings

Carsten

[BenedictHeyl]

Yes, if you write your new data in sufficiently large chunks, you might lose some data while you are busy writing to Flash.

I would suggest using a synchronous communication protocol. You should acknowledge successful receipt of packages, validate them with a CRC and possibly request retransmission or transmission of the next package whenever your system is ready.

[TDK]

An interrupt will fire at the first chance. If the CPU is blocked due to a flash access, it will fire after the operation is complete. It will not be lost.

[BenedictHeyl]

I agree that the interrupt won't be lost, but depending on the length of the Flash access (for example if a page must be erased) and the transfer speed of the new data, it is very possible that data is overwritten by the time he can react to the interrupt.

Regardless if this is the underlying issue: Not only lost interrupts, but also lost or corrupted data could be remedied with the implementation of some reliable transport mechanisms.

I have two more suggestions on how to improve the issue:

• Don't write the new data on the same Flash page which is used by the code.
• Erase enough Flash pages to save all the new data.

[TDK]

If one is erasing flash pages needed to handle active interrupts, one is doing something very wrong.

[BenedictHeyl]

I'm always happy to learn from someone more experienced, so I'm looking forward to your explanations and suggestions for Carsten.

[alister]

Not familiar with the parts, but assuming their flash is organised as a single bank, your observations sound plausible and you might consider one or more of these options

a. change your design to erase all the sectors before the upload starts

b. change or add a protocol to allow dead time during erase

[Carsten1]

Hello BenedictHeyl, hello alister,

thank you for your suggestions. When we were still using a serial bootloader (i.e. receiving data from a flash page, then deleting and writing the flash page and then requesting next data via handshake) we did not have the problem. So I think alister's suggestion is the most sensible. "b. change or add a protocol to allow dead time during erase". I.e. I have to tell the transmitter that the bootloader is busy. I also came up with this solution with my colleagues. It was important for me that my assumption of the problem was correct.

Thank you for your participation. If the problem has disappeared, I will report at this point ... .

Thanks again and have a good time for you

Carsten