openocd-devel

[Openocd-development] 'flash write_image' and 'verify_image' commands fail if there are no more hardware breakpoints available

[Dario V. <dar...@ti...>]

Hi all,

I found that after manually setting hardware breakpoints 'flash write_image' 
and 'verify_image' commands fail if there are no more hardware breakpoints 
available.

I think they should be removed before command execution and then restored.

---------------------------------------------------------
(STR9comStick, ARM966E, FT2232, openocd svn 881)
---------------------------------------------------------
> bp 0x40 4 hw
> bp 0x100 4 hw
> verify_image prog.elf
no watchpoint unit available for hardware breakpoint
can't add hardware breakpoint, resource not available
can't add breakpoint to finish algorithm execution
error executing arm7_9 crc algorithm
Runtime error, file "?", line 1:
    no watchpoint unit available for hardware breakpoint
can't add hardware breakpoint, resource not available
can't add breakpoint to finish algorithm execution
error executing arm7_9 crc algorithm

In procedure 'verify_image' called at file "?", line 1
>
> rbp 0x40
> rbp 0x100
> verify_image prog.elf
verified 5588 bytes in 0.109375s
>
---------------------------------------------------------

Another question, about 'working_area'.

By default scripts (at least str9comstick.cfg) point at the beginning of 
SRAM.
For this reason it is not very clear what 'working_area' is (unless you read 
the documentation...) and one can believe (me, for example...) it is the 
beginning of internal SRAM.
If you load an application into the RAM at the same address (normally at the 
beginning of SRAM) using 'load-image' there is no check of this conflict and 
the load_image algorithm will overwrite itself while running.

Similar problem can happen if you are stepping an application (loaded in 
flash) and you want to load an image (data for debugging purpose) into the 
RAM at a known free address and then resume the application.
The beginning of the RAM will be overwritten by the algorithm code so some 
variable of your running application is now dirty (registers too?).
In this case you can use the 'backup' option of 'working_area' command but 
it is not in the default script (should it be?) nor a warning is given to 
the user.

The problem is evident only with 'dcc_downloads' enabled.

-----------------------------------------------------------------------------------
(STR9comStick, ARM966E, FT2232, openocd svn 881)
using default scripts (nobackup)
-----------------------------------------------------------------------------------
> mdw 0x50000000 64
0x50000000: e1a02000 e3e00000 e1a03001 e3a04000 ea00000b e7d21004 e59f7030 
e0200c01
0x50000020: e3a05000 e3500000 e1a06080 e2855001 e1a00006 b0260007 e3550008 
1afffff8
0x50000040: e2844001 e1540003 1afffff1 eafffffe 04c11db7 00000000 00000000 
00000000
0x50000060: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x50000080: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x500000a0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x500000c0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x500000e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
> mww 0x50000000 0 64
> mdw 0x50000000 64
0x50000000: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x50000020: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x50000040: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x50000060: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x50000080: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x500000a0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x500000c0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x500000e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
> dump_image zero.img 0x50000000 256
dumped 256 byte in 0.015625s
> load_image zero.img 0x50000000 bin
256 byte written at address 0x50000000
downloaded 256 byte in 0.015625s
> mdw 0x50000000 64
0x50000000: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x50000020: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x50000040: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x50000060: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000   [OK]
0x50000080: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x500000a0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x500000c0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x500000e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
> arm7_9 dcc_downloads enable
dcc downloads are enabled
> load_image zero.img 0x50000000 bin
256 byte written at address 0x50000000
downloaded 256 byte in 0.015625s
> mdw 0x50000000 64
0x50000000: 00000000 e3110001 0afffffc ee111e10 e4801004 eafffff9 00000000 
00000000
0x50000020: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x50000040: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x50000060: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000   [NOT OK]
0x50000080: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x500000a0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x500000c0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x500000e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
> mww 0x50000000 0x11111111 64
> mdw 0x50000000 64
0x50000000: 11111111 11111111 11111111 11111111 11111111 11111111 11111111 
11111111
0x50000020: 11111111 11111111 11111111 11111111 11111111 11111111 11111111 
11111111
0x50000040: 11111111 11111111 11111111 11111111 11111111 11111111 11111111 
11111111
0x50000060: 11111111 11111111 11111111 11111111 11111111 11111111 11111111 
11111111
0x50000080: 11111111 11111111 11111111 11111111 11111111 11111111 11111111 
11111111
0x500000a0: 11111111 11111111 11111111 11111111 11111111 11111111 11111111 
11111111
0x500000c0: 11111111 11111111 11111111 11111111 11111111 11111111 11111111 
11111111
0x500000e0: 11111111 11111111 11111111 11111111 11111111 11111111 11111111 
11111111
> load_image zero.img 0x50000000 bin
256 byte written at address 0x50000000
downloaded 256 byte in 0.015625s
> mdw 0x50000000 64
0x50000000: 50000410 11111111 11111111 11111111 11111111 11111111 11111111 
11111111
0x50000020: 11111111 11111111 11111111 11111111 11111111 11111111 11111111 
11111111
0x50000040: 11111111 11111111 11111111 11111111 11111111 11111111 11111111 
11111111
0x50000060: 11111111 11111111 11111111 11111111 11111111 11111111 11111111 
11111111   [NOT OK]
0x50000080: 11111111 11111111 11111111 11111111 11111111 11111111 11111111 
11111111
0x500000a0: 11111111 11111111 11111111 11111111 11111111 11111111 11111111 
11111111
0x500000c0: 11111111 11111111 11111111 11111111 11111111 11111111 11111111 
11111111
0x500000e0: 11111111 11111111 11111111 11111111 11111111 11111111 11111111 
11111111
> arm7_9 dcc_downloads disable
dcc downloads are disabled
> load_image zero.img 0x50000000 bin
256 byte written at address 0x50000000
downloaded 256 byte in 0.015625s
> mdw 0x50000000 64
0x50000000: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x50000020: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x50000040: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x50000060: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000   [OK]
0x50000080: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x500000a0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x500000c0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
0x500000e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000
>
-----------------------------------------------------------------------------------

