Small ROM
In my ongoing effort to make the Tiny CPU board as small as possible, I’m looking for a small Flash ROM or EEPROM. That’s small in physical size, not necessarily capacity. My search has led me to examine many different ROM package types and interfaces, but unfortunately I’ve yet to find anything better than a standard Flash ROM in a 32-pin DIP package, using a space-hogging ZIF socket, with reprogramming performed by removing the ROM to a stand-alone programmer.
JTAG?
My dream solution is a programmable ROM with a JTAG interface. Then I could add the ROM to the JTAG chain, and program it using the same hardware and software I’ll already be using to program the CPLDs. Unfortunately, the only JTAG ROMs I’ve found are intended for use as FPGA configuration devices, and have a serial interface instead of the standard parallel address and data lines I need. They’re also surprisingly expensive.
SPI, I2C?
I’ve seen a couple of ROMs that use SPI or I2C for programming, but that doesn’t help me much. I don’t have any appropriate programming hardware, and at any rate these also don’t have parallel address/data interfaces. I do have an FTDI USB-to-serial cable, which might be usable for programming if I had appropriate software and a serial-programmable, parallel addressable ROM.
JTAG Indirect?
An approach with some promise is JTAG indirect programming, in which the ROM’s pins are connected to some other JTAG-enabled device, and then JTAG boundary-scan bit shifting is used to manipulate those pins to program the ROM indirectly. This might work, but available information and software for actually doing it seems scarce. I’d need some better examples, and some software that actually does indirect programming, before I could evaluate it. ROM programming using the JTAG indirect method is also reportedly slow, but just how slow isn’t clear. If it takes several minutes to program a 128K ROM, I would probably get annoyed.
Custom Interface?
I might use a standard Flash ROM in a smaller package, soldered directly to the board, and connected to a simple microcontroller or other device used to program it. That would be essentially equivalent to JTAG indirect programming, but rolling my own solution. The addition of a MCU or other programming hardware would mostly cancel out the space savings of the smaller IC package, though. Creation of a ROM-image loader also likely wouldn’t be trivial.
DIP.
It seems that all paths lead back to where I started: A plain old DIP, in a ZIF socket for easy plugging and unplugging. It will take up a lot of space, but I can easily transfer the ROM back and forth between the Tiny CPU board and my EPROM programmer whenever I need to update the ROM image. Maybe this is one case where the old, tried and true solution is best.
14 Comments so far
Leave a reply. Comments may take a few minutes to appear.
Assuming Tiny CPU is running at only a few megahertz, you could use a faster microcontroller as your memory device and emulate a ROM in software using the flash or EEPROM memory in the microcontroller for the actual storage. For example, the Atmel ATMEGA32A-AU is in a small TQFP-44 package with 32K flash and 1K EEPROM (both JTAG programmable) and has 32 I/O pins (28 if you dedicate the 4 JTAG pins). It would be limited by the software to how fast the chip could enable or disable it’s data bus though. You could minimize the turn off time with an external buffer if this was important.
There’s also the PSoC series from Cypress that includes not only a in-circuit programmable microcontroller but also some programmable logic. I have not used this, so I don’t know for sure, but I think that the programmable logic could at least take care of buffering the data bus so that you would not need an external buffer.
However, a DIP flash chip does have simplicity going for it and doesn’t seem a perverse as using a fancy microcontroller in a support role to such a simple CPU.
Hi,
I think what you want is a NOR flash. NOR flash usually has a “parallel” memory mapped interface.
A quick google for “JTAG NOR Flash” gives this page:
http://www.asset-intertech.com/jtag_development_po9.htm
which talks a bit about “Flash Memory Programming with JTAG or Boundary Scan” i.e. JTAG Indirect.
Have you considered reusing the CPLD as the programmer? That is:
* Program the CPLD as an EEPROM programmer
* Download a program to the EEPROM via the CPLD (Custom to PC parallel port or FTDI adaptor would seem sensible?)
* Program the CPLD as the CPU again
With any luck, after a try or two of this you should have a functional boot loader ready and no longer need to go through the rigmarole.
Perhaps you can dedicate a 4-bit port on the CPLD to communications? Somewhat like:
* MOSI
* MISO
* STROBE
* ACK
PC inverts strobe to send or receive data; reciever inverts ACK to acknowledge. Data is clocked in on MOSI and MISO. Obviously, transferring on both edges is going to be faster. The main reason I suggest this protocol is that its feasible to bit bang from the CPU (Presuming you can fit in an address decoder for an IO port, of course)
How many instructions would your Tiny CPU need to read some serial flash and write it to memory? If it’s really small, you could write a tiny bootloader and implement it with diode matrix rom.
Advantages:
* Cheap serial flash in any package.
* No need for expensive Flash/EEPROM programmer.
* can use LEDs for the diodes (lot’s of blink’n lights)
Disadvantages:
* if bootloader is too big, it would take up way too much board space
* if bootloader is too big, it will slow down the memory bus.
* if bootloader is too big, you’re going to spend way too much time putting it together.
* Diode matrix rom is so 1950’s - building a CPU with TTL is one thing, building with diodes is likely to push people over the edge.
Check out the older 29F040 PLCC-32 series flash devices. They are 512K X 8bit, still available in 5V, relatively small and new are sub $2 USD in a quantity of one. These work exceptionally well as bank switched rom in a limited 16 bit address space architecture or as external rom with the larger ATMEGA series MCUs.
I frequently use these in my project with either an smt or through hole socket for prototyping and later soldered directly to the pcb on finished product. You will appreciate the fact you can actually see and solder the PLCC-32 with lead spacing at 0.050″ . The 29F0×0 devices are also compatible with most of the inexpensive usb eprom programmers using the PLCC to DIP adapter.
Great suggestions all, thanks!
@Erik - An MCU to emulate ROM would likely work, but isn’t something I’d be happy with for this project.
@Andy - Yes, this is what I was looking at with JTAG indirect, but the details are sparse, and the required software only seems to be part of JTAG boundary-scan tools costing hundreds or thousands of dollars. I found a trial version of a tool called TopJTAG Flash Programmer which I’ll try.
@Owen - That’s roughly what I was thinking of when I mentioned “Custom Interface”. It could be worth a shot. My concern is that it’s a significant technical project in its own right, requiring custom hardware and software for ROM programming. And frankly, I’m lazy.
@Tom - I think a diode ROM bootloader would be far too big, but a similar idea might work: At bootup, use some unused logic resources in the second CPLD (the one doing address decoding and device interface) as a hard-wired bootloader, copying the ROM image from serial Flash to RAM. And the serial Flash could be something that’s normally used for configuration, and supports JTAG natively. This could work fairly well, and isn’t too horribly complex. The amount of time needed to copy the ROM image might be an issue though.
@SA - If I stick with a solution that requires removing the ROM from the board to reprogram it, then this may be the way to go. How easy is it to remove the PLCC from a socket? I’ve only pulled a PLCC a few times, but it required a special tool and seemed like a pain, so probably not something you’d want to do a lot. But if it can be removed pretty easily, this could work well.
I tried out JTAG indirect programming, using the Altera CPLD demo board, a 128K AMD Flash on a protoboard, lots of long loopy wires, and a trial version of TopJTAG Flash Programmer. The good news is: it works! The bad news is: it’s slow.
Reading the 128K ROM took about 4 minutes. Writing? Well, it’s been going for 25 minutes, and the progress bar looks like it’s about 10% done. Ugh. This may partly be due to my Flash ROM, which TopJTAG warned me was not CFI-compliant and which I think only supports word-by-word programing rather than buffered.
I’m unclear how to set the speed of the JTAG clock. Too fast and you’ll get errors, too slow and you’ll waste time needlessly. There’s no speed option in the software that I can find, so I have to guess that it auto-sets the clock rate, based on some feedback or error checking. If so, then my long loopy wires connecting the demo board and Flash are surely contributing to the slow programming times.
Unfortunately, unless better wiring and a different brand of Flash could provide a 100x speedup, then I don’t think JTAG indirect programming is going to be fast enough. And there’s really no way to know if better wires and a different Flash would help, without actually buying some parts and building a board to test it.
Is JTAG indirect a feasible method for loading a small bootloader? I’ve seen people cram USB bootloaders into 512 bytes of ROM; I’m sure you can manage to cram something for a simpler protocol into a similar size. I noticed your proposed interfaces don’t include any connection to a host machine; this is a bit of a shame as it makes things more complex (Perhaps you could hijack the PS/2 interface and bit bang it from a PC parallel port? It will never be fast, but it should be faster than *that*!)
Owen, can you describe what you’re imagining further? My goal is a way to reprogram the system ROM (tentatively 128K) without having to remove it from the board. Yes, I could probably write a bootloader in 512 bytes, stored in a tiny ROM that could be programmed quickly with JTAG indirect. But then what? I’d need to always have the system connected to a PC, and use the bootloading process to store a program in RAM every time the system is reset, right? Or are you imagining two separate ROMs: a small one programmed using JTAG indirect that contains a bootloader, and a larger one programmed directly by the CPU, using the PS/2 connector or a serial port maybe?
Owen has a good suggestion. Most flash devices have independently erasable/programmable sections. It would make the most sense to put the bootloader in one of these sections (via JTAG indirect) and have the bootloader either download new code into one or more of the other sections or transfer control to the previously downloaded code. Thus you could avoid needing two separate ROMs or being always connected to a PC.
A minor complication is that you normally cannot execute code from the flash chip while programming the flash chip, but as long as the bootloader can first copy itself into the RAM and execute from there, it’s not a problem.
I think my brain is overloaded. I’m reluctant to use a bootloading solution for my first attempt at least, because it complicates things more than I’d like. It requires adding a serial port or some other PC connection, and writing a bootloader to program the ROM, which means deciphering the AMD or Intel Flash command sets. I’d rather keep things simple, increase my chances of getting it to work at all, then add improvements.
I think I’m going to stick with using a standard Flash ROM that I remove from the board and program in an external programmer– either a 32-pin DIP, or the smaller 32-pin PLCC that SA mentioned. But I’ll design it in such a way that JTAG indirect programming is also possible. That way I’ll have something I’m pretty certain will work, but also learn how well JTAG indirect programming works in a real system. That’s still my preferred solution if I can get it fast enough, because it should “just work” without the need for me to write any software or tools, or to add additional ports.
It seems the JTAG indirect programming was working more poorly than I first thought. I tried it again yesterday, and some of the original data had been replaced by my attempt at programming, but not with the data I was attempting to program. What’s more strange, though, is that when I took out the Flash chip and put it in my regular EPROM programmer, it no longer recognized the device ID and wouldn’t program or erase it. Instead, it seemed to be interpreting two bytes of data at 0×100 as the device ID. What the heck? So not only was JTAG indirect programming apparently not successful, but it also bricked my Flash chip. I didn’t think that was even possible.
Could you put a header on the PCB for flash programming and then attach that to a dumb programmer consisting of a couple of (three or four) 8-bit latches and program it from a PC via a centronics cable?
When you are not programming it, you disconnect the small dumb programmer. The header shouldn’t take up much space or disturb the routing much. Also, your signaling speeds are low so it shouldn’t be a problem there, either.
I’d suggest using the CPU to program the flash. This is the way abatron and other JTAG programmers work. Basically, you use the JTAG hardware to bootstrap the CPU and then manipulate the CPU via JTAG to program your flash for you. Speed would depend on your implementation, but the bdi-2000 is very fast