PiratePICprog console application

[ian]

The .NET programming app 7 wrote is great. It has rescued a bunch of Logic Sniffers, and we learned how to program PICs.

For continued development though, I'd like to build a cross-platform console app. I'm going to use pump-loader as the basis because it has all the parts I need.

This thread will document my progress knocking together an initial simple application framework.

I already documented my attempt to compile pump-loader under MinGW:
http://dangerousprototypes.com/2010/06/16/intro-to-mingw-compile-pirate-loader/

Now I'm going to:
*Modify for binmode entry, setup raw2wire.
*Add ICSP entry
*Add readID
*Use new 4/16 command format in v5 firmware.

I'll be updating my code to SVN here:
http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/#svn/trunk/PiratePICprog

[ian]

Pretty good progress today, mostly because I'm borrowing all the hard work 7 did earlier.

The current version (in SVN, exe attached) does these things successfully:
1. Enters ICSP
2. Reads PIC ID and parses it.
3. Erases the PIC

It requires the updated PIC 4/16 command in the latest Bus Pirate nightly firmware (also attached).

Run it like:

Code: [Select]

E:\Work\dp-svn\trunk\PiratePICprog>piratepicprog --dev=COM3 --hello
+++++++++++++++++++++++++++++++++++++++++++
  piratePICprog for the Bus Pirate
  Loader version: 1.0.2  OS: WINDOWS
+++++++++++++++++++++++++++++++++++++++++++

Opening serial device COM3...OK
Configuring serial port settings...OK
Entering binary mode...BBIO1(OK)
Entering rawwire mode...RAW1(OK)
Setup mode...(OK)
Setup peripherals...(OK)
Entering ICSP...
Set mode for PIC programming (LSB)...(OK)
PIC ID: 0X260 (18F24J50) REV: 0X2
Erasing the PIC (please wait)...(OK)

E:\Work\dp-svn\trunk\PiratePICprog>
Sorry, there's no configuration options right now, it just goes through the motions. The code is an awful mess, and most errors aren't even checked, etc.

Today or tomorrow I'll add program, and maybe read. The code already has a HEX parser, so it's just a matter of adopting it to our needs.

[ian]

Sorry, attachments.

[ian]

Couldn't leave it alone, but this is it for now. It's been a fun day of learning to write software for the desktop.

Added write page function. Writes first page of flash with 0-31, twice. Works fine in test & dump.

All that's really left of a test app is to connect the HEX parser function with the program function in a loop. A read chip function would be nice, but 7 didn't write one and I'm not sure it's important enough for me to pioneer right now. Need to add command line options for program, erase, ID, etc.

Code is really ugly and needs a good PC C programmer to give it some TLC :)

Code: [Select]

E:\Work\dp-svn\trunk\PiratePICprog>piratepicprog --dev=COM3 --hello
+++++++++++++++++++++++++++++++++++++++++++
  piratePICprog for the Bus Pirate
  Loader version: 1.0.2  OS: WINDOWS
+++++++++++++++++++++++++++++++++++++++++++

Opening serial device COM3...OK
Configuring serial port settings...OK
Entering binary mode...BBIO1(OK)
Entering rawwire mode...RAW1(OK)
Setup mode...(OK)
Setup peripherals...(OK)
Entering ICSP...
Set mode for MCLR (MSB)...(OK)
Set mode for PIC programming (LSB)...(OK)
PIC ID: 0X260 (18F24J50) REV: 0X2
Erasing the PIC (please wait)...(OK)
Exit ICSP...
Entering ICSP...
Set mode for MCLR (MSB)...(OK)
Set mode for PIC programming (LSB)...(OK)
Writing the PIC (please wait)...
Exit ICSP...
Done!

E:\Work\dp-svn\trunk\PiratePICprog>pause
Press any key to continue . . .
Updated version (source and single .exe file) can be download from the SVN via a web browser, so I'm not going to attach a new release to this post. Just download from google here:
http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/#svn/trunk/PiratePICprog

