Skip to main content
Topic: PiratePICprog console application (Read 35452 times) previous topic - next topic

Re: PiratePICprog console application

Reply #15
[quote author="rsdio"]
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.
[/quote]

Every pic has a device-id (except the pic10f) so theoretical yes, but the voltage is the problem. For autodetecting you could start with 3v3, try to get a response and switch to 5v if needed.

When reading the type with highend pics will need the family as you need to run a program through icsp to report the devid. The assembly for reading the devid is different for each family.

Re: PiratePICprog console application

Reply #16
Thanks, I updated the list.
Quote
P.S. Can the ICSP interface be used to query the PIC type?

To an extent. I think the ID is 11bits (i think) so it's too short to give each PIC a unique number.  There's a nice chart in the datasheet (attached as an example).

Googling around I found this great page on the JALlib google code wiki:
http://code.google.com/p/jallib/wiki/PicPgmGroups

It has the programming specs for 346 PICs (10/12/14/16/18F chips only) arranged into 48 groups of chips that use the same algo. I'll start with the PICs in DP projects and low-voltage VPP chips that can be programmed directly, it doesn't look like most of the 18F algos differ much.

I'll see if I can add 24F64GA002 today.
Got a question? Please ask in the forum for the fastest answers.

Re: PiratePICprog console application

Reply #17
[quote author="ian"]
To an extent. I think the ID is 11bits (i think) so it's too short to give each PIC a unique number.  There's a nice chart in the datasheet (attached as an example).
[/quote]

11 bits can address 2048 different pics :D The 11 bit is only used for lowend pics.

Pic24 (and pic30/33 i think) like the buspirate use a 32bit value.

[quote author="ian"]
Googling around I found this great page on the JALlib google code wiki:
http://code.google.com/p/jallib/wiki/PicPgmGroups

It has the programming specs for 346 PICs (10/12/14/16/18F chips only) arranged into 48 groups of chips that use the same algo. I'll start with the PICs in DP projects and low-voltage VPP chips that can be programmed directly, it doesn't look like most of the 18F algos differ much.
[/quote]

Why invent the wheel again? You could reuse this code: http://code.google.com/p/the-bus-pirate ... ROG/prog.c

Re: PiratePICprog console application

Reply #18
Quote
Why invent the wheel again? You could reuse this code: http://code.google.com/p/the-bus-pirate ... ROG/prog.c

You're totally right. I didn't want to use this code because I don't use GPL with the Bus Pirate (only public domain). But I have no problem licensing this app under GPL :)
Got a question? Please ask in the forum for the fastest answers.

Re: PiratePICprog console application

Reply #19
Quote
11 bits can address 2048 different pics :D The 11 bit is only used for lowend pics.

Sorry, editing error. I originally wrote 5bits, then took the screenshot and realized it was 11, changed the bits but not the assumption. It's probably to force manual selection of voltage level and ICSP mode then?
Got a question? Please ask in the forum for the fastest answers.

Re: PiratePICprog console application

Reply #20
[quote author="ian"]
It's probably to force manual selection of voltage level and ICSP mode then?
[/quote]
manual override is always a good thing ;)

from my notes when writing the BP piclibrary, i see the devid is stored @ 0x2006. If I remember correctly it is pretty much the same for each lowend pics (pic12,14,16). When you use the commandline on the bp:

Code: [Select]
[0]0 [6:6 4] r

or use macro 1 ;)

Re: PiratePICprog console application

Reply #21
I'm indulging in a bit of work on this over lunch. I need to get it to a point where robots can see where it's going and consult on a good structure for future expansion. Using #defines and comments, I've modified the current source to read/write/erase the PIC 24FJ64GA002 in the Bus Pirate. I updated the binwire mode with a new command to set pic read/write type. I will upload to SVN once it's working.

10100000 + protocol number
This rawwire command sets the PIC programming protocol.
0=6/14 for 10/12/16F (unimplemented)
1=4/16 for 18F chips
2 = 4/24 for 24F chips

