Dangerous Prototypes

Dangerous Prototypes => Bus Pirate Support => Pirate PIC programmer => Topic started by: ian on June 17, 2010, 11:41:03 am

Title: PiratePICprog console application
Post by: ian on June 17, 2010, 11:41:03 am
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/ ... te-loader/ (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-prot ... atePICprog (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/#svn/trunk/PiratePICprog)
Title: Re: PiratePICprog console application
Post by: ian on June 17, 2010, 04:56:26 pm
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:Workdp-svntrunkPiratePICprog>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:Workdp-svntrunkPiratePICprog>

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.
Title: Re: PiratePICprog console application
Post by: ian on June 17, 2010, 05:01:41 pm
Sorry, attachments.
Title: Re: PiratePICprog console application
Post by: ian on June 17, 2010, 06:05:51 pm
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:Workdp-svntrunkPiratePICprog>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:Workdp-svntrunkPiratePICprog>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-prot ... atePICprog (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/#svn/trunk/PiratePICprog)

Edit: latest SVN direct download...
http://dangerous-prototypes-open-hardwa ... ICprog.exe (http://dangerous-prototypes-open-hardware.googlecode.com/svn/trunk/PiratePICprog/piratePICprog.exe)
Title: Re: PiratePICprog console application
Post by: ian on June 18, 2010, 11:55:49 am
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)
[s:]*Fix addressing issue that writes to wrong address in PIC flash[/s:]
*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
[s:]*Add read??[/s:]
*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:Workdp-svntrunkPiratePICprog>gcc piratePICprog.c -o piratePICprog.exe

E:Workdp-svntrunkPiratePICprog>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)?
Title: Re: PiratePICprog console application
Post by: liyin on June 18, 2010, 03:40:50 pm
What's the relationship between the PiratePICprog and the PIC programmer adapter?
Title: Re: PiratePICprog console application
Post by: ian on June 18, 2010, 03:56:51 pm
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.
Title: Re: PiratePICprog console application
Post by: liyin on June 18, 2010, 04:38:16 pm
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?
Title: Re: PiratePICprog console application
Post by: ian on June 18, 2010, 05:17:31 pm
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.
Title: Re: PiratePICprog console application
Post by: Sjaak on June 19, 2010, 08:53:59 am
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.
Title: Re: PiratePICprog console application
Post by: ian on June 19, 2010, 12:13:00 pm
I updated the rawwire documentation with the new PIC read/write commands:
http://dangerousprototypes.com/2009/10/ ... wire-mode/ (http://dangerousprototypes.com/2009/10/27/binary-raw-wire-mode/)
Title: Re: PiratePICprog console application
Post by: ian on June 19, 2010, 03:58:15 pm
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.
Title: Re: PiratePICprog console application
Post by: ian on June 19, 2010, 04:21:00 pm
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:Workdp-svntrunkPiratePICprog>pause
Press any key to continue . . .
Title: Re: PiratePICprog console application
Post by: ian on June 19, 2010, 04:50:24 pm
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.
Title: Re: PiratePICprog console application
Post by: rsdio on June 20, 2010, 02:13:31 am
[quote author="ian"]
EEPROM: does this chip have EEPROM (no)
EEPROM amount: how much eeprom (0)
[/quote]
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.
Title: Re: PiratePICprog console application
Post by: Sjaak on June 20, 2010, 09:16:44 am
[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.
Title: Re: PiratePICprog console application
Post by: ian on June 20, 2010, 09:39:25 am
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 (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.
Title: Re: PiratePICprog console application
Post by: Sjaak on June 20, 2010, 10:09:02 am
[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 (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 (http://code.google.com/p/the-bus-pirate/source/browse/trunk/source/USBPICPROG/prog.c)
Title: Re: PiratePICprog console application
Post by: ian on June 20, 2010, 10:43:43 am
Quote
Why invent the wheel again? You could reuse this code: http://code.google.com/p/the-bus-pirate ... ROG/prog.c (http://code.google.com/p/the-bus-pirate/source/browse/trunk/source/USBPICPROG/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 :)
Title: Re: PiratePICprog console application
Post by: ian on June 20, 2010, 10:45:55 am
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?
Title: Re: PiratePICprog console application
Post by: Sjaak on June 20, 2010, 11:30:02 am
[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 ;)
Title: Re: PiratePICprog console application
Post by: ian on June 21, 2010, 12:45:43 pm
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.
Title: Re: PiratePICprog console application
Post by: rsdio on June 21, 2010, 01:03:10 pm
[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...
Title: Re: PiratePICprog console application
Post by: Sjaak on June 21, 2010, 01:19:18 pm
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...
Title: Re: PiratePICprog console application
Post by: ian on June 21, 2010, 03:01:17 pm
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 . . .
Title: Re: PiratePICprog console application
Post by: ian on June 21, 2010, 04:31:20 pm
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 . . .
Title: Re: PiratePICprog console application
Post by: ian on June 21, 2010, 06:07:44 pm
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 . . .
Title: Re: PiratePICprog console application
Post by: Sjaak on June 21, 2010, 06:33:44 pm
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  (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en012156 ) it is a general document which also describes a bit about the devid (for autodetecting the pic) It only describes pic12-16 and pic18.
Title: Re: PiratePICprog console application
Post by: ian on June 21, 2010, 06:38:53 pm
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 . . .
Title: Re: PiratePICprog console application
Post by: robots on July 06, 2010, 08:39:30 pm
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 :)
Title: Re: PiratePICprog console application
Post by: ian on July 07, 2010, 08:36:16 am
Thanks robots - I've been studying the code every time you make a commit. The interface abstraction is nice and easy to understand, the whole app is really straight forward and well written. I think we'll be able to expand it to support a few different programmer types. You did way more work than I expected, I had just hoped you would tell us how you think it should be built and I would do it :) I'm going to check out the new code now.
Title: Re: PiratePICprog console application
Post by: robots on July 08, 2010, 04:12:57 pm
Don't worry ;) You still need to implement those various programming protocols.
Title: Re: PiratePICprog console application
Post by: ian on July 08, 2010, 07:27:56 pm
I'm excited :) the SURE programming adapter for all the testing just arrived a few minutes ago:
http://dangerousprototypes.com/2010/06/ ... ng-adapter (http://dangerousprototypes.com/2010/06/24/universal-pic-programming-adapter)
Title: Re: PiratePICprog console application
Post by: Sjaak on July 08, 2010, 07:35:25 pm
how does it look and feel? I didn't bought one because the order was getting too expensive

My stuff from sure arived around a week ago, but it was packaged very well. (that could explain the shippingcosts ;)
Title: Re: PiratePICprog console application
Post by: liyin on July 09, 2010, 12:30:32 am
I'm awaiting one for my PICkit 2.   :)
Title: Re: PiratePICprog console application
Post by: ian on July 09, 2010, 08:22:51 am
It's pretty tough. Two thick pieces of acrylic as a top and bottom plate, an idea I might use for a future Bus Pirate case. Decent ZIF sockets (for $10...). The only thing is I can't really operate the levers from the cut-outs provided. I'll post it up today.
Title: Re: PiratePICprog console application
Post by: robots on July 10, 2010, 10:11:12 pm
Sooo, I have checked in some version of the piratepicprog. I think it contains all of the basic functionality, BUT it has not been tested (not even once). I'm really sorry :( I am leaving for vacation in few hours and I didn't get any more time to spend on this project. I don't even know if there is internet connection, so please don't yell at me ;).

Included is also Makefile.win that should work with mingw (probably needs "-lkernel32" in LIBS variable). I have compiled the project successfully with mingw-gcc 4.5.0, some linking problem due to my sloppy installation and broken paths.

Command line parsing is done using getopt. This way is much cleaner than pump-loader used and easily extended when new parameters are to be implemented. Some sanity checks are missing (combination of correct parameters), but should really be just matter of one "IF".

The whole application should be really easy to understand. All the technical problem have been dealt with and other additions should be done according to the "template". Some warning: Data buffer passed to write/read function is void* and PICxx implementations choose what the size of the element in the array is. This can cause some problems on different endian systems. (The same is for the ICSP key - it should be stored as array of bytes instead of one 4byte value). I see this as a small improvement, and I was aiming for some working application, instead of polishing details on trash.
Title: Re: PiratePICprog console application
Post by: Sjaak on July 10, 2010, 10:18:44 pm
Have a nice vacation!!
Title: Re: PiratePICprog console application
Post by: robots on July 10, 2010, 10:29:47 pm
Thanks a lot!   I was hoping for some more on topic reply ;)
Title: Re: PiratePICprog console application
Post by: Sjaak on July 10, 2010, 10:55:28 pm
Sorry man... It is here too hot to be serious ;)

But you did a good job :)
Title: Re: PiratePICprog console application
Post by: rhyde on July 11, 2010, 02:18:46 am
I went to look at this, figure I would try it out on my MAC, but I got lost trying to find the current sources.  Any pointers of which repository and tree would be appreciated.
Title: Re: PiratePICprog console application
Post by: ian on July 11, 2010, 09:24:17 am
@rhyde - I believe this is the current source: http://code.google.com/p/dangerous-prot ... /framework (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/#svn/trunk/PiratePICprog/framework)

Thanks robots, you did a fantastic job. Have a great trip. I'll clear the remaining things you mention.

I just got the updated, stackable PIC programming adapter PCBs from the post office. That, along with the SURE PIC programming boards, means this week will be full of debugging fun :) I'll start posting progress updates in this thread on Monday.
Title: Re: PiratePICprog console application
Post by: ian on July 12, 2010, 05:29:09 pm
I spent the day working with robots' new framework. I got it compiling and communicating with the bus pirate on windows with MinGW.

