Every once in a while I come across an ancient UV erasable memory device, for which no programming hardware is available. The typical reason for this is that the device in question uses unusual, normally high programming voltages, making it impractical to support in a cheap universal programmer. Premium programmers typically do support these devices, but often with a $300+ programming adapter (on top of the $600+ you’ve already paid for the programmer).
Many, including myself, seek a more affordable option. There are plenty of examples of other D.I.Y. programmers for the devices I support in this project, however these are usually quite makeshift bare-minimum-to-do-what-they-wanted affairs and difficult to recreate.
The aim of this project is to provide a good software platform for programming these old devices, and some reliable, easy to build Arduino shields as the programming hardware.
As it is nearly impossible to build hardware which programs everything I support, each device family requires its own programming hardware. To date, there are three device shields, which have their own project pages:
More about it here.
- 1702A (and all compatible devices. The 1702 is not compatible)
Okay, so this one is not so easy to build, but the demand for this is quite low, so I went for elegance and convenience of use rather than ease of construction. If you really want one, it’s going to be a bit of an effort.
More about it here.
I recently came across an MCS-48 in something I was trying to repair, so HVEPROM gets a new shield!
- 8048 (Read mask ROM)
- 8049 (Read mask ROM)
More about it here.
Am I missing one?
I actually rather enjoy designing and building these. If there’s a common UV Erasable memory device you’re aware of for which programming hardware is non-existent – drop a comment. I might just build a programmer for it.
To drive these boards I’ve written a small Windows application which gives an experience similar to a commercial programmer.
- Programmer firmware source (includes pre-compiled .HEX files)
- Command line host software source
- Windows GUI binary download (not open source)
Windows GUI version history
- Initial release
- Hardware test added
- Fixed some incorrect labels on form
- Fixed crash on systems with no serial ports
- Fixed error in 270x voltage check
- Added configurable baud rate
- Added checksum calculator
- Fixed bug where status bar showed an incorrect operation when programmer doesn’t respond
- Fixed bug where operations in menus were enabled at times they shouldn’t have been
- There is a known bug in this version where the ‘read’ part of the hardware test screen does not work. It will be fixed in the next release.
- MCS-48 added
- Fixed bug in ‘read’ step of hardware test, where readback value wasn’t shown
- Added configurable verify delay (application configuration file only)
- Fixed issue in write checksums where checksum of input file was shown instead of device
I don’t distribute the source for the Windows GUI. There shall only be one version of it: My version.
I welcome new implementations of the host software, but it has to be clear that it has not come from me and as such I will not be personally supporting any alternate interfaces.
If you are interested in seeing an implementation of the host side programmer – take a look at the command line version of it on Github.
I do fix bugs and make changes on request (provided the changes are of benefit to all). Please get in touch if you feel there’s something missing.
Command line programmer
For reference I have also provided a command line programmer written in C. I do not distribute binaries for this – any binary should be considered ‘unofficial’. It is very easy to build.
On Linux – clone the git repository to a folder, and run ‘make’ in that directory.
On Windows – It has to be built with Visual Studio. I used Visual Studio 2017 with the C++ add-on. It may build on cygwin – you are on your own with that.
Programming the firmware
There is only one version of the firmware, which supports all shields and devices. There is a variant of the firmware: ‘rs232’ which uses the DE-9 serial connector on the shields instead of the Arduino USB interface.
The source code is written in C and compiled with AVR-GCC. There is no Arduino sketch – it cannot be opened with Arduino Studio. It (including pre-compiled .HEX file) is located in my eightoduino repository on github. It can only be used on AVR Arduino Mega boards (unless ported to something else).
Use AVRDUDE with this command and the pre-programmed Arduino bootloader to program the firmware (replace the COM port as appropriate):
avrdude -p m2560 -c stk500v2 -P COM4 -b 115200 -D -p atmega2560 -U flash:w:hveprom.hex:i
Operation timed out
This is the most likely problem you’ll see. Assuming you’ve selected the correct COM port and successfully flashed the Arduino with the above command (using the Arduino bootloader – not a physical programmer such as the STK500) then you should be at least at the point where you’ll get an error message other than a timeout.
The next think I’d try is running the hardware test (Setup -> Hardware test) without the shield attached – just in case there’s an issue with your shield which is causing problems with the Arduino its self. At the very least you should see an “Invalid shield attached” error.
There are also some oddities of the on-board USB to RS-232 chip on the Arduino – even the genuine models – it seems to be common for it to get into a “bad state” where it stops passing data between the PC and the AVR. The reset button has no effect on this chip – so usually a combination of power-cycling, disconnecting and re-connecting the USB will fix it. If you’re an Arduino expert and know more about this problem please get in touch with me.
Failing that, build your board with the RS-232 section (and plug it into a serial port), and use the rs232 version of the .HEX file. You will not have these problems.
Using the hardware test function
From the “Setup” menu select “Hardware test”. You will be prompted with the above dialog which will assist with testing before risking blowing a potentially expensive EPROM.
I strongly recommend doing this before fitting the test socket, or if you have fitted it, put an IC socket into the test socket – this will make contact with multimeter probes a lot easier. Label all of the pin numbers as I have done here. There are quite a few tests to get through – you are not going want to have to keep counting through all of the pins!