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