Best regards,

              Dario 

Re: [Openocd-development] 'flash write_image' and 'verify_image' commands fail if there are no more hardware breakpoints available

[Ø. H. <oyv...@zy...>]

On Thu, Jul 31, 2008 at 11:13 AM, Dario Vecchio <dar...@ti...> wrote:
> Hi all,
>
> I found that after manually setting hardware breakpoints 'flash write_image'
> and 'verify_image' commands fail if there are no more hardware breakpoints
> available.
>
> I think they should be removed before command execution and then restored.

I guess the problem is that that would be another code path to test... The
code is working as intended otherwise.

This would have to be done *everywhere* in the code and at that point I'd
rather place this responsibility with the debugger, which can enable/disable
breakpoints before/after stepping/running.

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.

This isn't a problem when debugging with GDB, is it?

> ---------------------------------------------------------
>
> Another question, about 'working_area'.
>
> By default scripts (at least str9comstick.cfg) point at the beginning of
> SRAM.
> For this reason it is not very clear what 'working_area' is (unless you read
> the documentation...) and one can believe (me, for example...) it is the
> beginning of internal SRAM.
> If you load an application into the RAM at the same address (normally at the
> beginning of SRAM) using 'load-image' there is no check of this conflict and
> the load_image algorithm will overwrite itself while running.
>
> Similar problem can happen if you are stepping an application (loaded in
> flash) and you want to load an image (data for debugging purpose) into the
> RAM at a known free address and then resume the application.
> The beginning of the RAM will be overwritten by the algorithm code so some
> variable of your running application is now dirty (registers too?).
> In this case you can use the 'backup' option of 'working_area' command but
> it is not in the default script (should it be?) nor a warning is given to
> the user.
>
> The problem is evident only with 'dcc_downloads' enabled.

How do you propose to deal with this from a users point of view?

-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer

Re: [Openocd-development] 'flash write_image' and 'verify_image' commands fail if there are no more hardware breakpoints available

[Dario V. <dar...@ti...>]

> 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 

Re: [Openocd-development] 'flash write_image' and 'verify_image' commands fail if there are no more hardware breakpoints available

[Ø. H. <oyv...@zy...>]

On Thu, Jul 31, 2008 at 1:06 PM, Dario Vecchio <dar...@ti...> wrote:
>> 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:

I'd like to see this implemented as a tcl api proc.

Are you interested in having a stab at it?

The things you are contributing requires/ties very nicely into the scripting
work being done and I think you'll find that your changes will become
much more elegant using scripting.

>> 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.

If the operation failed, then it should report an error. Otherwise I'd just say
that the code is broken. Error codes do not always propagate properly
in the older openocd code.