I made some modifications to get it working on my system. These could be the same sloppy paths that robots mentioned for his compile.
*Added windows.h for Sleep()
*Used old windows serial read (unix version didn't read according to portmon)
*Made the BBIO entry a little more robust. In practice it doesn't matter, but during development it's helpful to be able to enter correctly after a single 0x00 command. The old function would be fine if I know how to flush the serial buffer.

My goal has been to test erase and then add a general 'id the chip' function. So far it enters BBIO and sets up fine.

There is a problem with a pointer (I think) that causes a segfault. It happens the first time the iface struct is used here in pic18.c:

Code: [Select]
static void PIC18_settblptr(struct picprog_t *p, uint32_t tblptr)
{
struct iface_t *iface = p->iface;
void *opts = p->iface_data;

// set TBLPTR
iface->PIC416Write(opts, 0x00, 0x0E00 | ((tblptr >> 16) & 0xff));
printf("n here!!! n");
iface->PIC416Write(opts, 0x00, 0x6EF8);
iface->PIC416Write(opts, 0x00, 0x0E00 | ((tblptr >> 8) & 0xff));
iface->PIC416Write(opts, 0x00, 0x6EF7);
iface->PIC416Write(opts, 0x00, 0x0E00 | ((tblptr) & 0xff));
iface->PIC416Write(opts, 0x00, 0x6EF6);
}

The printf (here) is never reached.

To get a closer look I've installed the codeblocks IDE and debugger. Codeblocks doesn't seem to recognize that this is a .c project and not c++, so I had to change the g++ executable to gcc...

That's where I'm at now. I've traced through and found the fault, now I've got to get familiar enough with the structs to see what's going on. Thought I'd post an update in case the problem is readily apparent to anyone else.

My code is checked in here:
http://code.google.com/p/dangerous-prot ... /framework (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/#svn/trunk/PiratePICprog/framework)
Title: Re: PiratePICprog console application
Post by: ian on July 12, 2010, 06:46:15 pm
Code: [Select]
	picprog.iface = Iface_GetByName(param_prog);
picprog.chip_idx = PIC_GetChipIdx(param_chip);


picops = PIC_GetProtoOps(picprog.chip_idx);
picchip = PIC_GetChip(picprog.chip_idx);
picfamily = PIC_GetFamily(picchip->family);

if (cmd & CMD_ERASE) {
picops->Erase(&picprog);
}


//erase 18F, sleep delay should be adjustable
uint32_t PIC18_Erase(struct picprog_t *p) {
struct pic_chip_t *pic = PIC_GetChip(p->chip_idx);
struct pic_family_t *f = PIC_GetFamily(pic->family);
struct iface_t *iface = p->iface;
void *opts = p->iface_data;

//error starts here
PIC18_settblptr(p, 0x3C0005); //set pinter to erase register
printf("n here!!! n");
iface->PIC416Write(opts, 0x0C, f->erase_key[0]);//write special erase token
PIC18_settblptr(p, 0x3C0004); //set pointer to second erase register
iface->PIC416Write(opts, 0x0C, f->erase_key[1]);//write erase command
iface->PIC416Write(opts, 0, 0);
iface->PIC416Write(opts, 0, 0);
usleep(1000 * f->erase_delay);

return 0;
}

static void PIC18_settblptr(struct picprog_t *p, uint32_t tblptr)
{
struct iface_t *iface = p->iface;
void *opts = p->iface_data;

// set TBLPTR
iface->PIC416Write(opts, 0x00, 0x0E00 | ((tblptr >> 16) & 0xff));
printf("n here!!! n");
iface->PIC416Write(opts, 0x00, 0x6EF8);
iface->PIC416Write(opts, 0x00, 0x0E00 | ((tblptr >> 8) & 0xff));
iface->PIC416Write(opts, 0x00, 0x6EF7);
iface->PIC416Write(opts, 0x00, 0x0E00 | ((tblptr) & 0xff));
iface->PIC416Write(opts, 0x00, 0x6EF6);
}

uint32_t BP_PIC416Write(void *pBP, uint8_t cmd, uint16_t data) {
int fd = ((struct BP_t *)pBP)->fd;
enum BP_picmode_t mode = ((struct BP_t*)pBP)->picmode;
uint8_t buffer[4] = {0};
int res = -1;

if (mode != BP_PIC416)
BP_SetPicMode(fd, BP_PIC416);

buffer[0] = 'xA4';
buffer[1] = cmd;
buffer[2] = (uint8_t)(data);
buffer[3] = data >> 8;

serial_write(fd, buffer, 4);
res = serial_read(fd, buffer, 1);
if (buffer[0] != 'x01') {
puts("ERROR");
return -1;
}
return 0;
}


Complete chain.
Title: Re: PiratePICprog console application
Post by: ian on July 12, 2010, 08:10:14 pm
I don't think I'll get it today.

Code: [Select]
	printf("Initializing interface n");
picprog.iface->Init(&picprog, param_port, param_speed);

picprog.chip_idx = PIC_GetChipIdx(param_chip);
if (picprog.chip_idx == -1) {
printf("Unknown chip '%s' !n", param_chip);
return -1;
}
printf("Found chip ! index = %dn", picprog.chip_idx);

picops = PIC_GetProtoOps(picprog.chip_idx);
picchip = PIC_GetChip(picprog.chip_idx);
picfamily = PIC_GetFamily(picchip->family);

    picprog.iface->MCLRLow(&picprog); //new line to trigger segfault

buf_read = (uint8_t*)malloc(picchip->flash);

Made this change to main.c and can trigger the segfault from main.c now. The hint is that Init works above, so I think it's a problem with the serial port that's dealt with at in MCLRLow and not Init:

Code: [Select]
uint32_t BP_MCLRLow(void *pBP) {
int fd = ((struct BP_t *)pBP)->fd;
return BP_WriteToPirate(fd, "x04");
}

Anything that does int fd = ((struct BP_t *)pBP)->fd; in buspirate.c crashes.
Title: Re: PiratePICprog console application
Post by: ian on July 14, 2010, 10:32:50 am
The segfault is happening because the reference is getting messed up by this line:
((struct BP_t *)pBP)->fd = fd;

It's in buspirate.c BP_Init about like 116:

I'm assuming it destroys the whole iface struct. After this line accessing any iface part of picprog causes segfault. As part of my debugging the moved the serial port to a global variable, but this is a super messy change and I'd rather figure out that's going on here and fix it.
Title: Re: PiratePICprog console application
Post by: ian on July 14, 2010, 10:35:44 am
Here's the line:
http://code.google.com/p/dangerous-prot ... rate.c#109 (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/trunk/PiratePICprog/framework/buspirate.c#109)
Title: Re: PiratePICprog console application
Post by: ian on July 14, 2010, 02:27:32 pm
The problem was actually quite simple. The main.c was passing a picprog_t struct, and the bpinit was treading it as a bp_t struct.

I created a global bp_t struct in buspirate.c and add a reference to it in the picprog_t struct now. Once I figure out the exact pointer stuff it should work (fingers crossed).
Title: Re: PiratePICprog console application
Post by: ian on July 14, 2010, 06:20:26 pm
I got this going, erasing and reading ID. I'm trying to move my changes into the various libraries. I'll probably have a working version tomorrow. My codeblocks project is checked in under robots framework folder.
Title: Re: PiratePICprog console application
Post by: Sjaak on July 14, 2010, 07:42:41 pm
Great job! So it is now just a matter of converting the picprog into your application?

When is the ETA of the HVP adapter? It would be an pitty to have the app ready and the hw not ;)
Title: Re: PiratePICprog console application
Post by: ian on July 15, 2010, 07:45:02 am
I'm going to rotor (http://rotor.ws (http://rotor.ws)) to get the female 2x5 today when I get a broodje beenham for lunch. I hope to have programmed the USB IR Toy by the end of the day (might be too ambitious).
Title: Re: PiratePICprog console application
Post by: Sjaak on July 15, 2010, 09:15:13 am
Eat slowly and you might make it ;)

