I've been working on various parts of the firmware in anticipation of the PCBs arriving. Today I'm trying to put it all together.
Parts:
1. USB stack configuration -
Get the USB CDC firmware running on the PIC18F24J50. The clock starts slow, even if configured for PLL, remember to switch and wait.
2. UART configuration to FPGA - setup PPS, speed, etc.
3. ROM programming (pull prog_B low), PERL script to load new images
4. USB bootloader (need to adapt to hybrid 24f memory map in 18xxj chip).
5. Self test - check pins with pull-ups, are they what we expect?
Part 1 & 5 are completed. The USB part of the design works great, connected to CDC firmware, check pull-ups, light LED.
Next I'm going to setup the UART, write handling functions and test them with a Bus Pirate. Then the ROM programmer (today's part demo at dangerousprototypes).
The USB bootloader still needs some tweaks. It was my priority, but it makes more sense to get the firmware working then worry about the bootloader.
Finished part 2 and tested with the Bus Pirate. Got expected terminal output at 115200bps.
Now on to #3.
Finished testing the device with the Bus Pirate:
http://dangerousprototypes.com/2010/01/ ... t-spi-rom/ (http://dangerousprototypes.com/2010/01/25/demo-at45db041d-4mbit-spi-rom/)
Now I'm going to test the version of flashrom posted here that supports the BUs Pirate. If that works, I'll just make a Bus Pirate compatible interface in the PIC and we can use the Linux and Windows flashrom program to load the FPGA synthesis.
Read ROM ID and read ROM work. Write will work, but we need something to write.
Jack gave me a .mcs file to program. It's a basic .hex format, as described here:
http://www.xilinx.com/support/answers/476.htm (http://www.xilinx.com/support/answers/476.htm)
The ROM programmer part is NOT using the Bus Pirate interface. I designed a custom protocol for maximum speed given the size of the ROM and USB latency:
Commands are 4 bytes:
01 00 00 00 - Returns the 4 byte JEDEC ROM ID
02 XX XX XX - Reads 264bytes (one ROM page) starting at byte offset XX XX XX (note offset is bytes and not pages).
03 XX XX XX + 264 data bytes + 1 CRC byte - writes 1 page of ROM to page XX XX XX (note pages must be 264bytes, pad if less. XX XX XX is a PAGE address, not a byte offset!)
Now I'm going to write a PERL script to read the .mcs file and program it into the ROM.
added:
04 00 00 00 - Erase chip (takes 12 seconds, returns 0x01 success or 0x00 fail when complete)
05 00 00 00 - Get ROM status byte (returns ROM status byte)
03 Write also returns 0x01 success or 0x00 fail when the operation is complete.
The write CRC is the same as intel hex (sum data bytes, subtract last 8 bits from 0x100).
The firmware and loader perl script are working, but there's a minor addressing bug I still need to work out. I'll check everything into SVN tonight.
This is great, I just received my boards in the mail yesterday and am building them today. Once built I should be able to program the SPI flash chip with a JTAG programmer to verify that the FPGA side looks right.
Jack.
The ROM programmer firmware and PERL script are working. You can upload, dump, erase, and check the status byte:
C:Perleg>pump-loader.pl
# PUMP ROM programmer,
#
# -p <port> serial port to use
# -w <file> BIN file to write
# -r <file> read ROM to file
# -e erase ROM
# -s ROM status byte
# -i ROM JEDEC ID
# -l <pages> limit write or read to first <pages>
No file specified. at C:Perlegpump-loader.pl line 52.
C:Perleg>pump-loader.pl -i
Using: COM5
Read/write: 2048 pages
PUMP-Loader v0.1
Reading JEDEC ID: 0x1f240000
Found ATMEL AT45DB041D
C:Perleg>
The file needs to be a binary blob, but I wrote a perl script to make that from the HEX file.
Everything could be working except that I got hung up all afternoon figuring out a silly detail of PERLs command line parameters.
I'm about to test the serial bridge now. Hopefully it works and I can upload a test firmware yet today.
Here's where I'm at:
It looks like everything works, in theory, but there's still a bug.
The ROM programmer can program and dump the ROM chip with the binary I created from your HEX. A diff of the dump and source .bin shows them to be the same. I also used the Bus Pirate to read out the ROM and verify the write, maybe if you get to this point you can use a JTAG programmer to do the same. The FPGA loads, DONE goes high, the ARM and TRIG LEDs light (?).
The UART bridge sends data to the FPGA pin 35(AUX2/PIC B1/RP4) and receives from pin 34 (AUX3/PIC B0/RP3). I verified send and receive by attaching a Bus Pirate to the pins and watching/entering text in a terminal with a jumper over PROG_B. To test the FPGA I sent 5 times 0x00, then 0x02 for the SUMP ALS1 ID, but I don't get anything from the FPGA.
I uploaded the latest files to Jack's SVN and the Dangerous Prototypes google code SVN (because it's easy to link to).
Here's the PIC source and a compiled .HEX ready to burn:
http://code.google.com/p/dangerous-prot ... r/firmware (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/#svn/trunk/SUMP%20PUMP%20logic%20analyzer/firmware)
The first time you connect the PIC, windows will want a driver. CDC is a built-in driver, but you'll need the files in the /inf to point the way:
http://code.google.com/p/dangerous-prot ... rmware/inf (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/#svn/trunk/SUMP%20PUMP%20logic%20analyzer/firmware/inf)
The USB driver source is not redistributable, if you want to compile it you'll need to download the latest source and put the PUMP folder in the /Microchip Solutions/ folder.
Here's the PERL scripts for converting a HEX to a BIN, and for uploading the bin to the ROM:
http://code.google.com/p/dangerous-prot ... er/scripts (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/#svn/trunk/SUMP%20PUMP%20logic%20analyzer/scripts)
You'll need active PERL and the perl serial port driver to use it. See the instructions at the top of pump-loader.pl. Type just the name of either file to see a help screen.
--------------------------
I'm guessing that either I haven't written the ROM right, my hex2bin converter is doing something wrong, or the serial pins are swapped. I could also have an solder problem on my PCB somewhere.
I have to get my next monthly project published over the next two days, but I'll try to dig in some when I have a spare minute.
---------------------------
Using it:
1. Use bin2hex to make a binary blob
2. Start in ROM update mode by holding the upgrade button then pressing reset. The ACT LED will be solid.
2. use pump-loader to load the bin. Verify by reading the ROM and diff'ing the files.
3. Press the reset button. The ACT LED should blink until the FPGA loads and DONE goes high. There are two error codes: slow blink is a problem with the PROG_B pullup resistor, fast blink is DONE is still low.
I have a built board and just spent 30 minutes trying to figure out why nothing was showing up when I plugged the USB cable in. I finally realized that the chip must not ship with a bootloader and I'm going to have to download MPLAB and dig up my PICKIT 2 programmer. So I'm working on that next.
Jack.
Ian,
I was able to write the hex file to the PIC chip. When I plug the Sump Pump in the ACT LED blinks but Windows does not detect a USB device and prompt for a driver. The device manager does not show anything connected to the USB controller.
When I plug the Sump Pump in while holding the update button then ACT is solid and a USB device is detected and I am asked for a driver. I direct it to the inf folder in svn and it installs correctly. Now there is a new COM port that show up whenever I connect it while holding down the update button.
Howerver, there is still no device showing up when I do not hold down update. Is there an issue with the USB driver in the non-update mode or is that normal behavior?
Here are my thoughts on potential problems:
-No USB device is detected in standard non-update mode.
-I know there have been problems programming SPI flash chips for the S3E devices related to the need to byte swap the mcs file. I thought the correct format was generated by Impact now but that maybe not and that is our problem.
-As far as the pin direction for the UART bridge, I'm looking at the VHDL core. RX is pin 35 and from the perspective of the FPGA, so pin 35 is an input only pin. RX pin 35 on the FPGA is connected to is pin 22 (AUX2/PIC B1/RP4) of the PIC. TX is pin 34 configured as and output on the FPGA which connects to pin 21 ((AUX3/PIC B0/RP3) of the PIC.
-Another thing to do is to lower the speed of the UART on the FPGA to 38400, I had problems reaching 115200 with the FTDI chips over USB. I was hoping the problem was specific to FTDI chips as seems to be indicated in the Sump forums but maybe it is specific to USB. I will place an MCS file with the speed set to 38400 into SVN.
Jack.
A 38400 bps version of the MCS file is checked into svn now.
Jack.
Howerver, there is still no device showing up when I do not hold down update. Is there an issue with the USB driver in the non-update mode or is that normal behavior?
This is intended, but should be improved. The self test checks if the PROG_B pull-up is working, and then waits for DONE to go high. If PROG_B never goes high, then the LED blinks slowly, if DONE never goes high then the LED blinks fast. In both cases it get's caught in a loop prior to the USB setup. After you load a ROM image (either through the header or through the loader script) DONE will go high and the PIC will continue and connect to USB normal mode.
-I know there have been problems programming SPI flash chips for the S3E devices related to the need to byte swap the mcs file. I thought the correct format was generated by Impact now but that maybe not and that is our problem.
I read about this too, I'll try to look into it mode.
I haven't had the time to look at all the details, yet - two points come to my mind:
1. The Bits within each Byte need to be reversed when using SPI Flash instead of Xilinx configuration PROMs. However iMPACT or PROMGen will do this for you if you select 3rd party SPI Flash as the target ... see page 126 ff of the Spartan-3 Generation Configuration User Guide - ug332.pdf (http://http://www.xilinx.com/support/documentation/user_guides/ug332.pdf).
2. There is a chance that we may need to terminate the Clock and the Data line between SPI Flash and FPGA with 100 Ω towards +3.3V and GND ... see Spartan-3 Generation Configuration User Guide - ug332.pdf (http://http://www.xilinx.com/support/documentation/user_guides/ug332.pdf) page 58 ff (Figure 2-3:) - The SPI acts as the master during configuration so it's comparable with the FPGA Master --> FPGA Slave configuration shown in the document.
With the SPI programmer (Bus Pirate) connected to the SPI programming header we have a star topology - not sure if you disconnected the programmer. The total length of the signal stubs for Clock and Data is definitely longer than 0.5 inch or 12.5 mm, I think.
Other people have experienced similar problems and described them i.e. on the microcontroller.net forum:
http://www.mikrocontroller.net/topic/156133 (http://www.mikrocontroller.net/topic/156133)
Adding the termination and pull-up/pull-down resistors as suggested by Xilinx solved the problems in most cases.
I'm _really_ hoping it's as simple as reversing the bytes. I'll try to read more today.
An 'easy' test would be if someone could program the ROM with a known-working programmer. If the UART works there, please create a dump with the Perl loader script so I can see what it should look like in the ROM.
A file was just checked into svn that was loaded to the SPI flash using Impact and the jtag cable and then dumped with the pump-loader.pl script.
It is named 115200_jtag_loaded.bin and corresponds to the Sump_Pump.mcs file.
Jack.
I checked an MCS file into svn that maps the rx and tx lines to the LED's. When loading this mcs file to the SPI flash using the perl script and resetting the LED's show the rx and tx activity in the same manner as when I load by JTAG.
This seems to confirm that the perl script to program the SPI flash is working correctly. Now we seem to be having problems with stable UART communications.
Jack.
Well, great news! Everything seems to be working as expected now. I checked Sump_Pump_115200.bin into svn and this file loaded by the pump-loader script is working perfectly for me.
The key change seemed to be updating the logic type in the ucf file to LVCMOS33 instead of LVCMOS25 for the rx,tx, and clock lines!
Please check your boards and see if everything is working for you as well.
The pin numbering is not quite right still, will take a look a little later.
I was able to capture a 5V signal on each of the buffered lines, so the buffer seems to be working correctly as well.
Jack.
Just checked in a new file "Sump_Pump_3.bin" that uses the inside row numbering scheme.
I've been using this and the previous design with pretty good stability on the two different boards now.
Jack.
I'm catching up a bit here. I'm just loading the design now, and I'm going to verify the dumps and stuff. There is a problem in the dump you made for me that really concerns me. Could be a read error in my PERL script. I'm checking now.
I'm mulling the appropriate user interaction for the empty ROM/no !DONE state. Right now it doesn't enumerate, it sticks in a loop blinking the LED. I'm not really fond of it because it's confusing, but it is consistent with an unloaded device. I don't know if it will ship with the ROM programmed and how much extra that would save/cost. We should consider using some of the ample back silk area to write a big warning if it doesn't come with a programmed ROM.
Signs of life!
I used the loader script to erase, then program and verify the ROM, reset the PUMP. I used a terminal to send bytes, and got back the expected ID!
I checked in new versions of both my perl scripts:
*Comments
*better help
*better config switch handling
*Erase now polls for success instead of pausing 12 seconds (max erase time)
*New reset command -x (need new firmware too, coming shortly) to exit program mode, reset PIC, start over
*serial port works on Win32 and Linux
New PIC firmware:
*Added DONE timer. If it doesn't go up, the blinking led stops after a few seconds and it enumerates into ROM loader mode with solid ACT LED.
*Added reset command, exit updater, reset into run mode.
*returned to 115200
I'll check in the new firmware and source now.
Here's a picture of the first response in the terminal :)
I uploaded the latest bootloader code to SVN. It doesn't work, but I know what the problem is. Certain registers on the 18Fxxjxx chips need to have a bank set before they can be used. It's just a matter of searching for any use of these registers and setting the bank before using them. Hopefully that's the last think I have to do.
I've hit a snag porting the ASM bootloader to the 18F24j50. Windows sees the USB device, but says it malfunctions. Basically the pull-ups now work, but it's not sending anything correctly. I can't find any other relevant differences between the 24j50 and 2550 to reconcile, so I'm at a bit of a loss for the moment.
I'll start asking for help in the microchip forums and PIC list if I don't get it soon. There's also the Microchip bootloader we can use, and issue an update later, but I'd prefer to use the truly open source bootloader from the start.
Latest code is in the SVN.
---------------------------------
Here's the issues I've cleared so far:
1. Updated configuration fuses for 24J50
2. Removed EEPROM code (24j50 has no EEPROM).
3. Added PLLEN, delay for clock start and PLL lock.
4. Located non-access bank special function registers and added bank switching (most USB registers are not directly addressable).
Stuff to be done once USB works:
1. Ensure bootloader and jump instruction protection (not a problem, the 24j50 has protection fuses)
2. Protect the config bits, adapt to the 24F style config bits (minor task).
I work pretty much exclusively with the PIC series (mostly the 18Fx455 series) so I know exactly what troubles you guys are going through. USB can be a huge pain to debug, especially when you're getting that malfunction note.
What bootloader are you guys using? Maybe I can help out a little bit since I pretty much love this project.
Thanks conlin!
We're using the Diolan bootloader:
http://www.diolan.com/pic/bootloader.html (http://www.diolan.com/pic/bootloader.html)
It's for the 2550 series, but I've (mostly) ported it to the 24j50.
The latest port code is here:
http://code.google.com/p/dangerous-prot ... tloader/fw (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/#svn/trunk/SUMP%20PUMP%20logic%20analyzer/bootloader/fw)
I also posted a request for help on the Microchip forum:
http://www.microchip.com/forums/tm.aspx?m=474647 (http://www.microchip.com/forums/tm.aspx?m=474647)
Any suggestions are greatly appreciated. I'm going to step through the code one more time, and then compare it to a step through working code on a 2550 and see if I can pick up on anything.
Well aren't you lucky. I only work with the Diolan bootloader, and I even wrote a small tutorial on it!
http://www.nilok.ca/products/bootloader/index.php (http://www.nilok.ca/products/bootloader/index.php)
Fantastic! Some things you should know about my port:
*I used it successfully with the usb ir toy project (18f2550) that I posted today at http://dangerousprototypes.com (http://dangerousprototypes.com)
*I stripped the XTEA encryption stuff
*I replaced all extended instruction set instructions so it works with C18 demo version compiled firmware.
So you have a working version. Good. In that case, what are the differences between the PIC18F2550 version you posted this morning and the 24J50 that you're using in this project? Specifically what files and what sections of code (aside from the obvious config bits, linker, etc).
So far I've done these things to all code files, as well as strip any EEPROM related stuff (no eeprom on this chip):
Updated configuration fuses for 24J50 (boot.asm)
Added PLLEN set, delay for clock start and PLL lock. (boot.asm)
Located non-access bank special function registers and added bank switching (most USB registers are not directly addressable). (mostly in boot.asm but also 1 in usb.asm, look for !!!18F24j50 change!!! in the code).
I do have a VID/PID that I'm using, but it's not included in the SVN.
That's what I've done so far, I'm still trying to find out if there are architectural differences I need to account for. I get 'USB device not recognized" when I plug it in.
Great. Once I get this SVN stuff figured out I'll take a look at the firmware. The USB VID & PID still show up in the revisions list by the way ;)
The easiest SVN client (for windows) is TortoiseSVN:
http://tortoisesvn.net/ (http://tortoisesvn.net/)
I also attached the current latest source to this post.
The PID got in there by accident, I'll have to dump the SVN to get rid of it.
Sorry, here's the source.
How far does the firmware run? Do you have an LED set up to blink or anything like that? Have you messed with the config bits? Why do you have the config USBDIV commented -- is it due to the PLL startup or something? Have you tried using a snooper on the USB lines?
Its sort of hard to debug if I don't know where you stand on this :) Unfortunately I don't have any spare 18F24J50s lying around :)
Yes, I replaced the config bits with a working set from my CDC firmware for the J chip.
USBDIV is not a config option on the 18f24J50 PICs. It is fixed /2.
I don't have a snooper for the USB lines, and there's nothing going on in Windows to snoop at the OS level.
The firmware runs as expected, the USB configuration setup is correct and the USB pullup resistors are enabled, the OS sees the pull-up and detects a USB device insertion, but from there nothing happens. During debug it hits the sleep instruction around line 253 of boot.asm a lot, but seems to wake up on interrupt every time. It's hard to tell with debug because it slows it down so much that it also causes unknown device errors.
Since the USB peripheral is nearly the same, except the banking required to reach the registers, I assume it's another architectural difference I'm not getting. I've confirmed that there's no special J part defines in the CDC firmware, so I'm strongly inclined to believe it's some ASM that's incorrect for the 18xxjxx chips.
Okay I'll start looking through the ASM specifically now. Out of curiosity, have you tried SnoopyPro for the USB? It goes down fairly low level, not sure if it can read activity without a VID and PID pair but since I don't have hardware I can't test it myself.
Yes, that's the program I use. I couldn't get it to show anything at the enumeration state it got to (no VID/PID as you say, just !SE0)
When I run the simulations, everything seems to be fine. Obviously I can't test with an actual USB request being sent unless you know how to emulate that in MPLAB. Ive checked over the config bits briefly (I assume they work since you've used them before) and I went through instruction by instruction, watching the SFR values. Everything seems to be fine as far as your initialization goes...
I'm a little tight on time for today, but later on I'll try to fake a packet or something and see how the firmware responds. Let me know if you make any progress!
Checked into svn is a new VHDL project to generate signals for testing the Sump Pump board. This testing core can be loaded on a second Sump Pump board and the two can be connected with a ribbon cable. The code is checked into svn here (http://http://www.gadgetfactory.net/gf/project/butterflylogic/scmsvn/?action=browse&path=%2Ftags%2FCounter_Test%2F). A 100Mhz signal is generated on channel 0 of the outside row numbering scheme. The frequency is cut in half for every channel after that.
The initial results from testing with my two prototype boards is located on my wiki page. There were so many pictures that it was not practical to post them all here.
Initial Results in the Project Wiki (http://http://www.gadgetfactory.net/gf/project/butterflylogic/wiki/?pagename=BoardTesting)
The results are that it looks like the 200Mhz sampling frequency is able to capture the 100Mhz signal on both the buffered and unbuffered pins. The unbuffered pins seem to have less noise and glitches than the buffered pins.
It looks great! So... when can I buy one?
I'd like to buy one too!
Ha! Got the bootloader to enumerate as USB HID. I think it was the register problem, but then I only ran it under debug, never as a complete app, so the timing was messed up. A last desperate attempt to get it to work, and bang, it worked!
I'll get it reading and writing tomorrow. Then some stress testing of the firmware to go with Jack's testing of the FPGA, write an article, and we're ready!
[quote author="jack.gassett"]
The results are that it looks like the 200Mhz sampling frequency is able to capture the 100Mhz signal on both the buffered and unbuffered pins. The unbuffered pins seem to have less noise and glitches than the buffered pins.
[/quote]
Jack:
Would it be posible to check with serial termination resistors, to see if that would clear the glitches?
The bootloader seems to be working well. I've updated it with a bit of extra protection to guard against erasing the bootloader or config bits.
Another snag I hit is that the 24j50 erases 1024byte pages instead of the 2550 64bytes, and the 24j50 writes 64bytes at a time instead of 32bytes. This is going to require some updating of the bootloader app.
The app is VC++, I've downloaded the free express edition and I'm installing the driver pack for HID now. I'm going to take a stab at compiling it, and then updating it. If there are any VC++ developers listening, I might need your help before this is all over.
As a precaution, I also got the Microchip bootloader working. It's not redistributable, and the app is only windows/.net, so it leaves a lot to be desired. If I can't get the Diolan bootloader working, this is ready to go. We can't get the PUMP produced before the Chinese holiday over the next two weeks, so there's no major rush.
Wow, well that was quick. I got the windows driver development kit so I'd have the required .h files to use USB HID, but I get hundreds of errors. I'm not a PC developer, so while I can modify the code to work with the diolan bootloader, there's really no way I'm going to get this updated if there's lots of things to be fixed. I guess I'm going to give up on the diolan bootloader and use the Microchip bootloader instead. Too bad.
Can you give me the link to the VC++ project ? I'll give it a try. Windows is not my primary development platform. But if you use the right hammer ... :))
I can now compile the fw_update. :)
I can either tell you how to setup the environment or i can compile patched file for you. Can you drop me an email ? so i don't have to poll for reply
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...
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.
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?
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:
# 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
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.
Latest files are in both SVNs, google has handy line number links:
http://code.google.com/p/dangerous-prot ... 20analyzer (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/#svn/trunk/SUMP%20PUMP%20logic%20analyzer)
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:
fw_update -e -w -m flash -vid 0x04D8 -pid 0xFC90 -ix v1-pumpfirmware-v0a.hex
C:Documents and SettingsianDesktoppumpv01firmware>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 SettingsianDesktoppumpv01firmware>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:
C:Perleg>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:
C:Perleg>pump-loader.pl -w pump.bin -x
......
638
639
640
done.
Reset PUMP to run mode.
C:Perleg>
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:
C:Perleg>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:Perleg>
-------------------------------
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 updateUSB 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 modeUSB 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.
How do you expect to program in 1 - 2 seconds?
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.
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.
It really zooms for me, but the firmware doesn't fill the chip, and I don't program/verify the EEPROM.
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.
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?
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.
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.
I just followed your directions and got the bootloader up and running correctly. I will test the bootloader application next.
Hey Colin, if you're still listening --
I promised a video of bootloading on the irtoy. Here's a screen capture.
http://www.whereisian.com/files/irtoy-flash.swf (http://www.whereisian.com/files/irtoy-flash.swf)