Firmware development

[ian]

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.

[ian]

Finished part 2 and tested with the Bus Pirate. Got expected terminal output at 115200bps.

Now on to #3.

[ian]

Finished testing the device with the Bus Pirate:
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.

[ian]

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

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.

[ian]

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.

[jack.gassett]

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.

[ian]

The ROM programmer firmware and PERL script are working. You can upload, dump, erase, and check the status byte:

Code: [Select]

C:\Perl\eg>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:\Perl\eg\pump-loader.pl line 52.

C:\Perl\eg>pump-loader.pl -i
Using: COM5
Read/write: 2048 pages
PUMP-Loader v0.1
Reading JEDEC ID: 0x1f240000
Found ATMEL AT45DB041D

C:\Perl\eg>
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.

[ian]

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-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-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-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.

[jack.gassett]

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.

[jack.gassett]

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.

[jack.gassett]

A 38400 bps version of the MCS file is checked into svn now.

Jack.

[ian]

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.

[IPenguin]

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.

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 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
Adding the termination and pull-up/pull-down resistors as suggested by Xilinx solved the problems in most cases.

[ian]

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. 

[jack.gassett]

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.