Thanks so far. You are right, to me the RTCK signal was somehow out of
sight. I added a loop that checks for the correct change on the RTCK
line and there is the feedback. It will receive some improvements but my
SIGSEGV problem is still there.
I compiled it with uClibc as part of an buildroot environment. Running
openocd from gdb with a well formed config file results in:
Info: JTAG device found: 0x0792603f (Manufacturer: 0x01f, Part:
0x7926, Version: 0x0)
Program received signal SIGSEGV, Segmentation fault.
0x000519ec in interface_jtag_add_dr_out (device_num=0, num_fields=0,
num_bits=0x2, value=0xf1040, end_state=TAP_RTI) at jtag.c:721
721 (*last_cmd)->cmd.scan->ir_scan = 0;
To me this output says allmost nothing, as the assignement is not the
first on a newly created structure. So I did an strace with the same
configuration. In fact ioctl calls are failing.
After taking a deeper look to the code I found that "fopen" calls for
the configuration files like this fail:
char const *mode="r";
fp = fopen(full_path, mode);
Calls like this work with *uClibc*.
fp = fopen(full_path, O_RDONLY);
Anyone any reasonable solution?
akuehn
Duane Ellis wrote:
> 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