But when does seeed sell it? ;)
Title: Re: PiratePICprog console application
Post by: ian on July 15, 2010, 12:19:57 pm
It's writing now :) Time to get lunch and some parts. Next I'll work on read, then try a console app instead of running it under debug. Getting exciting.
Title: Re: PiratePICprog console application
Post by: Sjaak on July 15, 2010, 12:29:51 pm
Eet ze! ;)
Title: Re: PiratePICprog console application
Post by: ian on July 15, 2010, 12:37:23 pm
Ok ok, but one last test. It's reading/verifying now :) Time to clean it up and make a release.
Title: Re: PiratePICprog console application
Post by: ian on July 15, 2010, 04:17:33 pm
I've got the code mostly working now, but it only works under debug, the compiled version just exits.
Title: Re: PiratePICprog console application
Post by: ian on July 17, 2010, 09:02:27 pm
Here's an initial version of the app. It's not final, but it programs the OLS bootloader really fast :) Will be updating the read/write PIC routines soon to maximize speed.
Title: Re: PiratePICprog console application
Post by: robots on July 23, 2010, 05:43:51 pm
I have just returned back and I am really happy you got it going !!!

I should fix/change the Iface init function to return pointer to correct BP_t (xxx_t struct), this would hide the interface completely from higher level. This would also lead to adding "finish" function, that would clean up the interface stuff (and return BP to normal mode).
Title: Re: PiratePICprog console application
Post by: ian on July 23, 2010, 09:27:38 pm
It's working well now. I am away this week, but I plan to get it going with the high voltage adapter next week. It takes a long time to write or read with the current protocol, so I'll probably update it for bulk reads and writes that are stored in a buffer in the PIC for maximum speed.
Title: Re: PiratePICprog console application
Post by: ian on July 28, 2010, 06:38:29 pm
I added new bulk read and write command and a buffer layer to the bus pirate interface. It's not very pretty yet, that will come later. Currently limited to the 18F. It erases, programs, and verifies a 18F24J50 in 19.2seconds. That's a huge improvement over the previous method that took minutes. I'll try to get the 24F going tomorrow and make a release when the v5.4 firmware is out.
Title: Re: PiratePICprog console application
Post by: Sjaak on July 28, 2010, 06:52:36 pm
And on to the lowerend pics. Looking forward to see the hvp (in action ;)


