Firmware development

[colin.i]

Wow,  glad to hear that the bootloader worked the whole time!  I wondered why I couldnt find any errors!

Anyway, don't give up on it so soon!  The application that it comes with is sort of stupid and overly complicated.  It has like 20 files to do the simplest task.  I wrote a very simple application for Delphi that takes over the place of the Bootloader.  It can be very easily modified to work for you too...

[ian]

That's what I thought of the app. It's a sprawling ball of source for a simple HEX parser and packet pusher.

There is one change that I forgot to mention. There is a place where the code sleeps and waits for a USB activity interrupt. I had to change it to IDLE instead of sleep because it woke up (I believe) on the slower clock source and the PLL has to be re-enabled. After I got it working I rolled back this change and it stopped working, so I guess it was important.

[colin.i]

Ah that sounds logical.  Definitely was due to an architecture change, you were right!

What's the news with the Bootloader now?  You can adapt the code very very easily with a USB sniffer (USB Snoopy that you have works well).  That's what I did, and now my bootloader consists of a single progress bar and an "upload" button.  What's the plan?

[ian]

The bootloader is working now, I got help compiling the update app and successfully modified it. Attached is a complete toolchain for the PUMP.

The 2550 chips have a 32byte write page size, but the 24j50 has a 64byte page size. USB HID packets are limited to 64bytes, so there's no way to pack the header and data into a single packet. I started an alternating packet protocol, but instead used the 2byte write size available on the 24j50 chips. This is a MUCH slower way to update, we transfer 64bytes for each 2bytes programmed, but it works and can be improved upon later.

I used a reserved byte in the write packet to signal that the PIC should write the current data to FLASH, previously it happened at the end of every packet. This will make it possible to send 64bytes over 2 packets and not save until a flush is flagged in the second packet. This will require further modifying the application software, but no further bootloader changes should be needed.

I also updated everything to give a version number with the pump-loader utility (hardware, firmware, bootloader), and added a command to jump to the bootloader from the rom update mode (no jumper required).

Changes follow
----------------------------------
Bootloader firmware:
*adapted to write 2 bytes at a time.
*removed auto-write at end of packet, now uses reserved byte to signal flush (flush when reserved byte !=0)
*added version number constant at 0x7fe
*added new jump entry point

Bootloader app:
*adapted to send 2 bytes at a time
*sends 0xff as the reserve byte to flush on every packet.
*created multiple .bat files to ease operations

ROM updater (main firmware):
* Added version string command, read firmware version constant
* Added jump to bootloader command (no jumper needed, thus no header required on production models)
* Added support in pump-loader.pl script.

This is the current command protocol for the rom update mode, as documented in pump-loader.pl:

Code: [Select]

# Protocol:
# 00 00 00 00 - get PUMP hardware/firmware/bootloader string (return 7bytes)
# 01 00 00 00 - get 4 byte JDEC ID (returns 4 bytes)
# 02 XX YY 00 + 264 data bytes + CRC - XX=page (upper 4 bits XXXXA987) YY=page (lower 7 bits = 6543210X), CRC = 2s compliment, (returns 1 when done, 0 for CRC error)
# 03 XX YY 00 - XX=page (upper 4 bits XXXXA987) YY=page (lower 7 bits = 6543210X), (returns 264 bytes, 1 page)
# 04 00 00 00 - erase chip (returns 1 on completion, takes up to 6 seconds)
# 05 00 00 00 - get status byte (returns 1 byte)
# $ $ $ $ - jump to bootloader

[ian]

This is my todo list:

* Update fw_update.exe to send 64bytes over two HID packets with an alternating flush flag. Remember to flush if ending on a half page.
* Make native C apps for all platforms to replace pump-loader.pl, add HEX parsing to eliminate that extra step.

[ian]

Latest files are in both SVNs, google has handy line number links:
http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/#svn/trunk/SUMP%20PUMP%20logic%20analyzer

[ian]

And here's a walk though of the setup (as I do it myself):

Power the board (with the USB cable)
Burn the bootloader firmware with a PIC programmer.
Remove programmer, remove power.
Place a jumper between the PGC and PGD pins of the ICSP header.
Plug in USB. ACT LED lights. Bootloader enumerates as an HID device.
Remove the jumper. If you remove it now the bootloader will reset into user mode automatically, if not it will just return to the bootloader.
Run the firmware loader, or just use pump-program.bat:

Code: [Select]

fw_update -e -w -m flash -vid 0x04D8 -pid 0xFC90 -ix v1-pumpfirmware-v0a.hex

Code: [Select]

C:\Documents and Settings\ian\Desktop\pumpv01\firmware>fw_update -e -
-vid 0x04D8 -pid 0xFC90 -ix v1-pumpfirmware-v0a.hex
U2IO flash erasing: DONE.
U2IO flash programming: DONE.
RESET Device
Operation successfully completed.

