JTAG error when debugging during flash erase

[chris250]

Hi,

I have an STM32F746 with 1MB of flash that I am debugging with VisualGDB. It is the discovery board with the on-board ST-Link. I am using version 5.3 (build 1836), OpenOCD 2017-821-0.10.0, ARM toolchain 6.2.0/7.12/r3, STM32 Devices 4.3.

I use the STM32 HAL to erase some flash sectors sectors, other than where my code is located. This is the done with the HAL_FLASHEx_Erase() function.

The function works and I can read/write/erase the internal flash memory. But when I am debugging and I call the HAL_FLASHEx_Erase() function I get a JTAG communication error:

ERROR -4
Error: jtag status contains invalid mode value – communication error
Warn: target stm32f7x.cpu is not halted
Polling target stm32f7x.cpu failed, trying to reexamine

I guess this error happens because it does take some time to perform the erase operation, and the flash operations are halted/stalled until the erase is complete. Is there anything I can do to prevent the debugger from breaking during the erase process?

Thanks

[chaaalyy]

Hi 🙂

I´m just curious… What do you mean with “using STM32 HAL to erase Sectors…” ?

I also work on the stm32f756-Disco and for debugging i just use the OpenOCD-Stuff provided with VisualGDB. St-Link v2.1, Frequency at 2000 and i just program, when rebuilt since last Load. Works perfectly out of the Box for me 🙂 Of course, also the whole Flash Memory gets completely erased, before reprogramming.

The resulting command Line (under VisualGDB-Settings -> Debug Settings, when opening “advanced Settings” )is:

-f interface/stlink-v2-1.cfg -f target/stm32f7x.cfg -c init -c “reset init”

Startup GDB Commands are:

set remotetimeout 60
target remote :$$SYS:GDB_PORT$$
mon halt
mon reset init
load

Regards, Charly

[support]

Hi,

We are not aware of any side effects of FLASH erasing that could cause JTAG issues, so this could be a side effect of inconsistent power supply or cross-talk, or could also be a limitation of a specific STM32 core. We would advise double-checking this with ST.

A possible workaround would be to erase the FLASH memory page-by-page instead of doing one massive erase operation – this might work around the issue.

[chris250]

Hi Chaaalyy

The code I am running is using the internal flash to store some data. This data is spread across a couple of internal sectors. The data in these sectors (including the erase of a full sector) is done through using the HAL functions.

Hi Support,

Thanks for the reply. I am only erasing a single sector within the STM32 device. My research lead me to the STM32 ref manual flash section, that states:

Any attempt to read the Flash memory while it is being written or erased, causes the bus to
stall. Read operations are processed correctly once the program operation has completed.
This means that code or data fetches cannot be performed while a write/erase operation is
ongoing.

Could this affect the debugger?

Thanks in advance.

[support]

Hi,

This might indeed interfere with debugging, but a 100% correct answer would depend on on the internal implementation details of the STM32 debug unit. We would advise double-checking this with ST (e.g. on the ST forums) as they should have a better insight into the STM32 internals than we do.

[Author]

Posts