srxtool
The srxtool is designed to communicate with the srx-programmer, dump data from the flash ICs or program the flash ICs. It makes usage of the programmer a little bit simpler than using a terminal application like teraterm or realterm.
WARNING: it seems this doesn't work properly in virtualized environments like VMWare workstation. Please don't try to do this in a virtual machine.
One prerequisite is that you use the correct native USB port of the Arduino Due. It is the one located next to the reset button.
Grab the binary from the release page for your operating system and place it into some working directory.
If you want to compile the software yourself, it is very easy. Download the golang compiler, clone the git repostitory and run "go build" in the src/srxtool directory.
For Linux users: as the tool and the user access the serial port, you'll might have to make sure the user has access to the serial port. Usually, this is done by adding the user to the "dialout" group.
srxtool is a command line tool. That means, you'll need to have a command line open. On Windows, you can search for "cmd" and open the command line interface. Change to the directory where you want to use the srxtool in and where you have placed the executable.
Run "srxtool -help" to see the usage options and some examples how to use the tool.
Then, find the right serial port by running "srxtool -devices". This will list all serial devices with the pointer what to look for (VID/PID). From there, you should be able to correctly determine the right serial port.
In this example, the VID and PID of COM8 match VID=2341 and PID=003e.
The first thing to know when dumping an image is that the srxtool + srx-programmer have (at the moment) absolutely no flow control or error correction. As a result, if the data transfer is somehow interrupted, the resulting dump file might not be the same data as stored on the card. Such interruptions can be caused by all kinds of things like the writing data to the harddisk of a different software running in parallel or similar. The experience is that virtualized environments like VMware workstation don't work reliably at all!
As a result, we need to know when our dump was successful. For that reason srxtool and srx-programmer firmware have the possibility to calculate a crc32 checksum over the data on the flash ICs without transferring the data over to the operating system. This is done entirely on the srx-programmer firmware and the Arduino Due, so the possibilities for interruptions is reasonably limited.
The second thing to know when dumping an image is how many flash ICs you want to be dumped. Dumping and Programming both have an option "firsticonly". This option needs to be used when there is only one flash IC on the card. This is clearly visible when you look at the card and IC2 is empty. Most cards have two flash ICs though and you won't need this option.
So let's begin. Before dumping, we should always run a crc32 checksum onboard on the srx-programmer so that we know when the dump was successful. Always push the reset button on the Arduino Due before starting a process on it. It makes sure it isn't stuck in some undefined state. We calculate the CRC32 using "srxtool -mode crc32 -serialport COM8" (for two ICs). After that, the CRC32 calculation process starts. The process is slow and will take some time.
When it is finished, it looks like this:
Take a note of the calculated CRC32 checksum.
Reset the Arduino Due first. You should do this before every command line call you perform. Then run „srxtool -mode dump -serialport COM4 -out filename.bin“ to start the dump process. In my systems it takes roughly 25 minutes per flash IC, i.e., the overall process for two flash ICs will take approximately 50 minutes, maybe a bit less.
The tool outputs the CRC32 checksum over the dumped file. As you can see, the CRC32 checksum of the file matches the calculated CRC32 checksum of the programmer. So the contents of the dumped bin file are likely to be exactly the same as on the card’s flash.
To verify that the dumped image works, it might be a good idea to program it to an opensrx card.
To program an opensrx card, it must be plugged onto the board as shown in the images. In addition, it is important to note that the opensrx card has additional pins. These are necessary to put the card into a mode where it can be programmed. When plugging the card on to the programmer, make sure that these pins are properly plugged into the programmer with good contact.
Then, it is a good idea to erase the opensrx card first. You do that by resetting the Arduino Due first (as always before doing an operation on it) and then calling „srxtool -mode erase -serialport COM4“. This looks as follows:
It now makes sense to verify that the card is indeed erased. For that, we do an exemplary hexdump of the contents of the first few bytes of data of each flash IC.
Reset the Arduino due. Then execute „srxtool -mode hexdump -serialport COM4 -ic 1“ and „srxtool -mode hexdump -serialport COM4 -ic 2“. The output should look as follows for both ICs. The FFFF’s indicate the the flash is empty. We’ll see what this looks like for a programmed card after programming.
Now that the card is empty, we’ll continue with the programming. We’ll reprogram the dump.bin from the dumping instructions above and load it back onto the card.
Reset the Arduino Due and type „srxtool -mode program -serialport COM4 -in dump.bin“. The output looks as follows:
The programming process is unoptimized at the moment and will take a pretty long time as a result (approximately 2 hours).
Once the programming is done, the output looks like this:
In rare circumstances, the programming might stall or halt. In this case, the process with erasing and programming unfortunately has to be repeated. Be sure to reset the Arduino Due before each step.
To check whether the programming worked we can now do two things to be sure. The first is that we perform hexdumps of each IC to check if data was written in the first few bytes of data of the card. We do that by repeating the hexdump process above: „srxtool -mode hexdump -serialport COM4 -ic 1“ and „srxtool -mode hexdump -serialport COM4 -ic 2“.
In this example, you see that there is some data on the second flash IC.
The second thing you can do is calculate a CRC32 checksum on chip again to compare it to the checksum of the .bin file programmed. The instructions can be found in the description on CRC32 checksumming above.