4/16 is already documented on the rawwire manual page. Here's how the 4/24 works:

write: send the writePIC command + 3 bytes. The 3 bytes are the 24bit PIC instruction to be shifted in with a 4bit SIX command (yeah, it's actually named that). BP responds 0x01 for success
read: send the readPIC command, bus pirate responds with 2 bytes. THe bus pirate send the 4bit REGOUT command, a dummy byte, and then reads two bytes from the PIC. The two bytes are returned.

Currently erase kind of works, but it seems to set everything to 0x00 instead of 0xff. I'm going to tackle the ID instead, the ID script works with the .net programmer in script mode, it implements a read and write, and it's obvious when you've succeeded without dumping the chip with a programmer every time.
Got a question? Please ask in the forum for the fastest answers.

Re: PiratePICprog console application

Reply #22
[quote author="ian"]Currently erase kind of works, but it seems to set everything to 0x00 instead of 0xff.[/quote]That's strange. I thought that it was always 0xFF, but perhaps I never paid close attention.

The 18F87J50 Family has bulk erase via ICSP only, and block/row erase from the PIC firmware (1024 bytes/512 words). I don't know if I've ever checked the results of a bulk erase versus a block/row erase. Could they be different?

Looking at the data sheet, they mention (for this one family) that Bulk Erase is the only way to change the Code Protection bit from ON to OFF. I don't know whether OFF is 0x00, but is it perhaps possible that Bulk Erase sets all Flash to 0x00 just so the Code Protect is turned off? ... nevermind, a quick scan of another data sheet says that '0' means Protect and '1' means no Code Protect.

Hmm.  I'm sure you'll figure it out...

Re: PiratePICprog console application

Reply #23
I never saw a flash chip that when erased return all 0x00's :S

Somewhere in the forum there is a document that 'generally' describes the programming algo for lowend pics. It is somewhere in a picprogramming topic (in the development section instead of here) I can't seem to find...

Re: PiratePICprog console application

Reply #24
Got the read ID working, then spend some time trying to understand it. I'm pretty happy with the read function. Now need to get erase working and then write :) Latest code is in the SVN.

Code: [Select]
E:Workdp-svntrunkPiratePICprog>gcc piratePICprog.c buspirateio.c serial.c -o
 piratePICprog.exe

E:Workdp-svntrunkPiratePICprog>piratePICprog --dev=COM3 --hex=pump.hex --ver
bose
+++++++++++++++++++++++++++++++++++++++++++
  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)
Set 4/24 programming mode...(OK)
Entering ICSP...
PIC ID: 0X447 (24FJ64GA002) REV: 0X3042 (1.2)
Exit ICSP...
Done!

E:Workdp-svntrunkPiratePICprog>pause
Press any key to continue . . .
Got a question? Please ask in the forum for the fastest answers.

Re: PiratePICprog console application

Reply #25
There are just a TON of NOPs between most operations, 1-3 usually. This takes up a ton of time to send each command, and reads especially are slow because every 2 bytes read takes 4 NOPs of 5bytes each. I updated the Bus Pirate 24F read function to always issue 2 NOPs after the read. This is the only way reads are done, and should always work.

I updated the write command to have adjustable pre-operation and post-operation NOPs. The PIC24 write instruction command for the BUs Pirate is now needs 4 bytes of payload:
Byte 1-3 are the PIC command to send
Byte 4: upper 4 bits are the pre-op NOPs, lower 4 bits are the post-op NOPs.

Byte 4 tells the Bus Pirate how many NOPs to send before and after the instruction. Offloading this to the Bus Pirate increases the speed a lot, because most command require 1-2 NOPs. Currently pre-op NOPs are unimplemented because it's only needed in once place, the post-op NOPs can send 0-16 NOPs to the PIC after the instruction is written. This appears solid, I'm going to work on erase and write now.