BTW now your post in the 5.4 topic make sense ;)
Title: Re: PiratePICprog console application
Post by: ian on July 29, 2010, 10:07:38 am
I'm working on the 24F part today. The Bus Pirate bulk transfer part is done, as is the underlying buffer support in the console app. I've got a segfault to tracking down though :)

In PIC24.c

Code: [Select]
	iface->PIC424Write(opts, 0x200000 | ((addr & 0xffff0000) >> 12), 0, 0);//SIX,0x200FF0,5, N/A MOV #<SourceAddress23:16>, W0

Causes a segfault. Variables look to be passed and handled the same (same as pic18.c at least).
Title: Re: PiratePICprog console application
Post by: Sjaak on July 29, 2010, 10:15:01 am
segfaults are cute :$ :P

sure you are passing an iface struct?
Title: Re: PiratePICprog console application
Post by: ian on July 29, 2010, 10:21:14 am
I got it, it needed p not opts as the first argument.
Title: Re: PiratePICprog console application
Post by: ian on July 29, 2010, 04:12:55 pm
I worked on the 24FJ support today. It IDs and erases the PIC. It writes to some extent (first page works fine), but there's a problem with the address tracking and calculation. Pages are being overwritten and cut short. I can't see why, but I get really confused by all the different metrics, better to start fresh tomorrow.

