> You could define a few step/breakpoint commands in tcl that has this
> functionality. The existing functions would then be the low level
> implementation
> of hardware/software breakpoints.
with the "breakpoints list/save/restore" patch one can use a similar script:
----------------------------------------------------------------------------
reset
sleep 1000
arm7_9 fast_memory_access enable
arm7_9 dcc_downloads enable
str9x flash_config 0 4 2 0 0x80000
# save breakpoints
bpsave bp.bpt
# remove all breakpoints
rbp
flash protect 0 0 7 off
flash write_image erase prog.elf
flash protect 0 0 7 on
verify_image prog.elf
# restore breakpoints
script bp.bpt
resume
----------------------------------------------------------------------------
> This isn't a problem when debugging with GDB, is it?
no
> How do you propose to deal with this from a users point of view?
The first issue for users (like me) is to be aware of risks and problems.
When a user execute:
> load_image zero.img 0x50000000 bin
256 byte written at address 0x50000000
downloaded 256 byte in 0.015625s
openocd says everything is ok but is not (not always) true.
Some idea can be:
- In the default scripts add a comment like "this area is reserved for the
debugger and should not be used by the application"
- Set 'backup' as default
- In the default scripts set a 'working_area' at the end of internal SRAM
(where is the stack? where is the heap?)
- chek overlapping of 'working_area' and image load in the load_image
implementation (this should be
easy and mandatory)
- if possible, allocate the 'working_area' needed for the algorithm outside
of the loading image space (but inside the 'working_area' defined in the
config file)
- if not enough space (e.g. the loading image space completely overlaps the
'working_area' defined in the config file) give an error and do not load
or load without dcc (or at least tell the user to disable dcc)
Regards,
Dario
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
