Black-Magic-Probe-Book
Black-Magic-Probe-Book copied to clipboard
compuphase
bmdebug Reset stuck at Initializing. Please wait ...
Hi, Pressing "Reset" does not always reset. Prog seems to get stuck at "Initializing. Please wait..."
Sequence of events that leads to the issue. after program load Cont -> Stop -> Reset -> program gets stuck and have to restart it
See attached screenshot and debug log.
What I see in the log, is that there is no response to the "stop". I see that the command is given: the next-to-last line in the log is "State: 21". This is the result on clicking on the continue/stop button (and since the firmware was running, it must be "stop"). However, there is no response from GDB.
The last line, "State: 4", is the response to clicking on "reset". Again, there is no response from GDB.
A work-around it: pressing Ctrl+C twice within 3 seconds does a full reset.
It is puzzling why GDB does not respond to the "stop" command. Are you able to stop the program in (bare) GDB?
While my program is running, I'm not able to execute any commands (no gdb prompt). Same in bmdebug and gdb-multiarch.
When stuck initializing, pressing Ctrl+C multiple times does not stop the program.
After unplugging and replugging the BMP. It seems to be working again. However from time-to-time, it gets stuck again. Should have some time toward the end of the week to see if I can find a repeatable pattern.
Found a pattern that may be impacting this... or it could be a separate issue - not sure.
When I do a reset, half of the time the program returns to the breakpoint at main(). The other half, the program continues running without stopping at main().
This behavior is not random; it alternates: continue -> stop -> reset -> stops at main() continue -> stop -> reset -> continues running w/o stopping continue -> stop -> reset -> stops at main() continue -> stop -> reset -> continues running w/o stopping ...
Each time the program continues running without stopping after a reset, there is an error message: error,msg="Error erasing flash with vFlashErase packet"
Looking at the debug log, this error just occurs after a "compare-sections" command When the line shows "4040 compare-sections" => no error message follows => restarts at main() When the line shows "c040 compare-sections" => error message follows => restart does not work as expected
Hope this is helpful. bmdebug.log
Additional clues: The above only seems to happen when the "Download to target on mismatch" option is selected.
Typing "reset" at the command line behaves exactly like pressing the "reset" button. That is to say, the issue still occurs. However, the problem does NOT occur when issuing a "reset load" at the command line.
Here are two log files. One when working correctly and one when failing. These were run back-to-back with no modifications to either my target app nor to bmdebug.
Recall: this only seems to happen when "Download to target on mismatch" is selected.
I'll take a shot at tracking it down, but this one may be above my pay level. :) bmdebug-working.txt bmdebug-failing.txt
I have yet to look more deeply into this, but I can confirm a few of your findings:
-
The "reset" button indeed does exactly the same as the "reset" command.
-
Given the error message "Error erasing flash with vFlashErase packet", this is definitely linked to the "Download to target on mismatch" option. When that option is selected, bmdebug first issues a "compare-sections" command to check whether the code in Flash in the microcontroller matches the ELF file. On mismatch, it then proceeds to download the ELF file. The first step in downloading to Flash is to erase all Flash sectors that will be rewritten. That procedure fails.
When the option "Download to target on mismatch" is not set, bmdebug skips the downloading. It still runs the "compare-sections" command, to give a warning on mismatch.
When you give a "reset load" command, bmdebug skips the "compare-sections" command, but proceeds immediately with downloading the ELF file to the microcontroller.