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.