Skip to main content
Associate
July 30, 2025
Solved

Issue with Extended Erase Command on STM32WB55RG via USART1

  • July 30, 2025
  • 4 replies
  • 406 views

Hi support, 

I’m currently working with a Nucleo-WB55RG board, and my goal is to perform a firmware update using an ESP32 as the host. The ESP32 is connected to the STM32 via USART1 (PA9 and PA10).

The sequence followed is : 
1. Connect to the bootloader
2. Test the link with Get command
3. Erase memory (mass erase)
4. Write binary + read for checking data
5. Go 

I’m encountering an issue when sending the Extended Erase command to the bootloader (3. Erase memory). I followed the documentation closely for both the hardware and protocol, as described in AN2606 (pattern 16) and AN3155.

 

Here is my manipulations :
=====================
First step : activation and synchronization with the bootloader :
0x7F sent
0x79 received 

Then, Get command to check supported commands on the chip. Those are following : 

0x00, 0x01, 0x02, 0x11, 0x21, 0x31, 0x44, 0x63, 0x73, 0x82, 0x92.
-> So, this confirm that the uart interface and hardware setup are working correctly . 

When I send the erase command (Extended erase), the special command to erase all the flash memory : 
0x44 0xBB sent 
0x79 received 
0xFF 0xFF 0x00 sent 
No response from the bootloader after this step ← this is the issue

Honestly I don't understand why.

I verified the protection (options bytes) and tested with :
- the Write Unprotect command (Two 0x79 received), then erase command → No response 
- The Write Unprotect command + reset NRST, then sync byte, finally the erase command : no response
-  erase command then reset after a timeout of 10 seconds.
   → program still runs, indicating erase did not occur
-  The page by page erase → no response either
- Verified signals with a logic analyzer → all bytes are correctly sent in proper order


I’m unsure why the bootloader stops responding after the global erase request (0xFFFF). Could you advise whether there’s a known issue or a missing step in this sequence?

Thanks in advance for your help.

Best regards,




Best answer by Xem

As promised, I'm back to explain how I resolved my issue.

To summarize:

  1. The STM32WB does not support the mass erase command (0x44 in my case) except via the SWD interface.
    How can you know if the 0x44 command is supported by the bootloader?
    Send the Get command (0x00) and read the response — it returns a list of supported commands.

    Even if the extended erase command (0x44) is supported, you cannot send special values like 0xFFFF to perform a mass erase of the flash memory.
    This is likely due to protected areas in the flash, especially regions reserved for the OpenThread binary and wireless stacks.

  2. So how do you erase?
    You need to use the extended erase command (0x44) in page-by-page erase mode.

To do that:

  • Send 0x44 followed by its XOR complement (0xBB).

  • Wait for the ACK (0x79).

  • Send the number of pages to erase, minus one (N - 1).
    For example, to erase 3 pages, send the number 2 :0x0002. This value must be sent as 2 bytes (big endian).

  • Then send each page number (2 bytes per page, also in big endian).

  • Finally, send the checksum byte, which is the XOR of all the previously sent bytes (i.e., the N - 1 value and all the page numbers).

Tip:
If you receive a NACK (0x1F), double-check:

  • That your data is sent in big endian format.

  • That your checksum is correct.

 

I hope this post helps others facing the same issue.

Have a great day,
Xem

4 replies

TDK
Super User
July 30, 2025

How is the bootloader being launched? If you're jumping from the application, consider trying to hold BOOT0 high during reset instead. Could be something on the chip is in a non-reset state.

"If you feel a post has answered your question, please click ""Accept as Solution""."
XemAuthor
Associate
July 30, 2025

The bootloader follows this hardware configuration to be launched : 
Pin PH3-boot0 connected to an IO of the esp32.
Pin Reset connected to another IO of the esp32. 
This procedure is described inside the AN2606, pattern 16 (First condition).

The esp32 drives the stm32 inside the bootloader mode or application mode with the state of PH3-BOOT0 pin. It is not an IAP used. 

This procedure seems to work perfectly, as I can synchronized with the bootloader and execute the Get command..

XemAuthor
Associate
August 5, 2025

The Extended erase command (0x44) sent through uart, for a mass erase (0xFFFF, 0xFFFE, ..), doesn't work on stm32WB. Even if the command is acknowledged by the bootloader, the functionality is not working. The response come from ST.

 

I'am trying to know if an erase page-by-page is possible or not. According to my tests, it is not possible too. I remains this thread opened to keep you informed about the status of this command. I am not resolved the problem.

If someone has information about this, please comment. 

XemAuthorBest answer
Associate
August 8, 2025

As promised, I'm back to explain how I resolved my issue.

To summarize:

  1. The STM32WB does not support the mass erase command (0x44 in my case) except via the SWD interface.
    How can you know if the 0x44 command is supported by the bootloader?
    Send the Get command (0x00) and read the response — it returns a list of supported commands.

    Even if the extended erase command (0x44) is supported, you cannot send special values like 0xFFFF to perform a mass erase of the flash memory.
    This is likely due to protected areas in the flash, especially regions reserved for the OpenThread binary and wireless stacks.

  2. So how do you erase?
    You need to use the extended erase command (0x44) in page-by-page erase mode.

To do that:

  • Send 0x44 followed by its XOR complement (0xBB).

  • Wait for the ACK (0x79).

  • Send the number of pages to erase, minus one (N - 1).
    For example, to erase 3 pages, send the number 2 :0x0002. This value must be sent as 2 bytes (big endian).

  • Then send each page number (2 bytes per page, also in big endian).

  • Finally, send the checksum byte, which is the XOR of all the previously sent bytes (i.e., the N - 1 value and all the page numbers).

Tip:
If you receive a NACK (0x1F), double-check:

  • That your data is sent in big endian format.

  • That your checksum is correct.

 

I hope this post helps others facing the same issue.

Have a great day,
Xem