Code: [Select]
+++++++++++++++++++++++++++++++++++++++++++
  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)
Set 4/24 programming mode...(OK)
Entering ICSP...
PIC ID: 0X447 (24FJ64GA002) REV: 0X3042 (1.2)
Exit ICSP...
Entering ICSP...
Exit ICSP...
Read PIC test...
Entering ICSP...
00 A8 00 00 76 A9 76 A9 76 A9
Exit ICSP...

Firmware updated successfully :)!
Done!

E:Workdp-svntrunkPiratePICprog>pause
Press any key to continue . . .
Got a question? Please ask in the forum for the fastest answers.

Re: PiratePICprog console application

Reply #26
Used open programmer source to figure out the correct erase command. Implemented it with WR bit polling, so it's better than the Microchip ICD2 algorithm, but not faster :)

Open Programmer has done a ton of work and most of the hard stuff. Now that I'm familiar with their code, I'm going to have to figure out if I should try to use parts of it, switch to a C++ project and mod the existing app to work with the Bus Pirate, or what... It would be cool to have a multi-hardware app, that included the USB Open Programmer hardware, the Bus Pirate, and a FTDI-based programmer that's been suggested. My main concern is not having to compile against the USB driver (downloading MS DDK was a headache), but Open Programmer has a comment that you don;t need DDK.

Code: [Select]
+++++++++++++++++++++++++++++++++++++++++++
  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)
Set 4/24 programming mode...(OK)
Entering ICSP...
PIC ID: 0X447 (24FJ64GA002) REV: 0X3042 (1.2)
Erasing the PIC (please wait)...Read: C04F
Read: C04F
Read: C04F
Read: 404F
(OK)
Exit ICSP...
Entering ICSP...
Exit ICSP...
Read PIC test...
Entering ICSP...
FF FF FF FF FF FF FF FF FF FF
Exit ICSP...

Firmware updated successfully :)!
Done!

E:Workdp-svntrunkPiratePICprog>pause
Press any key to continue . . .
Got a question? Please ask in the forum for the fastest answers.

Re: PiratePICprog console application

Reply #27
You could reuse the code pretty much. They abstracted the underlying command (and I guess you do the same) and requires only to search and replace (wel almost!). It would be nice (I can live with recompiling though) if there was a 'scripting' way to simply add a new processor(family) by editting a settingsfile.

I found btw the application note I was talking about: http://www.microchip.com/stellent/idcpl ... 2156  it is a general document which also describes a bit about the devid (for autodetecting the pic) It only describes pic12-16 and pic18.

Re: PiratePICprog console application

Reply #28
An now write appears to work :) I've got to stop now because there's no need to reinvent the wheel. Next thing is to decide how to integrate this project with code from open programmer and maybe USBPICprog.

Code: [Select]
+++++++++++++++++++++++++++++++++++++++++++
  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)
Set 4/24 programming mode...(OK)
Entering ICSP...
PIC ID: 0X447 (24FJ64GA002) REV: 0X3042 (1.2)
Erasing the PIC (please wait)...(OK)
Exit ICSP...
Entering ICSP...
Programming first page with 0x00...
Exit ICSP...
Read PIC test...
Entering ICSP...
00 00 00 00 00 00 00 00 00 00
Exit ICSP...

Firmware updated successfully :)!
Done!

E:Workdp-svntrunkPiratePICprog>pause
Press any key to continue . . .
Got a question? Please ask in the forum for the fastest answers.

Re: PiratePICprog console application

Reply #29
Hey guys,

I have checked into SVN preliminary version of the Pirate pic prog. It should be missing only the highest level part - user interface. I will try to finish it this week! (I am bit busier than I expected to be (-: ). The current code compiles well under GCC 4, it should also compile under MinGW (will try when feature complete).

Various pic-s and families are added easily just by filling another "row" into table.  Similar another interfaces (like future Busblaster) are added easily just by implementing few functions.

Feel free to dig in, all comments are welcome :)