Suitable JTAG for DM320?

I am looking for a simple JTAG do-hickey to connect between my PC and a PVR running a TI TMS320DM320 chip. The device was sent to me “as dead”, suspecting that a flash upgrade failed and trashed anything useful in the onboard Flash. The hardware is open, I have access to the schematics. There is a JTAG port. It runs at 3.3V. I hope there is no special procedure to invoke JTAG on the CPU end because god know what, if anything, is in the flash…

There are many of these sorts of devices on eBay – http://cgi.ebay.fr/ws/eBayISAPI.dll?ViewItem&item=400546690397 – looks to be a “Ulink 2” (or clone of such). Would this be suitable for resurrecting the device and/or playing around with the hardware at a comfy low level? ;-)

The official ARM info page suggests that it will work on a host running from ~2.7 to 5.5V, so I am guessing this rules out the Beagle and the Pi? They run at 1.8V, right?
Still, if it only works with the PVR, it’ll be okay for this thingy costs ~€12 (inc. postage!).

I have (somewhere!) a parallel port JTAG dongle, but never used that due to the fact that I rarely use a machine with an actual parallel port fitted (ditto serial port; I really ought to get a USB to serial adaptor so I can kick the bootloader if necessary), and the USB parallel port that I have is extremely single-purpose (it will talk to a printer in its most basic mode, nothing fancy).

The Pi’s GPIO & I2C are 3v3. I don’t know about the JTAG http://elinux.org/RPi_Hardware doesn’t illuminate:-(
I’d suspect the JTAG IS 3v3 but I offer no warranty!

A “proper” JTAG programmer has a VREF pin that you connect to the voltage you want to drive, and there are level shifters on it that set up the voltages to be the right level. So in your case you just connect VREF to 3.3V and you’re good to go. If the PVR has a 10-way JTAG header onboard then likely it’s already wired correctly (but check, there are a variety of pinouts out there).

The Pi can act as a JTAG programmer itself (in Linux): here is one example.
It isn’t a ‘proper’ programmer because it doesn’t have the level shifter, but doesn’t matter because your PVR is also 3.3V. You just wire up GPIOs to act as a JTAG master (don’t get confused by the JTAG slave inputs to the BCM2835 and the ethernet chip, they’re irrelevant in this discussion).

Then it’s ‘just’ a software problem. Do you have a flash programmer program for your device? Something like OpenOCD (in the above link) may do it, but it depends on the flash chip and how it is wired (for example, do you have to get at the flash via the CPU and if so what do you do). Like most the ebay programmer is probably just a pile of a GPIOs in a box, but it claims it’s compatible with ARM’s RealView – if you have those tools it may be easier.

I would start by identifying what software you want to use and then working out what programmer to use with it. OpenOCD is a good place to start.

Shouldn’t a problem if the flash is full of garbage – JTAG overrides whatever the CPU is doing.

I don’t know about the JTAG http://elinux.org/RPi_Hardware doesn’t illuminate:-(

It does have links to the schematics though for those that read pictures. :-)

I’d suspect the JTAG IS 3v3 but I offer no warranty!

Well me neither, but I tend not to argue with schematics (top right, page 4)

The Pi can act as a JTAG programmer itself […] You just wire up GPIOs to act as a JTAG master […]

Now there is an idea I hadn’t thought of. Bit banging JTAG from the GPIO.

Anybody already done anything like this under RISC OS?

JTAG is very difficult to do from scratch. You really need to start from some software that is known to work, specifically supporting the device(s) you intend to work with.

Once you’ve decided on the software, see what hardware it works with.

Indeed. JTAG is a stack like, say, networking. You can write an ethernet driver but it doesn’t mean Facebook then automatically works.

The basic operations and interface are standardised, but most of the interesting stuff is via vendor-specific extensions. In addition, you may have to do things indirectly. For example, usually flash chips don’t have JTAG ports themselves. But you can get in to the CPU JTAG port and use that to wiggle the pins on the outside of the CPU, which just happen to be the pins connected to the flash chip. So you need layers of code that:

• Drive the JTAG TAP protocol
• Know how to wiggle the CPU pins (this bit is standardised, though you’ll need a pin map file for your CPU)
• Know which CPU pins are wired to which flash pins (board-specific, the schematic will come in handy)
• Know how to configure the flash chip for writing (flash-specific)

These layers are a lot simpler than an IP stack, but there’s a lot less standardisation.

Porting one of the open-source tools might get you that, but I wouldn’t try writing it from scratch simply because you probably don’t have a few dozen different boards to debug with.

Once you’ve decided on the software, see what hardware it works with.

Having never used JTAG, I only have a rough idea of what it is supposed to do, therefore my current criteria is “as inexpensive as possible”.

You really need to start from some software that is known to work,

Yes, that would be sensible…
…a word people don’t tend to use when referring to me. ;-)

JTAG is very difficult to do from scratch.

Let’s see:

• I have no sources to look at (and wouldn’t want to base any of my code on any part of a GPL project), only a spec of the JTAG data format.
• I have no real idea of what JTAG can actually do, just a vague idea of the concepts involved.
• I would be bit-banging from a selection of GPIO pins; this is bare metal JTAGing.
• I have a suspicion that assuming the device works the JTAG interface will either work or it won’t, and if it doesn’t there is no reasonable way to discover why.
• But the assumption above is because the dead PVR is exactly that. Dead. Most likely a failed flash update, but just as easily could be “wrong polarity power inserted” or everybody’s favourite – random static electricity damage. Nothing is certain, even the power LED is controlled by software.
• I’m sure as hell NOT going to do dev work using the working PVR. I could use the cheapy Chinese one (same chip) but schematics are not available so I don’t know how the JTAG is wired up, or even if that 14 way socket is JTAG. [can’t think what else it would be, but…]
  
  

