I'm just writing some test programs in order to get to know the STM32F4 (ARM Cortex M4). The development board I'm using has U-Boot preinstalled in flash. When the board is up and running and U-Boot is showing it's command prompt,
- I'm connecting with OpenOCD+GDB through JTAG
- load my binary image into the RAM (OpenOCD:
load_image
) - reset the CPU (OpenOCD:
reset init
) - and set the PC to the location I want to run (GDB:
set $pc=0x2000001d
) - and run (GDB:
continue
)
The problem
Most of the times this is working fine. However, several times I had the problem that when the CPU is in RUNNING state suddenly OpenOCD is displaying this message:
Error: jtag status contains invalid mode value - communication failure
Polling target stm32f4x.cpu failed, GDB will be halted. Polling again in 100ms
If my observation is correct, this only happens when
- I'm resetting the development board with the reset button
- and typing something into the then-appearing U-Boot prompt.
When instead of U-Boot some other program is present in flash, this problem does not seem to occur.
My assumption
Currently I'm assuming this is caused by U-Boot writing to the RAM location from which issued the continue
command. I don't know how continue
works exactly, but my theory is that this command affects the debug circuitery in some way and writing to that RAM adress is therefore causing problems.
When my other program is present in flash, everything works fine. Even hitting the reset button works. I think it's because its very small in memory footprint, hence 0x2000001d is unaffected.
My questions
- What is
continue
doing exactly? Does it anything else than just setting the CPU into run mode? Does it affect the breakpoints in some way? - Is my assumption I explained above plausible?