Debugging problems on STM32G0B1 Nucleo board in conjunction with flash memory erasing/programming

[Markus8494]

I have a very strange behaviour when using the (on-board) ST-Link debugger on the STM32G0B1 Nucleo board using the Flash Programming example contained in the STMCubeG0 package (v1.5.0).

I use Keil MDK IDE v5.36, CMSIS- & STM32G0 device support packages are up to date.

Case #1:

I download the program directly (no debugging) and it *ALWAYS* works as expected

(=> LED pattern indicates success of erase, program & verify procedure).

Case #2:

I start a debug session and run the target, after the debugger automatically has ran to the main function.

After running the target, I noticed different behaviours:

a) Sometimes, after a few seconds, the debug session is terminated with an error message

(Cannot access target. Shutting down debug session.)

b) The application works as expected (erasing, programming & verify succeeded).

Update to case 2:

It looks like the debug session terminations do not occur when I reduce the debugger clock to, for instance, 0.050 MHz.

(Project options -> tab 'Debug' -> 'Settings' (on the right hand side) -> Clock Req.)

Case #3:

Same as case #2 but with a breakpoint set before the erase function call (main.c, line 143).

Program runs and stops at breakpoint location.

When I resume running the application, the erase procedure fails and it stays in the 'erase failed' while loop. (line 155-158).

Now I reset the CPU, the application automatically runs and stops at the breakpoint at line 143 again.

But now, when I resume the application, the flash procedures (erase, program & verify) succeed.

Further debugger resets (and auto run) always result in successful flash operation.

It looks like, in this case, the program fails only for the first time after starting the debug session.

Case #4:

I remove the flash erase (line 143) and flash program (line 170 line 169) function calls.

No problems occur during debugging. Neither with slow (0.050 MHz) nor with fast (10 MHz) debugger clock selection.

I also can use breakpoints without any problems.

It looks like there is some kind of problem with the debugger in conjunction with the flash erase/program procedures (on this type of board?).

I never had such problems on the F0, F1, F3 & F4 evaluation- and Nucleo boards.

Nucleo board label:

NUCLEO-G0B1RE

NUG0B1RE$AU1

On-board ST-Link firmware version:

V2J38M27

[TDK]

The debugger might be messing with the flash. Possibly an error code is set. Check FLASH->SR flags prior to modifying the flash. Check the reason for the flash failing. There should be an error code produced in the flash handle.

Did you mean to include your main.c? Without it, the line numbers aren't too helpful to debug.

[Markus8494]

Thanks for the quick response.

The Cube example uses the HAL functions. When the erase fails in case #3, the returned error is HAL_TIMEOUT.

I will try to get the flash error flags from the SR register.

I also have tried to disable the prefetch buffer and the CPU instruction cache but it does not make any difference for this issue.

The mentioned main.c file is part of the Cube (STM32CubeG0-1.5.0) FLASH example.

The FLASH example project comes from ST, see: https://www.st.com/en/embedded-software/stm32cubeg0.html

I did not make any modification to the files.

This main.c file is located in the sub-directory: /Projects/NUCLEO-G0B1RE/Examples/FLASH/FLASH_EraseProgram/Src/

Additionally you can find the main.c file attached to this post.

[Markus8494]

Update regarding the FLASH->SR register in case #3:

If I start the debug session, the debugger automatically runs the target and halts on main().

At this point, the CFGBSY flag is set (FLASH->SR = 0x0004'0000).

I run until line 143 (HAL_FLASHEx_Erase function call). CFGBSY is still set.

HAL_FLASHEx_Erase returns with error HAL_TIMEOUT because the HAL_FLASHEx_Erase function waits after the erase procedure for the CFGBSY flag to clear.

Because of the erase failure, the application stays in the 'erase failed' while loop (line 155-158).

If I execute a 'Reset CPU', the CFGBSY flag is cleared.

If I now run to line 143 and step over the HAL_FLASHEx_Erase function, it (of course) succeeds.

[TDK]

So CFGBSY=1 definitely will stop a flash operation from succeeding. Increasing the timeout would likely solve it. It's unclear why it's getting set in the first place.

[ECiav]

I've the same problem with STM32G070RB. In debugging mode in some case i've got "Cannot access target. Shutting down debug session", and in other case the Erase operation failed. Is there some solution?

 

Thanks in advance.