cancel
Showing results for 
Search instead for 
Did you mean: 

Issue with Extended Erase Command on STM32WB55RG via USART1

Xem
Associate II

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,




1 ACCEPTED SOLUTION

Accepted Solutions
Xem
Associate II

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

View solution in original post

4 REPLIES 4
TDK
Super User

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".
Xem
Associate II

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..

Xem
Associate II

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. 

Xem
Associate II

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