Hi Drasko,
your system has an ARM946E. Should have "vector_catch" capability.
Please check if command "arm9 vector_catch" shows the reset feature.
In such case, after set it to catch reset, you can press the reset
button to trigger OpenOCD and get CPU halted at first instruction.
If everything wor
Peter Stuge wrote:
> The alternative is quite straightforward, so I would
> strongly prefer not going there.
Allow me to clarify that;
The alternative of rewriting to use no double pointers makes the code
much more straightforward, so I would strongly prefer not using any
double pointers. :)
//
On 2010/12/11 13:00, Peter Stuge wrote:
Afraid not. The alternative is quite straightforward, so I would
strongly prefer not going there.
Thought as much :-)
Well, will leave it up to you guys to decide. I can test any new
patches required.
Cheers,
Paul
__
Paul Richards wrote:
> Peter, note that the double pointers are in the target list function
> implementations (that would be copied), are you ok with this?
Afraid not. The alternative is quite straightforward, so I would
strongly prefer not going there.
Thanks!
//Peter
On 2010/12/11 8:20, Andreas Fritiofson wrote:
I don't know. But, generally, if I _can_ register the same handler
twice, I'd expect each registration to require a separate unregister
call. The actual call sites would have to be inspected before changing
this behavior, of course. There shouldn't b
On Fri, Dec 10, 2010 at 11:39 PM, Peter Stuge wrote:
> Andreas Fritiofson wrote:
>> > Now there's 3 versions to choose from :-)
>>
>> It's not too late. The target versions seems nice and readable. And
>> correct, as far as I can see this late hour. I think the jtag version
>> should follow the be
Andreas Fritiofson wrote:
> > Now there's 3 versions to choose from :-)
>
> It's not too late. The target versions seems nice and readable. And
> correct, as far as I can see this late hour. I think the jtag version
> should follow the behavior of these and only remove the first matching
> handler
On Fri, Dec 10, 2010 at 4:16 PM, Paul Richards wrote:
> On 2010/12/10 18:46, Spencer Oliver wrote:
>>
>> Not looked into it but why do we not just duplicate the existing
>> unregister event/timer functions - or are they broken aswell?
>>
>
> They (the target versions) don't appear to have the same
Spencer Oliver wrote:
> [PATCH 1/2] contrib: make sure loaders use correct arch
> [PATCH 2/2] contrib: add source to the cfi flash loaders
Acked-by: Peter Stuge
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berl
[PATCH 1/2] contrib: make sure loaders use correct arch
[PATCH 2/2] contrib: add source to the cfi flash loaders
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
From: Spencer Oliver
Signed-off-by: Spencer Oliver
---
contrib/loaders/flash/pic32mx.s |1 +
contrib/loaders/flash/stm32x.s |1 +
contrib/loaders/flash/str7x.s |2 ++
contrib/loaders/flash/str9x.s |2 ++
4 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/contrib
From: Spencer Oliver
Signed-off-by: Spencer Oliver
---
contrib/loaders/flash/armv4_5_cfi_intel_16.s| 57 +
contrib/loaders/flash/armv4_5_cfi_intel_32.s| 57 +
contrib/loaders/flash/armv4_5_cfi_intel_8.s | 57 +
contrib/loaders/fl
Hi all,
I have run into one interesting issue, so I was hoping that somebody
could help me understand the problem.
My SoC has JTAG with no SRST (just TRST), and system reset can be done
in two ways :
1) mechanically, by pressing the reset button
2) writing one byte to dedicated SOC_RESET register
On 2010/12/10 18:46, Spencer Oliver wrote:
Not looked into it but why do we not just duplicate the existing
unregister event/timer functions - or are they broken aswell?
They (the target versions) don't appear to have the same problem. The
only difference I can see is that the jtag_unregist
On 09/12/2010 10:02, Luca Ottaviano wrote:
Nitpicking comment: you should also add
buf[buf_size - 1] = '\0';
before the end of the function, as snprintf() doesn't guarantee that if
you print more than buf_size chars.
Regards,
True, i will look at a solution that fixes the issue throughout o
On 2010/12/10 17:34, Øyvind Harboe wrote:
I think optimizing for testability & readability is the way to go here.
Especially considering the evidence that this code doesn't get tested
a whole lot
I can verify that both solutions work.
I'm OK with whichever solution you guys choose since y
The arm926ejs provides the RTCK . I do not know if you device and/or
board provide RTCK. Please verify or let us know your board schematic.
If your board and device support RTCK :
So, try to use a recent OpenOCD from git, and use the RTCK feature of
the Amontec JTAGkey-2.
With using the Amont
On 10/12/2010 08:34, Øyvind Harboe wrote:
On Fri, Dec 10, 2010 at 9:28 AM, Peter Stuge wrote:
Øyvind Harboe wrote:
Two versions attached.
I'll leave it to you to decide which is the best way to
implement this
I prefer the longer but simpler to read one. Were it mostly a smaller
my own proj
On Fri, Dec 10, 2010 at 9:28 AM, Peter Stuge wrote:
> Øyvind Harboe wrote:
>> > Two versions attached.
>>
>> I'll leave it to you to decide which is the best way to
>> implement this
>
> I prefer the longer but simpler to read one. Were it mostly a smaller
> my own project then I'd gone with the s
Hi everyone,
At 07:38 10/12/2010 +0100, Peter Stuge wrote:
Tomek CEDRO wrote: (replying to Nick Pelling)
> > I've asked Samsung for documentation listing all its JTAG codes,
> > but that may take some time to
>
> Hello Nick, the other problem is that Samsung may want you to sign the
> NDA and ke
Øyvind Harboe wrote:
> > Two versions attached.
>
> I'll leave it to you to decide which is the best way to
> implement this
I prefer the longer but simpler to read one. Were it mostly a smaller
my own project then I'd gone with the shorter one.
> and to incorporate any feedback.
I doubt anyon
21 matches
Mail list logo