C:\Documents and Settings\ian\Desktop\pumpv01\firmware>pause
Press any key to continue . . .
The chip is erased and then (slowly) programmed. Slowly is 30 seconds-ish. If I fix the app it will program in 1-2 seconds.
Remove the jumper (if you didn't earlier).
Press the reset button while holding the update button.
The ACT LED will light and it will enumerate as a USB virtual serial port. If it is the first time you plug it in, give windows the .inf file to assign the correct drivers to the device.
Run pump-loader.pl to verify that the firmware is listening:

Code: [Select]

C:\Perl\eg>pump-loader.pl -i
PUMP-Loader v0.1
Using: COM5
Read/write: 2048 pages
Reading firmware version:
Hardware: 1, Firmware: 0.1, Bootloader: 1
Reading JEDEC ID: 0x1f240000
Found ATMEL AT45DB041D
Use pump-loader.pl to upload a SUMP FPGA build into the ROM chip. If you use the -x flag it will exit to (what to call the modes?) SUMP mode and bridge the serial connection to the FPGA:

Code: [Select]

C:\Perl\eg>pump-loader.pl -w pump.bin -x
......
638
639
640
done.
Reset PUMP to run mode.
C:\Perl\eg>
To update the firmware:
1) Put a jumper over the PGC and PGD pins and press the reset button. The ACT LED will light and the device will enumerate as an HID device.

---or---
2) Enter ROM update mode by holding update and pressing reset. Run pump-loader.pl with the -b flag to jump to the bootloader. THe ACT LED will light, etc:

Code: [Select]

C:\Perl\eg>pump-loader.pl -b
PUMP-Loader v0.1
Using: COM5
Read/write: 2048 pages
Reading firmware version:
Hardware: 1, Firmware: 0.1, Bootloader: 1
Jumping to bootloader!

C:\Perl\eg>


-------------------------------
In normal run mode the ACT LED blinks while the FPGA loads. If the FPGA doesn't load after a few seconds, because of error or blank ROM chip, it goes into update mode and the ACT LED lights.

The ACT LED should blink when there is RX or TX activity.

The bootloader takes the PROG_B pin low when it check for the PGC/PGD jumper. A side effect is that the FPGA also resets and reloads when the PIC resets(and checks for bootloader entry).

There are three modes of operation:
* Bootloader
HID USB connection. Used to update firmware in PIC. Enter by placing a jumper between PGC and PGD and resetting, or running the pump-loader.pl with the -b flag in ROM update mode, the ACT LED will light. Use the fw_update.exe utility to load new PIC firmware with the bootloader.
*ROM update
USB CDC connection (same as SUMP mode). Used to update the FPGA design stored in the flash memory chip (IC2). Enter by pressing the reset button while holding the update button, the ACT LED will light. Use the pump-loader.pl utility to load new ROM .bin files.
*SUMP mode
USB CDC connection (same as ROM update). This is a transparent USB-> serial bridge to the FPGA. This is the default startup mode. Press reset to enter from any mode. The ACT LED will bink while the FPGA loads, and then turn off.

---
Edit: sorry, messed up my COM ports with portmon, had to reset to finish the how-to.

[colin.i]

How do you expect to program in 1 - 2 seconds?

[ian]

Using the Diolan with the 2550 USB IR Toy (32bytes flashed per HID packet) uploads a firmware several times bigger than the whole capacity of the 24j50 in seconds. If I upgrade the app/bootloader to split the 64byte program page size of the 24j50 between 2 packets I would expect the upgrade to take only seconds as well.

[colin.i]

Strange, when I use the fw_update program it takes about 20 - 30 seconds to upload a program to the 18F4455.  Using my own bootloader takes about the same time.

[ian]

It really zooms for me, but the firmware doesn't fill the chip, and I don't program/verify the EEPROM.

[Scorpia]

Ian

I wonder if windows is cacheing some of the write and doing it later? causing it to seem quicker

i know i can cache usb writes to hdd's and flash drives etc.

[colin.i]

Yeah, the Diolan bootloader fw_update program writes the whole HEX file, at 32 bytes per report.  Then it waits for a response before sending the next one.  That takes about 20+ seconds to complete for 24 kb of space -- mostly because it writes the empty space too.  If your code is 300 words, it will still write all 12288 of the space (which is stupid)!

Windows 7 or something?

[ian]

Nope, vanilla XP. I'm going to have to do some testing to make sure I didn't break anything, but it's really lightening fast for the USB IR Toy. I used the most recent release (sept of this year), maybe there were updates.

When I do my test I'll make a video and post it on youtube. I'd like to hear if it looks too fast/just right/etc.

[ian]

I did a big cleanup of firmware/bootloader/loader source in the SVN. I added a /package folder for the latest compile of all utilities and firmware. Attached are the current contents of the package folder.