Re: [Openocd-development] Unexpected idcode causing SIGSEGV ?

[Rick Altherr]

On Dec 15, 2008, at 8:32 AM, Andreas Kuehn wrote:

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;

This looks a lot like the "command structure not aligned" bug that was resolved a few weeks ago. What SVN revision of OpenOCD are you compiling?

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);

If the fopen() failed, OpenOCD would not be able to read the config file at all. That would mean that the JTAG interface and device chain would not be configured which would cause OpenOCD to complain and fail to run (try running openocd with -c 'init' to see what I mean). I suspect the implementation of fopen() in uClibc is attempting to do an ioctl that is supported only on some systems but uses a fallback method if it fails. In other words, this appears to be a red herring.

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.

desperately need for dealing with the different processor speeds.

another at91sam9263 which runs at 32kHz after startup. TCK has to be

pushing jtag signals. Currently, I use the usleep call to waste the
time, pushing the TCK frequency down to 33Hz. ?-]

Unfortunately uClibc has some drawbacks regarding timer stuff which I BACKGROUND: openocd runs at 200MHz (at91sam9263) and has to connect to slower than 32kHz/6 = 5.45kHz. As a result, I have to waste time while

What you really need is "RTCK" support - which I believe the sam9263
has, and you can supply with your JTAG interface.


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.


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.


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.

See Section 21 - FAQ in the *NEW* openocd manual, look at the "battery At *SOME*POINT* - your targets are running *SO* fast - that - the test (2) Later, once you have configured the at91SAM - sys block (where

_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

--
Rick Altherr
kc8...@kc8apf.net


 -- Unsigned

"He said he hadn't had a byte in three days. I had a short, so I split it with him."

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development