Bootloader UART: NACK to mass erase in extended erase memory command

[loulou1844]

Hello,

We are currently using an homemade software to program our mcu. It has been tested on an STM32L4. While I am using it on an STM32L0 with the same version of the ST bootloader (V3.1). It returns an error during the erase step. The mcu responds with a NACK to a special mass erase command (0xFFFF) after acknowledging the extended memory erase command (0x44). I checked that the command was supported after doing a get (0x00).The communication recorded in hex is attached and commented. Technical details on the environment are given at the end.

The solutions I have already tried:

1.           Page by page erase

The mcu returns an ACK and the page is erased (controlled with stm32CubeProgrammer) This solution is slower and causes compatibility problems in our software because we need to know the size of the flash. Nevertheless, it shows that the memory is not in protected mode.

2.           Activate and deactivate the read protection

This sequence causes the flash to be erased. It is fast but looks more like a hack than a real solution. Also, I would prefer to use the same command for all MCUs with the same bootloader version. If I can't solve this problem, I will probably keep this. Is it recommended? Are there any side effects?

3.          Disable read before erase protection

In case I was wrong and the memory was indeed protected, I tried to unprotect it before sending the extended memory erase command. The result is the same. We get a NACK for the mass erase.

Thank you in advance for your help

Best regards

Louison

Technical details about the environment:

MCU : STM32L052K8U6, bootloader version 3.1

UART info : baud rate 9600, parity even, 8bits , 1 stop bit.

Application note used: AN3155 USART protocol used in the STM32 bootloader

Communication record in hex :

7F /* origin PC : starting frame */
79 /* origin MCU: ACK */
02 FD /* origin PC : get chip id + CRC */
01 XX XX 79 /* origin MCU: chip id + ACK */
00 FF /* origin PC : Get version and cmd */
79 /* origin MCU: ACK */
0B /* origin MCU: number of bytes */
31 /* origin MCU: Bootloader version */
00 01 02 11 21 31 44 63 73 82 92 79 
 /* origin MCU: Available command
 * 0x44 : Extended Erase Memory command
 * is in the list 
 * + ACK */
44 BB /* origin PC : extended erase memory cmd + CRC */
79 /* origin MCU: ACK */
FF FF 00/* origin PC : 0xFFFF = Mass erase + CRC */
1F /* origin MCU: NACK -> ERROR ! */

[Bubbles]

Hello @loulou1844​ ,

setting RDP1 and reverting to RDP0 holds a risk that in case of transient power supply failure the OB could be corrupted. But if you are confident of the PSU, it's actually viable alternative.

I'll try to look into the problem of the mass erase on L052 too.

BR,

Jarda

[Tesla DeLorean]

Dupe

https://community.st.com/s/question/0D53W00001lUw5cSAC/bootloader-uart-nack-to-mass-erase-in-extended-erase-memory-command

Thought I responded to this, perhaps there was another post/user account

Might have to debug/disassemble the boot loader to understand what it objects too.

Does it need a sum? Is 0xFFFF handled the way you expect.

Copy out the ROM, and attach.

[Bubbles]

Hello @loulou1844​ ,

I checked and this device (as well as for example STM32L1 series) do not implement the mass erase in the bootloader. The BL code space was simply too small on this device to fit the mass erase. Sorry.

I admit this should be better documented in AN2606 or other our literature.

I'll suggest that, but actual ME will never fit into the available memory.

Please use the workaround.

BR,

J

[Bubbles]

BTW chapter 4.4 of AN2606 warns about this possibility and suggests exactly what you are doing. Do RDP1 and revert to RDP0.

J

[loulou1844]

Hi,

Thank you both.

I think we have the final answer in AN2606. Doing RDP1 and reverting to RDP0 is not the best solution to keep my software compatible but it still works.

In my case, the power supply is reliable. Nice to have your point of view on this.

Thanks again for your help.

L