The problem is in the 24F setup in pic.c
http://code.google.com/p/dangerous-prot ... g/pic.c#29 (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/trunk/PiratePICprog/pic.c#29)

Or the 24F write routine in pic24f.c
http://code.google.com/p/dangerous-prot ... ic24.c#119 (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/trunk/PiratePICprog/pic24.c#119)
Title: Re: PiratePICprog console application
Post by: ian on July 29, 2010, 05:00:29 pm
Got it, the address pointer is by words = bytes*2, so the raw HEX byte count need to be /2 for the word location. I think there is still a problem calculating the end range, and it doesn't ignore any blank chunks, still need to work on that.
Title: Re: PiratePICprog console application
Post by: ian on July 29, 2010, 05:16:00 pm
First 100% successful program. Read might need some tweeking.

The problem with ignoring blank sectors is that the PIC uses 3 bytes of every 4 in the hex files, and the last unused byte is 00 instead of FF. I'm not sure how to handle this, maybe every PIC needs a parser too...
Title: Re: PiratePICprog console application
Post by: Sjaak on July 29, 2010, 05:36:40 pm
Pic24 and the largers pic pad the programword to 32 bits, the lower end pics pad the programwords to 16. I'm not sure about the midrange family of pics.

So you need two (or three) parsers :)
Title: Re: PiratePICprog console application
Post by: ian on July 29, 2010, 05:50:54 pm
Yup, I think that is the way to go. For now I used this ugly hack that checks the protocol and skips every fourth byte. It's not great, but I got to test it, and it programmed the bootloader into another Bus Pirate perfectly in just a 2-3 seconds. Read is still painfully slow because there's no good way to do it in bulk without implementing PIC programming commands into the Bus Pirate (I have an idea though :) ).
http://code.google.com/p/dangerous-prot ... /pic.c#158 (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/trunk/PiratePICprog/pic.c#158)
Title: Re: PiratePICprog console application
Post by: Sjaak on July 29, 2010, 06:12:39 pm
I would say stuff it into a 32bit unsigned int  (for pic24+) and use the bits you need. Otherwise use a 16 bit unsigned int ;)