Edit: latest SVN direct download...
http://dangerous-prototypes-open-hardware.googlecode.com/svn/trunk/PiratePICprog/piratePICprog.exe

[ian]

Latest version now reads, parses, and programs a .hex file. with --verbose it shows all data and the address it is programmed at. This looks fine, but the actual data dumped from the PIC is of by bytes or pages after the first few pages.

I left the hex parser and sendfirmware routines in a bit of a mess. They had to be converted from the 3byte (4 byte?) words of the 24FJ bootloader to the 2byte words of the 18F. Eventually they will both need to be made adjustable/universal so that it can parse HEX files with different lengths (all this needs to be stored in a struct or XML file somewhere).

It does it really fast, and without entering and exiting ICSP on every write like the .net programmer. I think that is due to the new commands that read/write 20bit commands directly, instead of tiny chunks. It's much, much faster.

XX00YYYY
XX=delay, 0=none, 1=1ms, 10=2ms, 11=3ms
YYYY=4bit command (second byte of PIC programmer write command)

Also added a delay option to the PIC write command. the upper two unused bits of the 4/6bit command byte give a delay in ms. If it is >0, the last clock bit of the command will be held for 1, 2, or 3 MS. The 18F24J50 needs 1.2ms (1 seems ok), lower parts in that family need 3ms, we might need to adjust the values depending on future families. A nightly with this change is in the piratePICprog folder.

Changes:
*load and parse HEX seems to work
*passes HEX to write, address seems off
*only enters ICSP once, not on every page
*updated hex parser for 16bit data

To do:
*Clean HEX parser, make it universal/configurable (different PIC word lengths/page size/flash length in variables instead of defines)
*Make sendFirmware function adjustable, configurable (page size, pic flash length)
*Fix addressing issue that writes to wrong address in PIC flash
*Massive code cleanup (move functions to other files)
*Better read with timeout (smaller delay?), binmode entry
*Enable options - --id --e(rase) --pic:18F24J50 --r(ead):dump.hex
*Add read??
*search through .HEX and mark 0xff pages unused.
*Determine a structure to store the various PIC constants: (see update in the post below)

Code: [Select]

E:\Work\dp-svn\trunk\PiratePICprog>gcc piratePICprog.c -o piratePICprog.exe

E:\Work\dp-svn\trunk\PiratePICprog>piratePICprog --dev=COM3 --hex=pump.hex --verbose
+++++++++++++++++++++++++++++++++++++++++++
  piratePICprog for the Bus Pirate
  Loader version: 1.0.2  OS: WINDOWS
+++++++++++++++++++++++++++++++++++++++++++

Parsing HEX file [pump.hex]
Found 1040 words (3120 bytes)
Opening serial device COM3...OK
Configuring serial port settings...OK
Entering binary mode...BBIO1(OK)
Entering rawwire mode...RAW1(OK)
Setup mode...(OK)
Setup peripherals...(OK)
Entering ICSP...
Set mode for MCLR (MSB)...(OK)
Set mode for PIC programming (LSB)...(OK)
PIC ID: 0X260 (18F24J50) REV: 0X2
Erasing the PIC (please wait)...(OK)
Exit ICSP...
Entering ICSP...
Set mode for MCLR (MSB)...(OK)
Set mode for PIC programming (LSB)...(OK)
Writing page 0, 0000...
F8 6A F7 6A 03 D0 00 00 04 EF 04 F0 75 D2 FF FF FF FF FF FF FF FF A1 D0 0C EF 04
 F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F
F FF FF 12 01 00 02 00 00 00 40
Writing page 1, 0040...
D8 04 90 FC 22 00 01 02 00 01 09 02 22 00 01 01 00 80 32 09 04 00 00 01 03 00 00
 00 09 21 01 01 00 01 22 17 00 07 05 81 03 40 00 01 05 0C 09 00 A1 02 09 00 95 4
