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

Re: PiratePICprog console application

Reply #60
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 ;)

Re: PiratePICprog console application

Reply #61
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).
Got a question? Please ask in the forum for the fastest answers.

Re: PiratePICprog console application

Reply #62
segfaults are cute :$ :P

sure you are passing an iface struct?

Re: PiratePICprog console application

Reply #63
I got it, it needed p not opts as the first argument.
Got a question? Please ask in the forum for the fastest answers.

Re: PiratePICprog console application

Reply #64
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

Or the 24F write routine in pic24f.c
http://code.google.com/p/dangerous-prot ... ic24.c#119
Got a question? Please ask in the forum for the fastest answers.

Re: PiratePICprog console application

Reply #65
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.
Got a question? Please ask in the forum for the fastest answers.

Re: PiratePICprog console application

Reply #66
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...
Got a question? Please ask in the forum for the fastest answers.

Re: PiratePICprog console application

Reply #67
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 :)

Re: PiratePICprog console application

Reply #68
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
Got a question? Please ask in the forum for the fastest answers.

Re: PiratePICprog console application

Reply #69
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?

Re: PiratePICprog console application

Reply #70
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.
Got a question? Please ask in the forum for the fastest answers.

Re: PiratePICprog console application

Reply #71
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?

Re: PiratePICprog console application

Reply #72
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.
Got a question? Please ask in the forum for the fastest answers.

Re: PiratePICprog console application

Reply #73
[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.

 

Re: PiratePICprog console application

Reply #74
[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.