halt
armv4_5 core_state arm
load_binary flash.bin 0x81000000
bp 0x81000028 4 hw
reg pc 0x81000070
resume
# I want a wait-for-breakpoint command here. As a work-around, I use "sleep"
sleep 1000
halt
step
reg r3
poll
reg r0
shutdown
This script gives the following output:
../openocd/src/openocd -f arm7_ft2232.cfg
Info: openocd.c:84 main(): Open On-Chip Debugger (2006-11-22 14:00 CEST)
Info: target.c:221 target_init_handler(): executing reset script 'h2222_init.script'
Info: configuration.c:50 configuration_output_handler(): requesting target halt...
Warning: arm7_9_common.c:842 arm7_9_halt(): target was already halted
Info: configuration.c:50 configuration_output_handler(): target already halted
Info: configuration.c:50 configuration_output_handler(): core state: ARM
Info: configuration.c:50 configuration_output_handler(): downloaded 132 byte in 0s 7859us
Info: configuration.c:50 configuration_output_handler(): breakpoint added at address 0x81000028
Info: configuration.c:50 configuration_output_handler(): pc (/32): 0x81000070
Info: configuration.c:50 configuration_output_handler(): requesting target halt...
Warning: arm7_9_common.c:1480 arm7_9_step(): target not halted
Info: configuration.c:50 configuration_output_handler(): r3 (/32): 0x00000000
Info: configuration.c:50 configuration_output_handler(): target state: halted
Info: configuration.c:50 configuration_output_handler(): target halted in ARM state due to debug request, current mode: System
Info: configuration.c:50 configuration_output_handler(): cpsr: 0x4000001f pc: 0x81000028
Info: configuration.c:50 configuration_output_handler(): r0 (/32): 0x80000000
There are two issues here:
There don’t seem to be a “wait” command to wait until the target hits a breakpoint.
Even if the target hits the breakpoint (in my test program, there are only three instructions to get to the breakpoint, and I’m waiting for a second here!) and the “halt” command is issued , the “step” command gives the warning that the target is not halted.
The command “wait_halt” allows you to wait for debug entry.
In your case, adding a poll after the halt would have worked, too. The target was already in debug state, but the debugger wasn’t aware of this, as there are no periodical polls during script exectuion.
The current script support in OpenOCD was never intended for what you’re trying to achieve. When I wrote it, all I hand in mind was low-level initialization, like configuring a SDRAM controller and other memory banks, or setting up a PLL - stuff that can be achieved by simply writing/reading some memory locations with m[dw][bhw] commands. I’ve later added the wait_halt to make life easier for people who want to use OpenOCD scripts to flash their targets.
For your particular idea, I would rather use a “generic” flash driver that uses code running on the target for every operation (probe, protect_check, erase_check, erase, protect and write) with configurable selection of the algorithm.
flash bank generic <bus_width> <chip_width>
generic_flash [options …]
The generic flash driver would then load _probe.bin, _write etc. for working with the flash. This would allow you to use the algorithm facilities that are much more suitable than the script support.
If you hit a breakpoint then the processor can be halted but openocd does not know this. When running interactively then there is a polling loop that does this continously, but when using scripts this explicit calls to poll is often necessary.
I already use a similar method for programming at work.
This would make it more in line with commercial systems that upload a bootloader.
With the system i use, commands are passed over the dcc channel and executed by the target, as such the host software knows very little about the target, except sending things like
Flash Init
Erase Flash
Write Flash
etc
Also the main stub of the bootloader is generic, so as such for a new bootloader you only have to implement the lib functions mentioned above.
Time is a bit short at the moment, but i am happy to look into this.
Dominic:
The command “wait_halt” allows you to wait for debug entry.
In your case, adding a poll after the halt would have worked, too.
Ah, OK! I could not find this command on the wiki or the pdf.
The current script support in OpenOCD was never intended for what you’re trying to achieve. [ … ]
For your particular idea, I would rather use a “generic” flash driver that uses code running on the target for every operation (probe, protect_check, erase_check, erase, protect and write) with configurable selection of the algorithm.