0 75 08 81 00 09 00 95 40 75 08
Writing page 2, 0080...
91 00 C0 04 03 09 04 0E 03 44 00 69 00 6F 00 6C 00 61 00 6E 00 FF 08 0E 81 51 80
 6B 7F D8 0D 0E 83 6F A6 88 84 D8 04 0E F7 26 83 2F FA D7 12 00 72 D8 00 EE C4 F
0 09 00 F5 CF EE FF 60 2F FB D7
^CTerminate batch job (Y/N)?

[liyin]

What's the relationship between the PiratePICprog and the PIC programmer adapter?

[ian]

12F/16F/18F PICs need a 13volt power supply on the VPP pin to enter programming mode, the PIC programming adapter generates and controls the 13volt supply with a few transistors and a boot converter.

[liyin]

Because there are several projects about using the BP as a programmer, I wanted to clarify what are the software requirements for using the BP/Adapter (what's coming).

AFAIK, there's an application to program 2 specific PIC's (PIC24... & PIC18...) with the BP. It's supposed to support more PIC's later on

Does the PiratePICprog support more PIC's at this stage?

What programming software currently supports the BP for programming PIC's? Do you just add the adapter for high voltage programming?

[ian]

The 18FxxJ chips and the newer PICs (24/30/33) don't use the 13volt programming voltage, so they can be programmed by the Bus Pirate without the supply/adapter. PICs that require the 13volt programming voltage (12F/14F/16F/18F) will need the adapter (or another 13votl power supply) to be programmed.

Right now there are two PIC programming apps.

There's the .net one we released to rescue the open logic sniffer that shipped without a bootloader. It programs the 18F24J50 only (limited script support for the 24J64GA002), but we learned what we needed to get a PIC programmed. This app probably won't be developed further because it's .net and many people don't like .net/mono.

PiratePICprog is the new console (command line) application I'm working on now, it will replace the previous programmer. It's written in C and compiled with the free/open source MinGW/GCC compiler. It has the advantage of being simple (one .exe file), cross-platform (Windows, Linux, Mac, Solaris, etc), and doesn't depend on a hundred+ meg framework. There's still a lot of work to do, but it has all the basic functions implemented in the code to work with the 18F24J50. After the first chip is working, we'll add 24J64GA002 support, and then try to abstract things a little so that we can support all the chips in a compatible family (for example 18F24J10-18F44J80, instead of just the 19F24J50). Each family of PIC chips has to be implemented separately, and we've only conquered a single chip in one family so far.

Neither program currently supports the programming adapter, I'll have to write support for it when we add a chip that needs it, probably the 18F2550-18F4550 family used on the IR Toy. I have to get PCB for the adapter made, prototyped, etc too. This project is just getting started.

[Sjaak]

There was also some (hardcore) way to program lowend pics (and a script on the BP). That used a preliminary version of the HVP adapter.

Actually lowend pics are easier to program as they don't use their ICE interface to write the flash.

[ian]

I updated the rawwire documentation with the new PIC read/write commands:
http://dangerousprototypes.com/2009/10/27/binary-raw-wire-mode/

[ian]

I figured out the addressing issue, forgot to clear the upper bits when setting the address. The current .exe in SVn now programs a 18F24J50 perfectly :)

Moved the tblprt setup to a function and adapted other functions to use it.

Started read function, will test in a minute.

[ian]

Latest version in SVN now supports reading back (dumping) from the PIC. Removed some commands that are no longer needed.

This is looking really good :) The next step is probably to make it work in response to command like options, but maybe it's smarter to abstract all the PIC programming stuff into a separate file and then start building this app on top of pump-loader because it's a little more developed and has richer features.

Here's the portion of the output when the program reads the first 256 bytes of the PIC:

Code: [Select]

Skipping page 254 [ 003f80 ], not used
Writing page 255, 3fc0...
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F
F FF FF A8 F7 5D FF 63 F8 04 F1
Exit ICSP...
Read PIC test...
Entering ICSP...
Set mode for MCLR (MSB)...(OK)
Set mode for PIC programming (LSB)...(OK)
F8 6A F7 6A 03 D0 00 00 04 EF 04 F0 75 D2 FF FF FF FF FF FF FF FF A1 D0 0C EF 04
 F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F
