Ferdinand,
Using two patches, (yours + mine) I have "reset halt" and "reset run"
working reliably for the jlink dongle. While "reset init" works sometimes I
am finding the command can cause the jlink dongle to permanently lose
communication in some cases:
reset init
JTAG tap: at91sam9260.cpu tap/device found: 0x0792603f (mfg: 0x01f, part:
0x7926, ver: 0x0)
JTAG Tap/device matched
target state: halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x000000d3 pc: 0x00000000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
8 kHz
WARNING: unknown debug reason: 0x0
invalid mode value encountered 0
cpsr contains invalid mode value - communication failure
Runtime error, file
"/usr/local/openocd-config/target/unknown-board-atmel-at91sam9260.cfg", line
3:
WARNING: unknown debug reason: 0x0
invalid mode value encountered 0
cpsr contains invalid mode value - communication failure
WARNING: unknown debug reason: 0x0
invalid mode value encountered 0
cpsr contains invalid mode value - communication failure
invalid mode value encountered 30
cpsr contains invalid mode value - communication failure
invalid mode value encountered 0
cpsr contains invalid mode value - communication failure
.
.
.
You have a different type of dongle so I am curious whether you see this
problem as well. Knowing this will help me narrow the problem down further.
Thanks,
Gary
On 8/6/09 2:48 PM, "Ferdinand Postema" <ferdin...@postema.eu> wrote:
> ==> How did you discover this fix?
>
> First I tried if the breakpoint version worked. It did.Then I inserted
> some commands to read back the vector catch register, to see if it was
> writen correctly. Then the vector catch worked! Then I tried a couple of
> things to see what was minimal neccesary. I tried waiting for 100000 us,
> but that did not work. Then I tried the extra cycle in state TEST
> RUN/IDLE and that worked. I think this should not influence other
> targets. It's just one extra cycle of doing nothing before the reset. I
> think it can be committed.
>
> Gary Carlson schreef:
>> On 8/6/09 2:14 PM, "Ferdinand Postema" <ferdin...@postema.eu> wrote:
>>
>>
>>> I found a solution to my problem. It seems that this module needs one
>>> clock cycle in state RUN TEST/IDLE between the setting of the vector
>>> catch and the reset. Then it works perfectly. I tested it with the
>>> RTCK-feature and on 1 kHz, 2 kHz and 4 kHz. It didn't work at 8kHz,
>>> because the chip clock falls back to 32 kHz at reset. I have attached a
>>> patch file to include the extra cycle in state RUN TEST/IDLE.
>>>
>>> Ferdinand Postema schreef:
>>> Index: src/target/arm7_9_common.c
>>> ===================================================================
>>> --- src/target/arm7_9_common.c (revision 2571)
>>> +++ src/target/arm7_9_common.c (working copy)
>>> @@ -1015,6 +1015,7 @@
>>> {
>>>
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
