When issuing GDB `continue` in RAM, can I write to the adresses from which I `continue`d?

Question

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,

1. I'm connecting with OpenOCD+GDB through JTAG
2. load my binary image into the RAM (OpenOCD: load_image)
3. reset the CPU (OpenOCD: reset init)
4. and set the PC to the location I want to run (GDB: set $pc=0x2000001d)
5. 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

1. I'm resetting the development board with the reset button
2. 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

1. 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?
2. Is my assumption I explained above plausible?

Answer 1

I'm resetting the development board with the reset button

Don't do that while OpenOCD is running. Use OpenOCDs reset halt or reset run commands instead.

The reset button will affect the internal debugging state of the target but OpenOCD may not detect that correctly, depending which debugger you use and how it is wired up.

Note that you should do reset init before you load the binary to flash.