Hi,is there anybody, who is working with the GNU tools running under Linux and using the Chameleon or Raven JTAG interface? I tried to do this, but I couldn’t connect to the target. I’m using Chameleon interface together with OCDLibRemote and GNU gdb 6.1-macraigor2. When I connect to the target using ‘target remote localhost:8888’ I get following output from OCDLibRemote: CPU[1] Accepted gdb connection on port 8888. ReadRegister Error(0, 1): ret c Processor Running ReadRegister Error(1, 2): ret c Processor Running ReadRegister Error(2, 3): ret c Processor Running ReadRegister Error(3, 4): ret c Processor Running ReadRegister Error(4, 5): ret c Processor Running ReadRegister Error(5, 6): ret c Processor Running ReadRegister Error(6, 7): ret c Processor Running ReadRegister Error(7, 8): ret c Processor Running ReadRegister Error(8, 9): ret c Processor Running ReadRegister Error(9, a): ret c Processor Running ReadRegister Error(a, b): ret c Processor Running ReadRegister Error(b, c): ret c Processor Running ReadRegister Error(c, d): ret c Processor Running ReadRegister Error(d, e): ret c Processor Running ReadRegister Error(e, f): ret c Processor Running ReadRegister Error(f, 10): ret c Processor Running ReadRegister Error(19, 0): ret c Processor Running Running under Windows there are no problems. I get a similar output under Windows when the board is not powered. Regards, Manfred
Hi Manfred The problems are due to the Linux port using the device in little endian mode and a JTAG bug in OCDLibRemote when the device is in this mode on the Netsilicon devices… This problem was unknown to Netsilicon until one of their application engineers sat with me for two days as we tried to get Raven and insight debugger to work on my HW in little endian mode… this was way back in May/June 2003 and it sounds like it still hasn’t been fixed… As I wasn’t using Linux, in the end I just switched to big endian mode as the GNU tools and Raven / OCDLibRemote do work in this mode… and lets face it if your are doing TCPIP work big endian increases your performance as this is the network byte order… For little endian mode you need an interface like Jeeni… Netsilicon loaned me one of these for a while and it does work with little endian mode and the gnu tools… Regards, Dave
yes, I’m using Net+OS in big endian mode. Sorry for the confusion. Regards, Manfred
… having now re-read the original post… I think I’ve made some bad assumptions ;-)… I assumed you were using Linux on the target and hence that you were using little endian mode… as you can make it work on Windows I suspect you are using Net-OS and the device is in big endian mode? in which case my previous post is crap… sorry BBFN Dave
I am working on UNC20 with NET+OS and JTAG under windows environment.I am facing the same problem. While loading software to target following error occurs.
Started listening socket on port 8888.
OcdLibRemote NetSilicon: RAVEN via LPT 2 at speed : 1
Accepted gdb connection.
ReadRegister Error(0, 1): ret 1 Processor Running
ReadRegister Error(1, 2): ret 1 Processor Running
ReadRegister Error(2, 3): ret 1 Processor Running
ReadRegister Error(3, 4): ret 1 Processor Running
ReadRegister Error(4, 5): ret 1 Processor Running
ReadRegister Error(5, 6): ret 1 Processor Running
ReadRegister Error(6, 7): ret 1 Processor Running
ReadRegister Error(7, 8): ret 1 Processor Running
ReadRegister Error(8, 9): ret 1 Processor Running
ReadRegister Error(9, a): ret 1 Processor Running
ReadRegister Error(a, b): ret 1 Processor Running
ReadRegister Error(b, c): ret 1 Processor Running
ReadRegister Error(c, d): ret 1 Processor Running
ReadRegister Error(d, e): ret 1 Processor Running
ReadRegister Error(e, f): ret 1 Processor Running
ReadRegister Error(f, 10): ret 1 Processor Running
ReadRegister Error(19, 0): ret 1 Processor Running
WriteRegister Error(0x0, 0x1[1]) : Processor Running
WriteRegister Error(0x1, 0x2[2]) : Processor Running
WriteRegister Error(0x2, 0x3[3]) : Processor Running
WriteRegister Error(0x3, 0x4[4]) : Processor Running
WriteRegister Error(0x4, 0x5[5]) : Processor Running
WriteRegister Error(0x5, 0x6[6]) : Processor Running
WriteRegister Error(0x6, 0x7[7]) : Processor Running
WriteRegister Error(0x7, 0x8[8]) : Processor Running
WriteRegister Error(0x8, 0x9[9]) : Processor Running
WriteRegister Error(0x9, 0xa[10]) : Processor Running
WriteRegister Error(0xa, 0xb[11]) : Processor Running
WriteRegister Error(0xb, 0xc[12]) : Processor Running
WriteRegister Error(0xc, 0xd[13]) : Processor Running
Please help.
Regards,
Gouri
Im working on UNC20 (ConnectCore 7U) under Windows too, but I’ve never seen this problem. I’m using Net+OS 7.1.1.
The ‘Processor running’ messages do sort of ring a bell though. Normally, when the JTAG is connected and enabled, I thought the processor should be in a stopped state unless the JTAG allows it to run. I’ve noticed that this is not always the case: sometimes the module just boots when you apply power.
I’ve also seen unexpected (and often incomplete, ending in garbage) error messages out of the serial port while I thought the processor ought to be in a stopped state. I can’t pinpoint the exact times it happened because I always noticed the output in the log window only a little while after it must have appeared, but as far as I can tell it always happened when an image was uploaded to RAM over the JTAG link.
Something else that might be related: I’ve got two UNCBAS development boards (one on loan from Digi and one I bought). The most recent one came with an extra little adapter between the JTAG module and the UNCBAS, the other didn’t. For the rest, the two kits seem fully identical hardware-wise.
I’ve asked Digi what the extra adapter is for and how important it is, but nobody seems to know (the answers I did get indicate that they simply don’t know what’adapter I’m talking about, as if they’ve never seen it). Tracing the PCB layout, it seems to be nothing but a single gate that buffers the TCK signal (single 2-input AND gate in SOT23, one input to TCK at JTAG, other input to power supply, output to TCK at module).
However, I haven’t seen your problem either with or without the adapter.
I thought maybe the JTAG was disabled on your development board (jumper on pins 1 and 2 of J1 removed, assuming you’re using an UNCBAS), but when I just tried that I got another error message from the debugger: “TCK (pin 9) low, but should be high” without the extra adapter in the JTAG link, and “Bad JTAG communication: Write to IR: Expected 0x1, got 0x7” along with some other messages with the adapter in place.
Message was edited by: lucvdv
Fixed a typo (SOT23 instead of SOT32)