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.
Read 16 comments and join the conversation16 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
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 29F0x0 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 0x100 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
That is exactly what Linksys routers do when you want to use the JTAG method to get DD-WRT, Open-WRT, Tomato, and so on, on it. A serial port is not a big inconvenience, space-wise. I’m planning to use one (albeit with bed-of-nails ‘adapter’) for one of my Gameboy (not GBA/NDS/3DS) cartridge projects. The major advantage is that if you’re producing boards by the thousands, then you can just assemble them en mass, and program them at the same time you do diagnostics. If a board refuses to program, it failed the first step in QC. Program it with boot loader, send CPLD firmware+diagnostic code, burn the CPLD and run the tests, then send the normal firmware for the Flash ROM. This can all be automated into a program + PC + adapter that does this in batches. If you wanted to be really efficient, make an gang(multidevice) programmer with an embedded system and have a front panel interface that even a monkey could figure out! 😛 About 10 of those (with 8 connectors) would be able to test 80 devices at a time, several times an hour.
1) Try to initialize boot ROM programming. Remove power to the board (relay/MOSFET/whatever on adapter) and connect it to the USB port on the computer. Wait for the USB device driver to recognize the part. If successfully loaded, then it responds as a USB-to-serial adapter with commands sent to the virtual serial port. Failure -> Check all boards in that batch for solder bridges and missing joints – this is a horrible failure that most likely means a newbie assembler f***ed up or their solder pool wasn’t hot enough. It’s best to solve this one ASAP.
2) Try to send the CPLD firmware to the board using USB. It’ll hold the firmware temporarily in Flash ROM, then send the correct parts to each/the CPLD/s on the board. The board’s microcontroller will tell you the checksums it reads back from the Flash ROM and they must match what the PC’s program precomputed. Failure -> Bad connection to Flash ROM or bad/missing Flash ROM. Yes, sometimes Flash memory is bad from the factory. -> Check board continuity, and if Flash ROM is connected, then you already know that writing patterns of bytes to it will probably fail. Use it for spare parts(hehe).
3) Send the diagnostic program to the Flash ROM using USB and then have the microcontroller run it. Stuff like loopback tests or anything you can think of that narrows failures down to specific parts of the board. The tests should return the same result on each board. Also, the checksum of the test code should not vary. This is an additional test for the Flash ROM, obviously. Failure(tests) -> bad connections to CPLDs? Failure(Flash ROM) -> Possibly bad device or buggy programming algorithm (did you wait long enough between written pages?).
4) Send your main code and have the microcontroller verify the checksums as it’s written to the Flash ROM. If your device gets this far, then congratuations, you’ve got a good board!
The nice thing about a test procedure like that is that you can catch failures at different levels. In other words, you can test that your prototype passes the boot loader (step 1) test before even bothering with worrying about the rest of the board. You can just hook a blank USB-based microcontroller to some breakout board before you even design the prototype board. Then you can go to testing that your Flash ROM programming algorithm is burning the data correctly, and so on. This saves a lot of headaches by breaking the problem into smaller, more manageable pieces. Good luck! And let us see the project when you get it working! 😉
Oh, here’s a short list in case that was TL;DR:
1) Test the boot loader/microcontroller.
2) Test the Flash ROM and USB.
3) Test the CPLD/s.
4) Verify that the normal firmware was written correctly.
5) ????????
6) Profit!