F FF FF 12 01 00 02 00 00 00 40 D8 04 90 FC 22 00 01 02 00 01 09 02 22 00 01 01
00 80 32 09 04 00 00 01 03 00 00 00 09 21 01 01 00 01 22 17 00 07 05 81 03 40 00
 01 05 0C 09 00 A1 02 09 00 95 40 75 08 81 00 09 00 95 40 75 08 91 00 C0 04 03 0
9 04 0E 03 44 00 69 00 6F 00 6C 00 61 00 6E 00 FF 08 0E 81 51 80 6B 7F D8 0D 0E
83 6F A6 88 84 D8 04 0E F7 26 83 2F FA D7 12 00 72 D8 00 EE C4 F0 09 00 F5 CF EE
 FF 60 2F FB D7 6A D8 00 EE 84 F0 0A 00 EE CF F5 FF 0F 00 60 2F FB D7 82 B1 6C D
8 12 00 15 D8 00 EE C4 F0 09 00 F5 CF EE FF 60 2F FB D7 F8 6A 12 00 0B D8 00 EE
84 F0 A6 88 5C D8 EE CF F5 FF 0D 00 60 2F FB
Exit ICSP...

Firmware updated successfully :)!
Done!

E:\Work\dp-svn\trunk\PiratePICprog>pause
Press any key to continue . . .

[ian]

Here's a list of info we'll need to store for each chip. Some of it is family based, so we could have chip-specific info and link to shared family details.

Chip specific (will varry for each member of a family, for example 18F2xJxx/18F4xjxx):
Chip name: 18F24J50 (example values)
Device ID: 1 or 2 byte ID for this chip (0x4c)
Program memory: how many bytes of program memory are in this chip? (16Kbytes)
EEPROM amount: how much eeprom (0)

Family specific (will be the same for all members of a family):
Protocol type: 4/16 for the 18F, 6/14 for the 16F, etc
Device ID location: 4 byte address where the device ID is read from (0x3fffe)
Word length: how many bytes per memory unit (2)
Page length: how many words (or bytes?) per write page (64)
ICSP type: low VPP or 13volt VPP programming entry method (low VPP)
ICSP low VPP key: a 4byte value used to enter ICSP mode for low VPP method chips (0x4D434850)
Erase key: unique values to write to do a bulk erase on this chip (see code, values for a 18Fxxxx is 0x3f3f, 0x8f8f)

Code: [Select]

        PIC416Write(0,0x0E3C);
        PIC416Write(0,0x6EF8);
        PIC416Write(0,0x0E00);
        PIC416Write(0,0x6EF7);
        PIC416Write(0,0x0E05);
        PIC416Write(0,0x6EF6);
        PIC416Write(0x0C,0x0101);//special for each PIC
        PIC416Write(0,0x0E3C);
        PIC416Write(0,0x6EF8);
        PIC416Write(0,0x0E00);
        PIC416Write(0,0x6EF7);
        PIC416Write(0,0x0E04);
        PIC416Write(0,0x6EF6);
        PIC416Write(0x0C,0x8080);//special for each pic
P9 write time delay: time to delay for a page of memory to be written (1ms)
P11 bulk erase delay: the amount of time to delay while the chip is erased (524ms)

Just some notes on the info we might need to track.

These values will be needed to, for example, properly parse and then send the .HEX file to the PIC.

[rsdio]

EEPROM: does this chip have EEPROM (no)
EEPROM amount: how much eeprom (0)

My comment here is very minor:
Couldn't you just have a single entry for EEPROM?
If the amount is (0) then the answer is (no) but any non-zero amount would mean (yes)

Overall, this looks like a great start!

P.S. Can the ICSP interface be used to query the PIC type?  I notice that the PICkit 2 programming software does not automatically detect the chip type - possibly because the voltage is unknown and it could damage the chip to use the wrong voltage - but after you tell the software which family you have, it can confirm the exact chip model.