In this case I'm wondering if you have found a bug in the error handling for
running algorithms when there are no free breakpoints.

> 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"

Is anyone going to read that comment?

> - Set 'backup' as default

That's slow and unecessary often.

> - In the default scripts set a 'working_area' at the end of internal SRAM
>  (where is the stack? where is the heap?)

I don't think there is such a thing as the "right" place to put the
working_area...
is there?

> - chek overlapping of 'working_area' and image load in the load_image
> implementation (this should be easy and mandatory)

hmm... sounds like a reasonable idea, though I'd try to push the
error handling into target_write_buffer(). Have to be careful to allow
writing to the working area as well though.

>  - 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)

I would like to see a robust solution: it's code path should be easy
to implement
and easy to test(i.e. exercised often). If we put an error message in some code
path that hardly ever happens, then the error message is probably not going to
work when the user eventually needs it...


-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer

Re: [Openocd-development] 'flash write_image' and 'verify_image' commands fail if there are no more hardware breakpoints available

[Magnus L. <lu...@ml...>]

Hello list
Øyvind Harboe wrote:
> On Thu, Jul 31, 2008 at 11:13 AM, Dario Vecchio <dar...@ti...> wrote:
>   
>> Hi all,
>>
>> I found that after manually setting hardware breakpoints 'flash write_image'
>> and 'verify_image' commands fail if there are no more hardware breakpoints
>> available.
>>
>> I think they should be removed before command execution and then restored.
>>     
>
> I guess the problem is that that would be another code path to test... The
> code is working as intended otherwise.
>   
After taking a quick look, I wold say that the code where things happen, 
armv4_5_run_algorithm is not  safe and does not perform as intended. It 
only works most of the time.
If there is an existing hw breakpoint in  the memory block where the 
algoritm code is loaded to, then bad things will happen.
So even without the  problem of not having enough breakpoints, when 
running algorithms on the target we probably should
disable all application breakpoints, and then restore them when resuming 
the  application.
> This would have to be done *everywhere* in the code and at that point I'd
> rather place this responsibility with the debugger, which can enable/disable
> breakpoints before/after stepping/running.
>
>   
This should probably be done in the "target->run_algoritm" functions, 
yes several places :), and not  by gdb or tcl scripting since this 
problem will apply every time an algoritm is run on the target and it 
should be fixed in the core C code.

Regards
Magnus

Re: [Openocd-development] 'flash write_image' and 'verify_image' commands fail if there are no more hardware breakpoints available

[Spen <sp...@sp...>]

> This should probably be done in the "target->run_algoritm" 
> functions, yes several places :), and not  by gdb or tcl 
> scripting since this problem will apply every time an 
> algorithm is run on the target and it should be fixed in the 
> core C code.
> 

I agree, this needs fixing at a c level.
to be honest there are only really three run_algorithm functions used
arm4_5, arm7 and mips so should not be major change.

Cheers
Spen

Re: [Openocd-development] 'flash write_image' and 'verify_image' commands fail if there are no more hardware breakpoints available

[Duane E. <op...@du...>]

Øyvind Harboe wrote:
> On Thu, Jul 31, 2008 at 1:06 PM, Dario Vecchio <dar...@ti...> wrote:
>   
>>> 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:
>>     
>
> I'd like to see this implemented as a tcl api proc.
>
> Are you interested in having a stab at it?
>
>   

PROBLEM: Saving will be hard, the JIM TCL does not support 
opening/closing/reading/writing files.
Reloading is simple - "source filename.tcl"

-Duane.

Re: [Openocd-development] 'flash write_image' and 'verify_image' commands fail if there are no more hardware breakpoints available

[Ø. H. <oyv...@zy...>]

> PROBLEM: Saving will be hard, the JIM TCL does not support
> opening/closing/reading/writing files.
> Reloading is simple - "source filename.tcl"

Jim Tcl does have file IO(jim-aoi.c).

Do we want to add it?

I'd like scripts to work across operating systems. What Dario wants
to do is to save settings. Two approaches come to mind(imagination
being the limiting factor):

- add two commands ocd_save_setting/load_setting that take two parameters.
Settings name(no path) and  value. We can implement these in OpenOCD
and let the C part decide where to put it. Windows/Linux differ.
- add jim-aio.c package that gives us file IO.



-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer