Console update application development

[ian]

Here's your chance to get a SUMP PUMP for free, maybe even a preview unit. We need command line utilities to update the SUMP PUMP FPGA image from Windows, Mac, and Linux. We're currently using a Perl script, but this is too much hassle for end users.

The update is done over a virtual serial port using a simple protocol. Ideally, the utility would load Intel HEX files directly, but we have raw binary blobs too. The utility must compile on all major platforms (Windows, MacOSX, and Linux). Piotr's Pirate-Loader utility source code should have everything you need to get started.

The winning entry should:
*Run as a native console application (not scripted, no .Net/Mono)
*Compile on Windows, Linux, Mac, and include these compiles
*Be released under an open source license, preferably CC-BY-SA or GPL
*Work in our tests

C code is preferred by not required. We'll leave this open until a satisfactory solution is submitted. In the case of multiple entries, we'll choose one based on compliance with the criteria and possibly a vote.

Original post here.

[robots]

I have written something ... But I don't know how to test the serial communication part. :)

It compiles on windows, and linux, (i don't have mac around here)
Has all the features perl script has, (except for the page number limit), reads writes hex and bin files.
Most of the OS dependent parts are from pirate-loader, so it should work even on windows :)

[robots]

Here is my work. I have only tested the bin/hex file parser/writers.

There are binaries for Win32 and linux, sourcecode, Makefiles for linux and Dev-C++. The serial part is copied from pirateloader, so it should work.

Can you test it ? 

[ian]

Thanks robots, fantastic work in a short amount of time -- I tested it and had lots of success, but a few errors:

C:\Perl\eg>pump-loader
PUMP loader

pump-loader
parameters:
-p PORT - port of PUMP, needs to be specified

-rH FILE - HEX file to be uploaded to PUMP
-rB FILE - BIN file to be uploaded to PUMP
-wH FILE - HEX file to be downloaded from PUMP
-wB FILE - BIN file to be downloaded from PUMP
-l 0     - send only bytes from file (0-padded) - write only
-l X     - send only first X paged
commands:
-erase  - erases Flash
-write  - writes data to Flash
-read   - reads data from Flash
-run    - enter run mode after finished
-status - get PUMP stauts
-boot   - enter bootloader mode - ignore other commands


When no command specified, program will check FW version, and Flash ID

C:\Perl\eg>

Help menu

C:\Perl\eg>pump-loader -p:COM5
PUMP loader

Opening serial port COM5...OK
Found PUMP HW: 1, FW: 0.1, Boot: 1
Found flash: ATMEL AT45DB041D

C:\Perl\eg>

Read PUMP/ROM version strings

C:\Perl\eg>pump-loader -p:COM5 -erase
PUMP loader

Opening serial port COM5...OK
Found PUMP HW: 1, FW: 0.1, Boot: 1
Found flash: ATMEL AT45DB041D
Chip erase ... done :)

C:\Perl\eg>

Erase the chip (verified).

C:\Perl\eg>pump-loader -p:COM5 -boot
PUMP loader

Opening serial port COM5...OK
Found PUMP HW: 1, FW: 0.1, Boot: 1
Found flash: ATMEL AT45DB041D
PUMP switched to bootloader mode

C:\Perl\eg>

Jump to bootloader works.

---------------------

C:\Perl\eg>pump-loader -p:COM5 -rH:pump.mcs -write
PUMP loader

Opening serial port COM5...OK
Found PUMP HW: 1, FW: 0.1, Boot: 1
Found flash: ATMEL AT45DB041D
no input file specified !

C:\Perl\eg>pump-loader -p:COM5 -rB:pump.bin -write
PUMP loader

Opening serial port COM5...OK
Found PUMP HW: 1, FW: 0.1, Boot: 1
Found flash: ATMEL AT45DB041D
no input file specified !

C:\Perl\eg>

I think the -wH/B and -rH/B are mislabeled? I get no input file specified when I use -w with -read and -r with -write.

If I do it the other way, I get system errors:

pump-loader -p:COM5 -wB:dump.bin -write

opens the port, gets the FW version string and the ROM version, but then windows pops up an error that pump-loader encountered a problem and needs to be closed.

C:\Perl\eg>pump-loader -p:COM5 -rB:dump.bin -read
PUMP loader

Opening serial port COM5...OK
Found PUMP HW: 1, FW: 0.1, Boot: 1
Found flash: ATMEL AT45DB041D
Page 0x0000 read ... OK
Page 0x0001 read ... OK
Page 0x0002 read ... OK
Page 0x0003 read ... OK
Page 0x0004 read ... OK
Page 0x0005 read ... OK

Reading partially works (with the operands switched). It starts out OK, but then it speeds up (bad reads?) and eventually crashes. On another try it read to page 0x800 and crashed. In both cases it never created the output file (dump.bin).

Great work, it looks really close to done. If you have any ideas for bug fixes, I'm happy to test again, though you may need actual hardware to finish the job :)

[ian]

I have one more minor request: since this is a virtual serial port the speed doesn't really matter. I increased the perl script baud rate to 921600 and got a nice speed increase. Could you please do the same with your program?

[robots]

I messed up the help:
-r[HB] goes with -read command
-w[HB] goes with -write command

The idea of reading is to: read the whole memory (or specified number of pages) into buffer and then write the buffer to hex or bin file (or both).
Write is done backards. Read hex/bin file (just one) and write the memory.

But when the reading fails, it should at least create file, with zeroes. Unless it fails on buffer overflow :)

[IPenguin]

Real quick and darn close shot by robots :)

pump-loader.exe works on

- default (no other parameter than port given - pump-loader -p:COMx)
- erase SPI flash (pump-loader -p:COMx -erase)
- switch to bootloader mode (pump-loader -p:COMx -boot)



- read SPI flash and write image to HEX file (pump-loader -p:COMx -rH:<file.mcs> -read)



However, it always fails when writing a HEX file to SPI flash (pump-loader -p:COMx -wH:<file.mcs> -write), causing a problem and Windows terminating pump-loader.exe with an error screen:



Maybe I misunderstood how to use the parameters for the write SPI flash operation properly ... sorry for the German text ... the system I am testing on runs a German Windows XP ...

[robots]

Could you test this one ?

http://robot.mysteria.cz/pump-loader.exe

Should work better, with parameters parsing corrected and lot's of copy-paste problems corrected. :)

For the ':' you can also use '=' or any other non white-space character.

[ian]

Fantastic work! It works great for me. I did these tests:

Wrote a HEX to the ROM with the console app
Dumped the ROM to a .bin with the .pl script and compared to a known-good dump, they were identical.
Dumped the ROM to a .bin with the console app, another compare was identical.
Programmed a BIN with the console app, dumped and diff'd - identical.

I really like loading the .hex directly, instead of using the 'stupid' HEX2BIN converter I made (stupid because it doesn't really parse intel HEX, it just grabs values from the file).

Could you please look at this bug report on the pirate loader source and see if it applies here?
http://whereisian.com/forum/index.php?topic=250.msg2412#msg2412

Could you please set 921600 as the default baud rate and add a configuration option?

Finally, is it feasible to limit writes to the data pages present in the HEX or BIN? Only the first 640 pages of data are used for the FPGA, but the writes continue through all 2048 pages.

Thank you so much for taking on this project. Great work.

Code: [Select]

C:\Perl\eg>pump-loader -p:COM5 -read -rB:dump4.bin -l:10
PUMP loader

Opening serial port 'COM5'... OK
Found PUMP HW: 1, FW: 0.1, Boot: 1
Found flash: ATMEL AT45DB041D
Will read 10 pages
Page 0x0000 read ... OK
Page 0x0001 read ... OK
Page 0x0002 read ... OK
Page 0x0003 read ... OK
Page 0x0004 read ... OK
Page 0x0005 read ... OK
Page 0x0006 read ... OK

Code: [Select]

C:\Perl\eg>pump-loader -p:COM5 -write -wB:pump.bin -l:680
PUMP loader

Opening serial port 'COM5'... OK
Found PUMP HW: 1, FW: 0.1, Boot: 1
Found flash: ATMEL AT45DB041D
Reading BIN file 'pump.bin' ... OK! (binary size = 169216)
Will write 680 pages
Page 0x0000 write ... OK
Page 0x0001 write ... OK
Page 0x0002 write ... OK
Page 0x0003 write ... OK
Page 0x0004 write ... OK
Page 0x0005 write ... OK
Page 0x0006 write ... OK

[robots]

Finally, is it feasible to limit writes to the data pages present in the HEX or BIN? Only the first 640 pages of data are used for the FPGA, but the writes continue through all 2048 pages.

Doesn't option -l:0 do the job ? :)

I can change the app to do this by default.

Another problem is the speed:
How long does it take to write those 641 pages ? The pirate-loaders serial function polls the serial port every 250 ms, i could change it to 10. This should increase the speed a lot.

New version available, with speedup and "write only what read":
http://robot.mysteria.cz/pump-loader.exe

[IPenguin]

The last version seems not to communicate with the PIC at all ... so it prompts "Opening serial port 'COMx' ... OK" it will do so for any COM port (COM2, COM3, ... COM20 regardless if the COM port exists or not) and then exit ...

[ian]

It does parse only the pages present in the bin successfully.

I have the same results with reads and writes. Very fast, but it's not actually using the port. I had to register the higher port speed in the perl script, maybe it's not going to be possible without a hassle in the C version.

The Perl script just pauses for 0.02 seconds and then the response byte is there :) I'd guess you're safe with 10ms polling.

[robots]

I had the debug option on :) I'm sorry, new version is up.

It does parse only the pages present in the bin successfully.

I have tried both hex and bin, and i get 641 pages on both.

[ian]

Perfect. Passed a full test and looks very professional.

The speed improvement is massive. Writes are good and reads fly by.

Is there a speed config switch so I can test even higher speeds?

Could you please add a usage example to the help menu.

This looks in order, I think you've got it wrapped up. When you're ready, would you please upload the source archive. I'll PM you about the PUMP.

[IPenguin]

No problem at all (debug option on) ... great job! :)

I did repeated write, read, erase cycles and tested different configuration images. All compares matched.

Switching to run and bootloader mode tested ok.

command -status seems not to be implemented ...