Andreas Kuehn wrote
> In fact, its a timing problem. I added some LOG_DEBUG lines to the code
> and all Warnings dissapeared when running with -d1 or higher.
> Unfortunately uClibc has some drawbacks regarding timer stuff which I
> desperately need for dealing with the different processor speeds.
> BACKGROUND: openocd runs at 200MHz (at91sam9263) and has to connect to
> another at91sam9263 which runs at 32kHz after startup. TCK has to be
> slower than 32kHz/6 = 5.45kHz. As a result, I have to waste time while
> pushing jtag signals. Currently, I use the usleep call to waste the
> time, pushing the TCK frequency down to 33Hz. ?-]
>
What you really need is "RTCK" support - which I believe the sam9263
has, and you can supply with your JTAG interface.
See Section 21 - FAQ in the *NEW* openocd manual, look at the "battery
powered hand held device" example.
http://openocd.berlios.de/doc/FAQ.html#FAQ
Here's the trick:
When the SAM series parts are running on SLOW_CLK (32khz) - the RTCK
signal will also respond @ 32kzh.
That is what you need to talk slow your actions down.
At *SOME*POINT* - your targets are running *SO* fast - that - the test
to support RTCK is stupid and actually slows down transfers.
You could - in your custom adapted driver - do the following:
(1) If the JTAG timing is ZERO - look for the RTCK signal.
use slow stupid code that must poll the RTCK bit.
(2) Later, once you have configured the at91SAM - sys block (where
the plls are)
you can execute the command to use a NON-ZERO rtck clock.
(3) At that point - your test delays should be just fine. In fact.
I doubt you even need to do any test, because the targets will
be going *SO*FAST* it does not mater.
-Duane.
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
