Various devices with JTAG and SPI

Development Boards MicroMod
1

(I know this is not completely an OpenOCD question, but I guess this is still the best forum to ask this one.)

We need to program a little bit of this and a little bit of that. We have:

  • ARM controllers (AT91R40008) with external flash (Am29DL163, CFI compliant)

  • different CPLDs (XC2C64A, EPM3128A, LC4256Z)

  • AVRs (ATmega8L)

The ARM and CPLDs are JTAG devices, the AVRs are SPI devices.

We would like to have a solution where we can use the same USB programming system for all devices just by changing the required cable. The system should work at least in Linux but very preferably in OS X and Win as well.

What we do right now is that we have a custom-made parallel port dongle and some proprietary patches to open source software (avrdude, svfplayer, armtool). As parallel ports are no more, we need to move on to USB (which could also provide us with more speed).

So, what we are planning to do is to get some USB-JTAG adapters supported by OpenOCD. (Actually, we have ordered but not received some Amontec dongles.) That should at least get the ARM part done. AFAIK, OpenOCD has been demonstrated to work with FT2232-based adapters in all Win/Lin/OSX.

But then we’ve got some problems with the CPLDs. Amontec has some Windows tools to program them with their JTAGkey, but we need something cross-platform. That spells “open source” in practice. What is the status of SVF with OpenOCD? I know XSVF should work, but we have also Lattice and Altera chips.

And then we have the SPI devices. Is anyone aware of an AVR programmer using the MPSSE of the FTDI chip? Bit-banging might probably be a tad slow, I guess. (Or is it? There is not much data to be programmed, anyway.)

Again, Amontec advertises something about USB/SPI with their JTAGkey, but I guess that only refers to the possibility of using MPSSE. Or is there some code lying around?

Any ideas and suggestions are welcome!

2

Well I am not aware of any Open Source SPI programming capabilities.

I would have thought that writing you own and adding them to OpenOCD would not be so hard. SPI is much simpler than JTAG. I have not looked at the spec. for the AVR chip however so maybe I am wrong :wink:

Good luck with your project, and if you do get something working do not forget to share !

3

Using MPSSE to program an AVR is simple. You can use any (I think) FT2232 based JTAG adapter with a pin connection/adapter that maps the in out and clock signals in the right directions for the AVR serial (SPI slave) programming interface:

TDI to MOSI,

TDO to MISO

TCK to CLK

and nRST or TMS or some other free signal to RESETn

For simply flashing the AVR’s I think it is easier to write a stand alone program for this rather than trying to fit the SPI, non JTAG, stuff into the OpenOCD framework.

But it is definetly possible to use the same hardware.

Regards

Magnus

4

I’d think that it would be possible to program a microcontroller like the one on the UBW to do the timing-intensive parts of the SPI and JTAG programming process, presumably on different sets of pins, and then talk to the µC from OpenOCD and a hacked avrdude. In fact, it seems like it should be really pretty easy to do that (on Linux/OSX at least, I don’t know about Windows), but maybe I’m forgetting some detail.

5

wiml:
it seems like it should be really pretty easy to do that, but maybe I’m forgetting some detail.

The detail is probably "it's easier to use two FT2232s than to write custom firmware for a PIC" :D
6

Using MPSSE to program an AVR is simple. You can use any (I think) FT2232 based JTAG adapter with a pin connection/adapter that maps the in out and clock signals in the right directions for the AVR serial (SPI slave) programming interface

This is absolutely true. We are even today using parallel port programmers which have four i/o pins. They are used with ARM/AVR/CPLD.

However, there is a slight challenge here. The mapping of MISO/MOSI/SCLK (OR TDO/TDI/TCK) is obvious and must not be changed. Or if it is changed the MPSSE becomes futile. But then we have two pins on ARM: TRST, SRST (i.e. JTAG reset and device reset), whereas there is only one extra pin required for AVR programming (nRST, device reset).

Which one to use? Mapping JTAG TRST to AVR nRST is what we’ve been using. It makes sense in the way that both signals are absolutely necessary. The SRST (device reset) in JTAG is not absolutely necessary, but then it has exactly the same function as the AVR nRST. Are there any reasons to use one and not to use the other mapping? How about making the software so that it wiggles both signals when used in AVR mode?

Well, I’ll let you know when I get this programming riddle solved. Seems that I have to take the avrdude and OpenOCD source and start hacking. I just find it odd no one has done this before. AVR is one of the most common 8-bitters, and JTAG is everywhere.