Hello Dominic,

Thank you for looking into the problem. I am pleased that you were able to identify a patch so quickly. I have not yet had a chance to patch R141 and test it but I should be able to get to it later on today. I just checked the revision number of the OpenOCD repository and I see that it is still at 141. I will let you know what I find.

I have completed my initial development on the internal RAM and external SDRAM projects for the 3180. Initializing the SDRAM controller using OpenOCD commands was an interesting exercise. I want to complete the testing and documentation today and post these. I have yet to have a close look at your sample code to see how the work can be pulled together. That too, will come today or shortly.

Thanks again.

Cheers,
Peter

Hello Peter,
>
>following up on my last mail, here's what I found out about the problem you're
>seeing:
>
>There seems to be a problem specific to the ARM926EJ-S (I've been able to
>verify the problem exists on a AT91SAM9260, too) that causes the TAP
>controller to fail after accessing the CP15 coprocessor via JTAG. Just
>selecting and deselecting the CP15 scan-chain (15) doesn't cause a problem,
>but executing a CP15 operation like reading the ID register results in wrong
>data (all bits '1' or '0') being output on TDO during the next IR scan. The
>ARM manual doesn't contain any information on this problem.
>
>Notwithstanding the wrong output, the data input through TDI is correctly read
>and the desired instruction gets selected. This can be verified by examining
>the value returned during a SCAN_N data register scan - the fixed pattern
>b10000 is returned fine.
>
>The reason why this didn't cause problems using a FT2232 based dongle but
>caused the Wiggler to fail is that the JTAG queue handling code was slightly
>different. The FT2232 just reported the error, and continued, whereas the
>Wiggler aborted queue execution after a check failed.
>
>Currently this seems to be the ARM926EJ-S' fault, as the underlying JTAG
>operations are very basic, and the failure is easily reproducable. I've
>written a workaround that executes a dummy IR scan on every CP15 operation,
>but of course this isn't an ideal solution. I'll see if I can find more
>information on this problem, but until then the workaround has to be enough.
>
>Unfortunately the Berlios system is down at the moment, so I can't commit my
>changes to the SVN server. You can find a patch against R141 at
>http://mmd.ath.cx/openocd/openocd_20070423_0.patch
>This should allow you to work with both Wigglers and FT2232 based dongles.
>
>Regards,
>
>Dominic Rath
>
>On Saturday 21 April 2007 11:52:00 Dominic Rath wrote:
>> Hello Peter,
>>
>> On Friday 20 April 2007 20:49:02 p...@akamina.com wrote:
>> > This change cleans up the situation but the
>> > eventual fatal error caused by entering "monitor arm7_9 sw_bkpts enable"
>> > remains.
>>
>> I was wrong when I thought that soft_reset_halt and enable_sw_bkpts
>> wouldn't cause JTAG activity. The former is supposed to turn off the
>> caches, so it's fine that it accesses the JTAG interface, but the latter
>> one should be a NOP on ARM926EJ-S, as it implements the ARMv5TE
>> architecture which includes the BKPT instruction. I've fixed that bug
>> locally, and will commit it with the next set of changes.
>>
>> > Let me know if you find anything odd with your Wiggler tests.
>>
>> I'm basically seeing the same behaviour you're seeing - the OpenOCD exits
>> because of a fatal communication error. I'll have to look into this a bit
>> further.
>>
>> Meanwhile, you can find my LPC3180 example code at http://mmd.ath.cx/lpc/
>>
>> Best regards,
>>
>> Dominic Start a New Thread

Hello Dominic,

I just finished testing the latest version of OpenOCD (143) with the OLimex Wiggler and the LPC3180. It works perfectly. Thank you for the update.

Cheers,
Peter
> Hello Peter,
>
>following up on my last mail, here's what I found out about the problem you're
>seeing:
>
>There seems to be a problem specific to the ARM926EJ-S (I've been able to
>verify the problem exists on a AT91SAM9260, too) that causes the TAP
>controller to fail after accessing the CP15 coprocessor via JTAG. Just
>selecting and deselecting the CP15 scan-chain (15) doesn't cause a problem,
>but executing a CP15 operation like reading the ID register results in wrong
>data (all bits '1' or '0') being output on TDO during the next IR scan. The
>ARM manual doesn't contain any information on this problem.
>
>Notwithstanding the wrong output, the data input through TDI is correctly read
>and the desired instruction gets selected. This can be verified by examining
>the value returned during a SCAN_N data register scan - the fixed pattern
>b10000 is returned fine.
>
>The reason why this didn't cause problems using a FT2232 based dongle but
>caused the Wiggler to fail is that the JTAG queue handling code was slightly
>different. The FT2232 just reported the error, and continued, whereas the
>Wiggler aborted queue execution after a check failed.
>
>Currently this seems to be the ARM926EJ-S' fault, as the underlying JTAG
>operations are very basic, and the failure is easily reproducable. I've
>written a workaround that executes a dummy IR scan on every CP15 operation,
>but of course this isn't an ideal solution. I'll see if I can find more
>information on this problem, but until then the workaround has to be enough.
>
>Unfortunately the Berlios system is down at the moment, so I can't commit my
>changes to the SVN server. You can find a patch against R141 at
>http://mmd.ath.cx/openocd/openocd_20070423_0.patch
>This should allow you to work with both Wigglers and FT2232 based dongles.
>
>Regards,
>
>Dominic Rath Start a New Thread