Hacking A Parallel Port Flash Memory Programmer

[Pulko Mandy] doesn’t use his flash ROM programmer very often, but he does use it. When he tried to get support for a new chip and the manufacturer suggested he just buy a newer version he decided to hack the programmer and it’s software instead.

This device connects to the parallel port and was intended for use with MS-DOS systems (no wonder there’s no longer support from the company). The board uses logic chips to add read and write function. So the first step was to analyze how they connect together and come up with a set of commands. While at it he also made some changes to the board to bring the voltage more in spec and ensure the logic levels on the parallel port met the correct voltages.

His plan was to use the board with a Linux system so the parallel port interface can stay. He used what he learned from the hardware inspection to write his own interface in C++. It works with a chip he was able to use under the MS-DOS software, but he hasn’t gotten it to work with the chip that sparked this adventure. If you’re familiar with how the AT29C040A works please consider lending a hand.

12 thoughts on “Hacking A Parallel Port Flash Memory Programmer

  1. I walked down his road several times until I realized that an old school pro programmer that does everything and more self contained and with RS232 was only $50.00 on ebay.

    I now have a reader/programmer that will read/write almost anything (except flash, but that stuff is trivial on a breadboard) and mass copy them.

    Dont be afraid to upgrade to a high end one.

  2. Um.. the AT29Cxxx chips are a piece of piss to prog. They only need 5v and they don’t have a massive programming state machine like more modern parts. You basically start writing 64 bytes at a page boundary and wait for it to finish and then write the next page.
    IIRC there are only 4 commands you can issue: identify, prog and protect page, unprotect and prog page, erase chip..

    Here’s a driver: http://code.google.com/p/obscuremicros/source/browse/generic/flash/atmel.c

    If you only want to prog these guys bin that programmer and build yourself a new one out of a micro with an SRAM bus or a simpler micro and some shift registers.

  3. Mh, FlashRom looks to be targetted at in-place BIOS update of PC computers, that’s not really what I’m after.

    The driver for the AT29C chips should be easy enough to write… I started with the identify command but I can’t read anything else than 0xFF out of the chip. I’m not sure if it’s a timing problem, a glitch in the 74xx logic, or if I need to more precisely adjust the power supply (it’s slightly below 4.5V right now).

    As for the parallel port, well, I still have one around,but if it proves to be too slow (the AT29C needs a byte loaded every 250µs or so, which should be ok), I can still plug a microcontroller to the DB25 connector and drive the programming with that. No need for designing a new PCB and everything, this one should do the work anyway and I wouldn’t make it very different if I had to build it myself.

  4. Flashrom looks to be targetted at in-place programming of BIOS chips without moving them out of the motherboard, that’s not what I’m after…

    As for throwing the programmer away, well, I have it, the hardware is simple enough and it works ok for all the other chips. If the parallel port turns out to be too slow, I can always plug a microcontroller to it and drive it this way.

    I read the Atmel docs on the chips, but I can’t get even the simple “identify” command to work. As far as I can tell it can be either one of :
    * Stupid bug in my code
    * Delay constraints not mached (but I couldn’t see any constraint on writing the identify command in the datasheet)
    * Voltage problem (my resistor swap brings VCC from >6v to slightly below 4.5V, maybe it’s too low now). I’ll try to find an adjustable resistor so I can finetune it more easily.
    * Glitch in the 74 logic because I did things in the wrong order.
    * The removal of the pull-ups may make the signal not as clean, I’ll have to look closer with an oscilloscope to see if they still rise fast enough

  5. I took a look at your site, there are a couple of issues with your approach:

    You measured 1.2v for logic low, that is totally wrong. since you use the port sucesfully with the original software i would guess that you are not initializing the port properly, you have to work with several more addresses than 0x378. google “parallel port complete” for more info. You should keep the pull-ups, regardless of how wimpy your port is, it should have no problem pulling a 4k7 low. Once you have that fixed, THEN you can debug the rest.

    Your voltage supply was that way for a reason, Eproms are programmed with Vcc at or near 6v to give them a margin, so they stay programmed longer as the stored charge decreases. If there is a diode on the output of the regulator and it was a *fixed* voltage regulator(7805 not a lm317) you can simply add a diode to ground in place of the resistor and you would get 5v, if you still want to program eproms and the 29c you could add 2 diodes for a 5.7v out and that would be fine for both chips. If it’s variable add a switch and to resistors to toggle between 5v and 6v. always aim for higher than 5v not lower.

    You should also check that the data/address lines are wired as you expected because they might have exchanged lines to obfuscate or make the layout easier.

    The programming sequence has to followed exactly, a catch is that 0xffff is not the same as 0xfffff, you might be tempted to think “all bits set to one” for address, your compiled code might be changing what you write, depending on word sizes/casting/etc.

    Flashrom works for a huge variety of chips, yours included, you only need to have a network card or motherboard on which to use it.

    Best Regards

    1. Well yes, 1.2V is very worrying. Last time I used this programmer, it was on another computer running MS-DOS. Now I moved it to a (slightly) newer one where the parallel port may not be as good. The long parallel cable I was using when testing might not help with the levels, as well.

      I’m rather sure I got the setup correct. I set the parallel port to standard mode in the BIOS to get away with all the ECP/EPP mess as it’s not needed for this design. Unless FreeBSD is configuring it otherwise behind my back…

      The power supply regulator is a fixed 5V one, so yes the offset to 6V was intentional in the original design, but not very fitting for modern chips. I’ll try with two diodes, that sounds like a better solution.

      The data and address lines mapping was figured out bit by bit with a continuity tester, and checked again multiple times by sending patterns to the registers and looking at the output on the ROM socket. The programming software is tricky enough to not add an extra layer of bit swapping.
      Given that each register is only 8bit wide, I don’t think sign expansion is a problem – I also checked the output on the ROM pins, and it’s fine.

      Well, I guess I should have a closer look at FlashROM, it could save me some work.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.