cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H74 microcontroller resetting while doing serial load using STM32 Cube Programmer V2.9 on few units

richaverma
Associate III

Hi,

  1. We are using STM32H74 microcontroller STM Bootloader ST Version 0x91.We are using STMCube Programmer V2.9 while during the serial programming using UART.
  2. On few of the units , we get the erase issue : Failed to erase memory . And then GETId not responded. All the power supply of the units are stable. On checking the NRST , it went low for around 30us . Refer attached.

richaverma_1-1751612982544.png

richaverma_0-1751612829455.png

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

richaverma_2-1751613817174.png 

richaverma_3-1751613870961.png 

richaverma_4-1751613942902.pngrichaverma_5-1751614049445.png

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.

 

10 REPLIES 10
mƎALLEm
ST Employee

@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:

mALLEm_0-1751614937578.png

Could you please clarify?

What is the STM32H7 exact part number are you using? what board are you using: ST or custom board?

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

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.

TDK
Super User

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

If you feel a post has answered your question, please click "Accept as Solution".

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

https://community.st.com/t5/stm32cubeprogrammer-mcus/are-the-erase-commands-in-stm3cubeprogrammer-broken-the/td-p/81968

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.

richaverma_0-1751906520060.png 

richaverma_1-1751906546166.png 

richaverma_2-1751906763754.png

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

  • Determine what the internal watchdog timeout actually is.We’ve seen that the reset occurs some time in the 5-6 second time frame.  So i am reaching out for STM support on this one to understand more details.
  • how often the IWDG is serviced ?

Erase one page at a time rather than doing a full erase.

If you feel a post has answered your question, please click "Accept as Solution".

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?

 

 

TDK
Super User

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.

If you feel a post has answered your question, please click "Accept as Solution".

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.

richaverma_2-1751999816056.png

 

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

richaverma_0-1751999526161.png 

richaverma_1-1751999568180.png

 

 

richaverma_4-1752001117913.png

richaverma_5-1752001234557.png

Hello @richaverma ,

You've already closed this thard by accepting the @TDK answer as solotion. Did you do that by mistake? 

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.