Issue with Extended Erase Command on STM32WB55RG via USART1

[Xem]

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,

[TDK]

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.

[Xem]

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