Which roughly translates to attempting to write some bit-banging software to a basic spec (and little other documentation) to use with a processor core that might not even work in the first place.

So, all in all…

…sounds like a piece of cake. [/sarcasm]

Theo:

for example, do you have to get at the flash via the CPU and if so what do you do

It is, to be honest, an unholy mess baked into a hacked-about version of u-boot. Something is very seriously wrong as the flash programming takes forever.
The fun stuff is here: https://svn2.neurostechnology.com/neuros-bsp/trunk/bootloader/board/ntosd-dm320/ [may cause a security exception due to mucked up certificate (*.geekisp.com)!] and the flash.c source is where the good stuff happens – the code is a bit icky and calls udelay(100) for each word written to flash (seems a bit excessive, no?).

When the device starts, the hacked uboot looks for a media device and then looks for a specific file. If the specific file exists, it is flashed. While this sounds good, the fly in the ointment is that the bootloader itself can be flashed (following a full flash erase). If this part fails, you’re looking at a brick.

What I as hoping, to be honest, is just to poke the bootloader into RAM (hopefully as it should appear following start-up) and start it running. It should detect the update file and do the rest… However, just to be clear, this is theory. Reality will probably differ. A lot. (^_^)

Know how to wiggle the CPU pins

Couldn’t you alternatively poke in the code to program the flash and set that running instead of wiggling directly?

While I’m here, is there any sort of test I could try with a multimeter to see if the chip is, in fact, working?
Flash/RAM is separate, not a Pi-style PoP, so I can probe the pins.
Would looking at !CS on the Flash be a start? I assume it’d go (active) low for reading the code? If the flash blanks to all byte &FF, that is a SWINV, so it may be that it just reads from flash over and over until it fails/wraps?

If it helps, the schematic is here: https://web.archive.org/web/20120818014423/http://open.neurostechnology.com/files/r3_rev-b_2006-07-02-0713-1.pdf

Just had a look, the init code copies the bootloader into RAM at start: https://svn2.neurostechnology.com/neuros-bsp/trunk/bootloader/cpu/arm926ejs/start.S
So the theory at least is to bung that into the correct part of RAM, set the CPU state and registers according to the start.S code (IRQ/FIQ stack, and so on) and then jump to the bootloader code and run it.

If it helps, the schematic is here: https://web.archive.org/web/20120818014423/http://open.neurostechnology.com/files/r3_rev-b_2006-07-02-0713-1.pdf

The schematic seems to suggest this is the flash device http://datasheet.elcodis.com/pdf2/76/39/763907/s29jl064h90tfi00.pdf
page 33 – 35 probably of particular interest for you.

It probably won’t surprise you that the Spansion manufacture runs are post normal lifetime production – i.e. the part is a bit old…

Rick, how can I put this to you… you can spend the next few years of your life, on a full time basis, trying to get the thing to work, if you’re just starting from scratch. I’ve done some stuff with JTAG; I used to have a copy of the IEEE standard. When you consider the layers involved, each of which is quite complicated, and you probebly don’t have the test equipment to test each layer separately… you’re looking at a task that is beyond the reach of most clever people.

The basic communication protocol of JTAG is a non-trivial state machine.

You have to know the length of the JTAG chain. You may be lucky and find it’s only the CPU.

You have to know the device’s JTAG chain: how many elements, which type each element is, which pin each is connected to.

If you’ve got that far: all you have achieved is the ability to wiggle the device’s pins and read back from them. Note that dealing with the direction of three-state pins is entirely up to you, so you have to go to some lengths to avoid contention, otherwise you’ll do damage to the chips – if you read from the flash, make sure the CPU’s data bus is set to input, fo example.

Then you have to deal with the protocol to write to the flash device. That’s also non-trivial.

Basically, if you go ahead on a bare metal basis: you’re heading for failure.

I’m agreeing with everything that Theo said in his post. But I’m also pointing out that bare metal is a monumental task; even using ready-cooked software and a JTAG interface, it’s still a non-trivial task.

Rick, how can I put this to you…

…I’ve read up on it. Let’s say rewriting the Wimp to use pre-emption would likely be simpler. Eek, it’s… likely to take me years to understand it.

Looks like the ULinkII will be a non-starter. It appears to be proprietary.

For those that say I should pick the software first – I don’t know what software. It’s a TI chip¹ with an ARM926 inside, I want to poke around in the processor, paste some code into RAM, etc. The sort of stuff you might think of doing with an emulator/debugger. I’m not interested in the boundary scan stuff, or the direct pin wiggling. The device can flash itself from code, so all I need to do it get that code onboard.

Plus breakpoints/register tweaking/code stepping/etc ‘cos you know I’ll want to play with it. ;-)

I may poke around and see if I can get the Pi/GPIO version of OCD running. [edit: oh good, it looks like it won’t interfere with the CJE RTC add-on] That’s probably the least expensive option… Thanks, Theo, for the link.

Rick, how can I put this to you…

Hmmm, there are people around that take that as a sort red rag —> bull.

In this case Rick may go rather quiet for a while.