Debugging two LPC21XX chips

Development Boards MicroMod
1

I’ve been using OpenOcd very successfully on an LPC2103. I’m using Debian Linux with a 2.6.8.3 kernel.

Now I need to connect the LPC2103 to its spi host, an LPC2148.

In theory it looks like I could chain the JTAG ports, but what the wiring would look like is a big question mark.

I’ve been using the parport Jtag but I also bought an Amontec USB dongle with the idea that it may be simpler to use two interfaces than try to chain from one. I don’t mind getting another Amontec dongle if that would make things easier, but will the USB driver allow that?

Has anyone tried to debug two processors using OpenOcd and any combination of Jtag interfaces? Thanks.

2

Hi David,

if you want to daisy-chain the two devices, you have to connect TCK, TMS, nTRST and nSRST in parallel, while you chain TDI and TDO like this:

JTAG-port-TDI → TDI-target#1-TDO → TDI-target#0-TDO → JTAG-port-TDO.

The Amontec JTAGkey should be able to drive two chips in parallel with no problems, a parallel port dongle could have problems.

In the .cfg file, you have to define two jtag_device entries. The first one refers to the one closest to the JTAG-port’s TDO. The target’s should then reference chain-pos 0 and chain-pos 1.

Using the OpenOCD this way isn’t tested very well, but basically it should work, and I believe I’ve already received some sucess stories on this topic.

Using two JTAG interface would be possible, too. If you’re using two USB interfaces you can identify them using their serial number - if Amontec doesn’t ship them with unique serials (I only have one -key and one -key tiny) you would have to rewrite the EEPROM, but that’s easily possible.

Best regards,

Dominic

3

Hi Smead,

You touch a limitation of the OpenOCD but not of the Amontec JTAGkey.

In fact, OpenOCD does not support the simultaneous debug of two processor in the same JTAG chain.

When starting an intance of OpenOCD JTAG server, the debug process is defined the .cfg. In the .cfg file you define which processor do you want to touch. The others processor in the same JTAG chain will be put in their bypass JTAG mode.

If you really need to debug two processors simultaneous, you have:

  • to split the JTAG chain in two independant JTAG chain and connect two Amontec JTAGkey and start two OpenOCD instance.

We could think to modify the OpenOCD for allowing multiple simultaneous debug, but this is not realistic . But the Amontec JTAGkey is ready for this kind of task.

For simultaneous debug, the best I can suggest you is to split your JTAG chain, use two Amontec JTAGkey and start two instance of OpenOCD.

Laurent

http://www.amontec.com

4

Hello Laurent,

it’s possible to define more than one ‘target …’ in the .cfg file, each talking to a different processor:

#jtag scan chain

#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)

jtag_device 4 0x1 0xf 0xe

jtag_device 4 0x1 0xf 0xe

#target arm7tdmi

target arm7tdmi little run_and_halt 0

target arm7tdmi little run_and_halt 1

A GDB port will be created for each target defined, but only one telnet session will be available. Within that telnet session you can choose which processor you want to talk with using the “targets [num]” command, without an argument the list of configured targets will be displayed.

There could be some bugs hidden somewhere, because this setup is rarely used, but there’s no fundamental restriction that would stop the OpenOCD from controlling two cores on the same time.

Best regards,

Dominic

5

All Amontec JTAGkey and JTAGkey-Tiny comes with a different Serial number.

Also, you may start an OpenOCD instance with the first JTAGkey serial number and start an other OpenOCD with the other JTAGkey Serial Number.

Note: We have tested the JTAGkey with 8 devices in the same chain. It works because the JTAGkey comes with big output buffer, 30mA. The JTAGkey-Tiny comes with 8mA output buffer → 1-2 device in the same chain.

Hoping this help.

Regards,

Laurent

http://www.amontec.com

6

Good advice from you Dominic,

I will try the the “targets [num]” command tommorow morning with two processor in the same JTAG chain.

I never try this!

GREAT!

Laurent

7

I’ve certainly experienced a number of issues with this, some caused by the design of OpenOCD and some I expect caused by (the ever present) bugs. I’ve managed to bypass most of these, but some are still causing real problems for me.

I have a board with three 2103s on it, one acting as a master for the other two. I use the target specifiers as outlined by Dominic to address individual targets.

Now for the issues.

First of all, flash programming. For a single target in the chain, this works fine simply adding a "target_script 0 reset oocd_update_2xxx.script

" command to the cfg file. However, with mutiple targets, the script gets run for every chip even though it specifies a target of 0 and thus shouldn’t run for the other targets.

I solved this by writing a simple TCP/IP script that issues the relevant flash programming commands to port 4444 and not using the (in my view broken) reset script mechanism.

Secondly, multiple target debugging.

This just doesn’t work. Reliably. I’ve been able to debug a target for several seconds, or in some instances, minutes, but eventually it will fail with an error that the wrong status was read from the target. This happens if either or both the other two targets are running, but not normally if they are halted.

If I start them up using the run_and_halt option on the target config line, then connect to OpenOCD and start one of the targets running it mostly works - but of course the other processors are then halted and thus cannot be tested. However, if I then connect to port 4444 and issue a command to start either of the other targets running, the first instance will either stop immediately or very soon thereafter.

It’s a bit bizarre because the JTAG chain does work just fine for programming the flash memory, but then again, the targets are all halted during this process. So it does look like a software issue somewhere in OpenOCD.

I can supply more info if anyone wants to follow this up.

I ended up putting a large connector on my board that allowed me to link the JTAG chain up to connect one or more targets together for the debug of the day! This works for me but it is hardly neat. And it costs me an extra $5 for a connector that I don’t really need…

8

kanoop,

Some of your comments are a bit harsh, a lot of people are working hard to make openocd reliable - it is free remember!

The more feedback we have from users helps this, config file, debug log, version etc may be a bit more helpful.

Have you tried debugging the problem from the openocd source?

As Dominic said not many people use this setup, this is probably why there are still a few bugs present.

Regards

Spen

9

Thanks for saying that, Spen. It’s exactly the reason why I didn’t reply yet…

it is free remember!

Most importantly it's free in more than one way. The usual "free as in gratis" (formerly beer), but it also comes with full sourcecode and a license that allows you to modify it in any way you want (as long as you follow a few simple rules).

One thing that comes to my mind with debugging multiple LPC2xxx cores is the lack of RTCK support. The ARM7TDMI-S (note the -S) requires TCK to be synchronized to the core clock. This limits the maximum JTAG frequency to 1/6th of the core frequency in case of a single target. Chances are that multiple cores in the chain make this problem even worse.

Regards,

Dominic

10

Apologies if my comments came across as harsh, I was merely trying to save “smead” some time going over the same ground that I’ve been going over in the last year or so, by highligting that there are issues and it’s not necessarily plain sailing.

I’ve been down the route of TCK sync, but as long as the clock frequency is kept below 1/6, it makes no difference. I.e. dropping the clock rate to well below this still fails in about the same timeframe.

I’ve had the same issue with a board with a Xilinx FPGA in the same chain as a LPC2134. So, it is not necessarily to do with multiple LPCs, just multiple devices.

Anyway, if you have the inclination to investigate further, I’ll be happy to send you one of my production boards with three 2103s on it, to play with.

11

Heh, allright. If there’s a problem I’d definitely like to see this solved.

I can’t promise any timeframe, but if you’re able to provide me with a board to test with I’ll look into these issues. You can contact me by mail at Dominic Rath gmx de.

Regards,

Dominic