How standardized is JTAG?

[jrmymllr]

This might be a dumb question. I need to read the memory contents out of an Analog Devices SHARC ADSP part. I don't have ADI's JTAG interface, but do have an old Luminary Stellaris JTAG interface that I've used with OpenOCD for other chips (for example hacking my Rigol scope). But OpenOCD doesn't have a support file for the ADSP.

I am just not familiar with JTAG at all. Are the signals standardized, but other parameters aren't? Is there any trivial way to get OpenOCD to work with the ADSP chip to pull RAM contents?

[ataradov]

Only the pins and some common basic subset of commands is standardized. The actual memory access is device-specific. And the debugger protocol is debugger-specific.

There is no trivial way to do that with OpenOCD, but it is not impossible. But if you only need it once, it might be easier to just do it from another MCU or Arduino or something like this. It depends on what other hardware you have on hand. It would be a very similar amount of effort, but you won't have to figure out internal OpenOCD plumbing.

[jrmymllr]

Only the pins and some common basic subset of commands is standardized. The actual memory access is device-specific. And the debugger protocol is debugger-specific.

There is no trivial way to do that with OpenOCD, but it is not impossible. But if you only need it once, it might be easier to just do it from another MCU or Arduino or something like this. It depends on what other hardware you have on hand. It would be a very similar amount of effort, but you won't have to figure out internal OpenOCD plumbing.

Thank you for clearing this up. Unfortunately I can't use another device as I'm troubleshooting this one specific device.

[ataradov]

No, I meant another device used as a JTAG adapter. Instead of using a standard JTAG hardware, connect another board to the JTAG pins and do whatever you need to the target device.

[nctnico]

No, I meant another device used as a JTAG adapter. Instead of using a standard JTAG hardware, connect another board to the JTAG pins and do whatever you need to the target device.

You'd still need to know how the device needs to be controlled (is that information even available?). An easier way might be to add basic memory read / write support to OpenOCD. At least you don't have to deal with getting a JTAG interface working from scratch and doing addressing.

My experience with JTAG has been so bad that I try to avoid it if I can.

[ataradov]

You'd still need to know how the device needs to be controlled (is that information even available?).

Sure, but without this information you can't modify OpenOCD either.

An easier way might be to add basic memory read / write support to OpenOCD. At least you don't have to deal with getting a JTAG interface working from scratch and doing addressing.

There is no standardized way to access memories over JTAG, so the only thing OpenOCD will save you is bit-banging a few pins. But on a down side you wold need to figure out how OpenOCD works internally. I'd pick bit-banging a few pins any time.

[SiliconWizard]

The low-level part of JTAG is standard, but each particular chip requires specific handling on top of it.

OpenOCD does support the ADSP-SC58x series. Look for the adsp-sc58x.cfg script. It's a SOC with embedded SHARC DSPs. So there might be enough support in OpenOCD for writing your own cfg file for your particular SHARC ADSP. I don't know those SHARC chips enough to be able to figure out exactly what would be required.

[NorthGuy]

JTAG is a protocol. The protocol is 100% standartized. But the commands you use are device-specific.

You can try to reverse-engineer it. You need to figure the size of the command, then you can send different commands and see if you get any non-trivial response and so on.

Or, you can try to find a BSDL file for your device which will list all the commands.

[ataradov]

If commands are not documented, BSDL files will not list them either.

But also, there seem to be a lot of variations between ADSP devices. And it looks like at least some don't have embedded memory and use external parallel or serial flash, which I guess can be programmed though the standard EXTTEST command.

So, at the very least we need to know the exact device  name to even look further into that.

EDIT: although if the question is about reading the SRAM, then you would need to have a real description of the JTAG commands.

[nctnico]

An easier way might be to add basic memory read / write support to OpenOCD. At least you don't have to deal with getting a JTAG interface working from scratch and doing addressing.

There is no standardized way to access memories over JTAG, so the only thing OpenOCD will save you is bit-banging a few pins.

No, OpenOCD has quite a bit of usefull generic infrastructure and is built very modular. It is quite easy to add support for a new chip. It will save time compared to starting from scratch because with OpenOCD as a base you only need to implement making the patterns to get data to / from a chip and it will work with several different JTAG dongles. I have used OpenOCD in the past for a custom programmer (using FPGA as a JTAG accellerator) and this was not difficult to achieve.

However, the fact that OpenOCD doesn't support the chip the OP uses makes me think that the programming algorithm is not publicly known.

[GromBeestje]

For modern ARM and RISCV cores, dumping memory and debugging code already in flash should work without problems, however programming if different for every chip, very manufacturer specific.

For other architectures... well... it will be tougher, when there is no standardised debugging interface available. I am aware of 8051 chips like the nRF24lu1p, which has JTAG, but without any documentation, it's pretty useless.  I'm not familiar with SHARC, so I don't know if there is any documentation about the debugger architecture.