$ git clone https://github.com/cdhooper/mx29f1615_programmer
$ cd mx29f1615_programmer/sw $ makeThe host software will be built with the above command. It may be compiled under Linux or MacOS as a command line utility named mxprog. This is the command that you will use on your computer to talk with the MX29F1615 Programmer. If your programmer already has firmware installed, you can skip to the Using the software section below.
If you would like to build the firmware, do the following:
$ cd mx29f1615_programmer/sw $ makeThe resulting firmware binary can be found as fw/objs/fw.bin The Rev3+ board provides a couple different ways to program the firmware.
Follow the pin markings on the silkscreen. I typically use an STM32F4-Discovery board for its ST-Link (pull both ST-LINK jumpers), and attach a 6-wire ribbon cable between CN2 on the Discovery board and STM32 SWD on the programmer. VCC on the ST-Link is toward the Red LED nearest the USB-Mini connector. VCC on the programmer is to the left, where the buttons are all the way in the bottom left corner.
Once the ST-Link is connected to your PC and the programmer is also connected to your PC, enter the following command in the fw directory:
$ make flash
DFU mode may be entered on the MX29F1615 programmer by holding down the ABORT button (bottom left) and pressing the RESET (immediately to the right). Release the RESET button first, then release the ABORT button.
In this mode, the green POWER LED will be off, but the amber INIT LED will be on. In about 10 seconds, you should see a USB device appear on your host. Example lsusb output:
Bus 001 Device 061: ID 0483:df11 STMicroelectronics STM Device in DFU ModeOnce the device is in DFU mode, you may enter the following command in the fw directory:
$ make dfuThis will use the Linux dfu-util command to load firmware on the MX29F1615 Programmer. Once the firmware has been loaded, the programmer will automatically reset and begin running the new firmware. At that point you will notice the ambert INIT LED is off and the greeen POWER LED is on.
$ cd mx29f1615/fw $ make flashA possibly easier option from a Linux or MacOS host is to use dfu-util to send the firmware.
$ sudo make dfu
After programming is complete, press the RESET button on the programmer.
% sudo cat </etc/udev/rules.d/70-st-link.rules
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="df11", MODE="0666"
EOF
udevadm control --reload
>/PRE>
Then simply follow the instructions above to put the programmer in DFU mode and go from there.
Verifying function
When the MX29F1615 programmer board is first assembled, no firmware will yet be programmed on the STM32 CPU. You may notice the Amber "INIT" LED is illuminated when the board is plugged in. After firmware has been loaded, you will instead see the Green "POWER" LED illuminated. When the programmer is performing an operation, the Amber "BUSY" LED will be illuminated. If you see the Red "ALERT" LED, then a firmware or hardware failure has occurred.
Once you've got a Green "POWER" LED, you can use the mxprog command on your Linux or MacOS host to communicate with the board. To access the MX29F1615 programmer's CLI, use the following command:
$ mxprog -t
Press Return and you should see a CMD> prompt.
CMD>
The prom vpp commmand can be used to show the board voltages.
CMD> prom vpp
Vrefint=069b scale=7155
Vtemp=042f 7663005 27.5 C
V10=065c 11648340 10.12 V EEPROM VPP=Off
V3P3=080a 14724990 2.94 V
V5=0658 11619720 2.32 V EEPROM VCC=Off
V5CL=05b0 10417680 2.08 V 10.90 mA
V10FB=050d 9251415 0.92 V
Using the software
If you are on Linux, you might want to configure udev to give regular users
access to the USB ACM serial device that is used to connect with the programmer.
You only need to do this once on your Linux machine.
The following command will do this:
% sudo cat </etc/udev/rules.d/70-ttymxprog.rules
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="1615", MODE="0666"
EOF
udevadm control --reload
Assumptions:
- You've already built mxprog and placed in your path.
- You've connected the programmer to your computer using either USB-C or USB type-A mini.
- You've inserted a MX29F1615 EEPROM in the programmer, with pin 1 toward the ZIF eject handle. [ Raise the handle before inserting the EEPROM and lower it after the EEPROM is inserted ]
You're ready to start programming EEPROMs. I recommend you start out with the
mxprog -i command:
% mxprog -i
Using /dev/serial/by-id/usb-eebugs_MX29F1615_Prg_6d905VF5792609C-if00
006b00c2
If you see any ID other than 006b00c2, such as 00000000 or ffffffff, you should try re-seating the EEPROM, while verifying the part is inserted with the correct orientation.
In order to program an image, you first need to erase the EEPROM. The mxprog -e command may be used to erase the entire EEPROM. You must confirm a chip erase unless the -y option is also specified:
% mxprog -e
Using /dev/serial/by-id/usb-eebugs_MX29F1615_Prg_6d905VF5792609C-if00
Erase entire EEPROM -- are you sure? (y/n) y
Chip erase
80 21.616 sec Done
The erase operation of a new part will take approximately 20 seconds.
The erase is dependent on the age and wear of the MX29F1615 part, and
will take longer as the part nears the end of its life.
To write an image to the EEPROM, you use the mxprog -w command. Example:
% ls -l
% -r-xr-xr-x 1 cdh cdh 524288 Apr 12 19:39 kicka3000.bin
% -r-xr-xr-x 1 cdh cdh 524288 Apr 12 19:39 kicka3000hi.bin
% mxprog -w kicka3000.bin
Using /dev/serial/by-id/usb-eebugs_MX29F1615_Prg_6d905VF5792609C-if00
Writing 0x080000 bytes to EEPROM starting at address 0x0
100%
Wrote 0x80000 bytes to device from file kicka3000.bin
Status: 0080 Normal
The above is the simplest example of writing to the EEPROM. In practice, you will probably want to add other options to the write command. For example, you may want to also specify that the write was successful. You can either add the -v option to the command above, or you can separately run the following command:
% mxprog -v kicka3000.bin
Using /dev/serial/by-id/usb-eebugs_MX29F1615_Prg_6d905VF5792609C-if00
100%
Verify success
It's quite possible that the MX29F1615 EEPROM (2MB capacity) is larger than the ROM image that you want to write. You should decide what to do with the remaining space. You can program that space with different images, or you can repeat the same image. If you are using the MX29F1615 part in a computer with only a 40-pin socket, you'll need to duplicate the image across the EEPROM so that regardless of how pin 1 and pin 42 of the EEPROM float, the correct data will be read. The -f option may be used to repeat an image. Example:
% mxprog -w kicka3000.bin -v -f
Using /dev/serial/by-id/usb-eebugs_MX29F1615_Prg_6d905VF5792609C-if00
Writing 0x080000 bytes to EEPROM starting at address 0x0
100%
Wrote 0x80000 bytes to device from file kicka3000.bin
Status: 0080 Normal
100%
Verify success
Writing 0x080000 bytes to EEPROM starting at address 0x80000
100%
Wrote 0x80000 bytes to device from file kicka3000.bin
Status: 0080 Normal
100%
Verify success
Writing 0x080000 bytes to EEPROM starting at address 0x100000
100%
Wrote 0x80000 bytes to device from file kicka3000.bin
Status: 0080 Normal
100%
Verify success
Writing 0x080000 bytes to EEPROM starting at address 0x180000
100%
Wrote 0x80000 bytes to device from file kicka3000.bin
Status: 0080 Normal
100%
Verify success
The above is an "all-in-one" command which fully programs and verifies the part.
If you decide later to install this EEPROM in a computer where you can select which of the four ROM images to run, you may want to program each "bank" with a different ROM image. The below example erases and programs just the top 512K with a new image:
% ls -l kick.a3000.46.143-lo.bin
-rw-r--r-- 1 cdh cdh 524288 Aug 29 22:06 kick.a3000.46.143-lo.bin
% mxprog -e -a 0x180000 -l 0x080000
Using /dev/serial/by-id/usb-eebugs_MX29F1615_Prg_6d905VF5792609C-if00
Erase sector(s) from 0x180000 to 0x200000 -- are you sure? (y/n) y
Sector erase 180000 len 80000
80 2.320 sec Done
80 2.312 sec Done
80 2.270 sec Done
80 2.281 sec Done
% mxprog -w kick.a3000.46.143-lo.bin -v -a 0x180000
Using /dev/serial/by-id/usb-eebugs_MX29F1615_Prg_6d905VF5792609C-if00
Writing 0x080000 bytes to EEPROM starting at address 0x180000
100%
Wrote 0x80000 bytes to device from file kick.a3000.46.143-lo.bin
Status: 0080 Normal
100%
Verify success
Since just the top sectors were erased, the remainder of the EEPROM still
has the contents which were previously programmed.
Debugging software
If you want to make modifications and need to debug, you can use gdb to do so. The makefile provides two target shortcuts for this purpose. In one window (that you'll set off to the side), enter:
$ make stlink
In a second window, enter:
$ make gdb
and at the gdb prompt:
(gdb) connect
From here, you can use normal gdb commands to set breakpoints, run software, and stop execution. The stlink interface isn't perfect. You might find the need to press the reset button on the target at times to re-run the firmware after setting a breakpoint.
Software Development History
I started implementing firmware on the STM32F4-Discovery board before Rev 1 of my board arrived. I decided to try the STM32CubeMX software to generate the initial environment in order to reduce initial development time. In the IDE, I selected the STM32F4-Discovery board which chose the appropriate ST-Micro CPU and GPIO configuration appropriate for the board. The IDE was configured to generate a Makefile so that I could use gcc-arm-none-eabi. To write the STM32 flash using the onboard ST-Link, I used st-flash from texane st-utils.
You can get a copy of this repository to build the tools with
git clone https://github.com/texane/stlink.git stutils
But it's not necessary to do this manually because the Makefile will acquire and build ST-Utils when using the make flash command.
The command line handling and some command code was integrated from a memory display/edit utility that I previously wrote.
From the start, I wanted to make this project completely open source. After getting barely functional programmer firmware up and running, I started looking into what it would take to make it open source. Based on my understanding of the ST-Micro License agreement, I openly share source of the ST-Micro HAL library. For that reason, I decided to port my firmware to use libopencm3 instead.
THe MX29F1615 programmer source assigns the libopencm3 git repository as a submodule. You can use the git submodule command to pull in code from this library:
$ git submodule init
$ git submodule update
I may choose to make this automatically done by the Makefile in the future.
As of January 6, 2021, the source code supports the STM32F407, STM32F103, and STM32F107 processors. It supports these three processors with either the STMCubeMX-generated HAL library as well as the open source libopencm3 library.
The main Makefile supports libopencm3 and boards are selected by setting the BOARD_REV macro in the Makefile.
To use STMCubeMX, you will find the individual *.ioc in the top directory. They provide the configuration used by STMCubeMX to generate the appropriate HAL sourtce. With only minor modifications to the HAL source, the firmware will run under each of the three CPUs. I am still working out how to minimize the number of modifications required for the HAL library source.