Can't you send a reading stub that reads the whole memory and send the bytes over a 2wire interface?
Title: Re: PiratePICprog console application
Post by: ian on July 30, 2010, 09:12:43 am
I was working on that approach right at the end of the day. Something wasn't working, I'll try it again today.

Want to avoid 32bit ints because as I recall there is an endian problem on some systems that make byte arrays a better choice. I'm not an expert on that, I just remember something from pump-loader and something robots mentioned.
Title: Re: PiratePICprog console application
Post by: Sjaak on July 30, 2010, 09:35:56 am
I think as long as you treat it everywhere as an u32 it isn't a problem. When you access the same location as u8[4] the endianess problem can pop up.

How is reading implemented in Picprog?
Title: Re: PiratePICprog console application
Post by: ian on July 30, 2010, 10:25:33 am
picprog sends arrays of commands to the programmer all at once, then they are processed and a done code is returned.

piratepicprog is different because we try to keep everything as operation oriented as possible (PIC read/PIC write), that way we can add new interfaces for different programmers in the future.

For the 4/24 bulk read I used a five byte packet, The first byte is read command, the second is the number of words to read, the last three bytes are the ASM command to execute prior to each read. This allows us to use a different command with each PIC, if needed, or a NOP if no command is needed. The latest version is a massive improvement, it reads the whole chip in seconds rather than minutes. The verify problem remains: the data is read out as 3bytes per word arranged in the PIC internal format, which is compared to the HEX with 4bytes per word formatted properly for HEX, so the verification fails.
Title: Re: PiratePICprog console application
Post by: rsdio on July 30, 2010, 07:55:21 pm
[quote author="Sjaak"]
I think as long as you treat it everywhere as an u32 it isn't a problem. When you access the same location as u8[4] the endianess problem can pop up.[/quote]Another problem is copying USB data, which is 8-bit, to internal data, which may be 32-bit.  Not only must you always treat the internal 32-bit array as u32, but you must always treat the 8-bit USB data as u8.  i.e. You can't "optimize" by treating the USB data as u8[4], because you then get into endian problems.

If you always read the USB data in bytes, and then use shifting operations to build 32-bit words for your internal array, then you should be safe from endian issues.

P.S. Officially, USB is a little-endian bus, but that does not guarantee that the sender will always put little-endian data into the packets.
Title: Re: PiratePICprog console application
Post by: Sjaak on July 30, 2010, 08:24:12 pm
[quote author="rsdio"]
[quote author="Sjaak"]
I think as long as you treat it everywhere as an u32 it isn't a problem. When you access the same location as u8[4] the endianess problem can pop up.[/quote]Another problem is copying USB data, which is 8-bit, to internal data, which may be 32-bit.  Not only must you always treat the internal 32-bit array as u32, but you must always treat the 8-bit USB data as u8.  i.e. You can't "optimize" by treating the USB data as u8[4], because you then get into endian problems.

If you always read the USB data in bytes, and then use shifting operations to build 32-bit words for your internal array, then you should be safe from endian issues.

P.S. Officially, USB is a little-endian bus, but that does not guarantee that the sender will always put little-endian data into the packets.
[/quote]

I was indeed talking about the internals. and sorta hoped that the FTDI serial emulation takes care of sending the bytes in the right order.

It is however a concern for the USB stack we are planning. Thanks for pointing it out.