Hi Gary,
I was a little bit conservative with the frequency. The following quote
is taken from the datasheet of the AT91SAM9260:
"Note the maximum JTAG clock rate on ARM926EJ-S cores is 1/6th the clock
of the CPU. This gives 5.45 kHz maximum initial JTAG clock rate for an
ARM9E running from the 32.768 kHz slow clock."
The following quote is taken from the OpenOCD Users Guide:
"6.2.4 JTAG Clock Rate
Before your reset-init handler has set up the PLLs and clocking, you may
need to use a low JTAG clock rate; then you'd increase it later. (The
rule of thumb for ARM-based processors is 1/8 the CPU clock.) If the
board supports adaptive clocking, use the jtag_rclk command, in case
your board is used with JTAG adapter which also supports it. Otherwise
use jtag_khz. Set the slow rate at the beginning of the reset sequence,
and the faster rate as soon as the clocks are at full speed."
So, I suggest a jtag speed of 4 kHz, or adaptive clocking.
Ferdinand
Hi Gary,
I think the 8 kHz is the problem here. I have read somewhere that the
CPU speed must be 16 times faster than the jtag speed for reliable
operation.
This means that with a 32 kHz clock, the jtag speed must be 2 kHz, or
lower. I have tried myself and it seems to work correctly at 4 kHz and
lower. So 2 kHz is on the safe side. I tried 8 kHz and then the system
was not stable. Every time I got different errors.
For interfaces with RTCK functionality, I can recommend this feature. It
works perfectly for me. With this feature enabled you don't need to
switch the jtag speed during a reset. It is much faster with these slow
clock frequencies.
So, I recomment that this script is changed. 8kHz should be replaced
with 2 kHz for reliable operation under all circumstances.
It would be nice if the script detects if the RTCK feature is enabled.
If it is, no switching of the jtag speed should take place.
Ferdinand
Gary Carlson schreef:
> 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
