2025-07-04 12:30 AM
Hi,
On few good units , erase takes around 6.5seconds with V2.9 STM32Cube prograamer.
This issue doesnt occur when we use STM32 Cube prograamer V2.19. Erase takes around 4.8seconds
On checking the difference between the two VERSIONS we found the command sent for erase is different in both the versions of STM32 Cube Programmer.
V2.9 sends command 0xffff00 data size :3 Bytes. This is a mass erase.
While V2.19 sends 0X0000000000 DATA size: 5bytes. It is a page wise erase. The erase time taken by V2.19 is less compared to V2.19.
Once the unit switches to the STM Bootloader, the IWDG timeout will be 16 seconds (32 kHz clock, pre-scaler set to 256 [Max Value] and window set to 2000). But on disabling this interrupt , we are able to do serial programming even with V2.9. Since the timeout for reset is 16 seconds , we are not able to understand how delay in erase using V2.9 can cause this reset.
Also , why it never happens when programmed with V2.19
Please note on doing only Bank 1 ERASE with V2.9 there is no issue. issue happens only during Mass erase V2.9 STM32Cube programmer.
Programming & erase using JTAG has no issues.
Any leads will be appreciated.
2025-07-04 12:44 AM
@richaverma wrote:
On few good units , erase takes around 6.5seconds with V2.9 STM32Cube prograamer.
This issue doesnt occur when we use STM32 Cube prograamer V2.19. Erase takes around 4.8seconds
Hello,
There is no version V2.9 for CubeProgrammer. The latest one is V2.19 as listed in the CubeProgrammer web link:
Could you please clarify?
What is the STM32H7 exact part number are you using? what board are you using: ST or custom board?
2025-07-04 12:50 AM
We are using STM32H743 . We are using STM32H743 Microcontroller in one of our custom product.
Also STM32CubeProgrammer v2.9.0 was previous release. This issue is happening in our production units . we have already crossed the development & qualification stage.
2025-07-05 6:43 AM
> On checking the NRST , it went low for around 30us .
Check RCC->CSR to see why the chip was reset. Perhaps a brown out condition, or IWDG. You could also check the TX/RX pins to see what is happening during the communication. Perhaps also NRST at the same time to see when the reset happens.
Probably a hardware issue if it happens repeatedly on the board.
Differences between v2.9.0 and v2.19.0 don't seem relevant here.
2025-07-07 9:51 AM
We have checked the TX and RX and at the same time NRST . There is no issue with the communication. Data seems fine . Also the issue happens occasionally and not on all the Units.
Only during the mass erase of the flash the error is happening when our unit switches to the STM Bootloader..
Looks like the processor is hanged or becomes unresponsive while the command 0xffff00 is sent from the cube programmer v2.9.
There is also some findings where we found mass erase is not managed well when connecting via UART using V2.9. refer link
There is no HW reset happening , since we have not connected NRST externally other than when programming using JTAG (ST-LINK) . No issues with erase using JTAG (STLINK) .
Our suspect is , Trying to perform an mass erase operation of a flash sector forces a WWDG reset, the watchdog expires resetting the chip.
When our unit switches to the STM Bootloader, the IWDG timeout will be 16 seconds (32 kHz clock, pre-scaler set to 256 [Max Value] and window set to 2000) as per snapshot below. The max erase time for mass erase from datasheet is 16 seconds as well. The IWDG is what is enabled , while going to the bootloader from our application.
What can be reasons for IWDG timeout during the bootmode during mass erase?
Our theory :Since the IWDG is enabled by the our application software, the MCU experiences an IWDG reset during a full flash erase. Flash erase timing varies, so this could explain why a bad board sometimes succeeds and sometimes fails.we made a custom version of the our application SW which does NOT enable the IWDG and in this case the mass erase works fine everytime.
So our next set of actions are
2025-07-07 7:40 PM
Erase one page at a time rather than doing a full erase.
2025-07-07 8:37 PM
But page wise erase is not an option in STM32 cube programmer v2.9.It does exists in V2.19.
But what I wanted to understand why mass erase trigger iwdt reset when reset timeout is 16 seconds .
During boot mode it's fully bootloader code which is not shared by ST.How it controls the watchdog reset and it's refresh timeS?
Under what scenarios during mass erase the reset can be triggered from SW in bootmode?
2025-07-07 9:43 PM
If IWDG timeout is set to 16s, that's how long it'll take, within the tolerance of the LSI clock.
If it's resetting before that, either it wasn't refreshed or it's not set to 16s.
AN2606 says it refreshes the bootloader periodically but provides no other details.
I would suggest booting into the bootloader, then connecting over SWD and examining the state of the IWDG peripheral to see how it's configured. It's possible there is a bug, perhaps not. I don't see anything reported.
What is the time between command set and NRST going low due to IWDG? Can you show a scope plot of this?
At the end of the day, not sure it matters much--you can't change the bootloader and you can't change STM32CubeProgrammer behavior without upgrading.
2025-07-08 12:02 PM
We are using software method to enter boot mode i.e. JumpToBootloader() function using discretes, we observe that the STM32 MCU enters the boot mode (UART) and responds to the ID, after the erase command no response. The issue happens during mass erase only on some units and its intermittent as well. There are no changes to microcontroller batch codes .
Our code uses the IWDG configured to reset if not serviced for 1 second (32 kHz clock, pre-scaler set to 16 and window set to 2000). The code application should service this every 50ms.
In the case of going to the bootloader from our code the IWDG will still be enabled. According to the Bootloader documentation as shown below: This means that once our unit switches to the STM Bootloader, the IWDG timeout will be 16 seconds (32 kHz clock, pre-scaler set to 256 [Max Value] and window set to 2000).
We tried to read the watchdog registers from the MCU when the bootloader is running. The prescale register was set to 256, so this should mean a 16 second reset.
Refer the snapshot of the reset , RS232_RX & RS232_TX. Also the video snapshot shows that when reset occurs roughly around 10 sec and then no response.
I have attached the logs of good versus bad for more details of behavior. towards the end
2025-07-08 12:41 PM
Hello @richaverma ,
You've already closed this thard by accepting the @TDK answer as solotion. Did you do that by mistake?