PIC buring Firmware to another PIC

[mook Jonhon]

I'd like to serially transfer a hex program file to one pic then have
that PIC burn this firmware to another pic.

In this case it would be a PIC18 recieving the FW serially and a PIC16
having this burned to its memory. The PIC16 does support LV
programming.

I'm thinking something like the circuits in the ICD3 but I dont need
debugging. Simply erase, burn and verify functions.


Due to the limited SRAM in teh PIC18 can I burn the FW in cnunks?
Recieve 1K via serial, write 1K, verify, repeat for the next 1K,

When done perform a checksum match over hte address range.


I know this has been done before, can you point me to some resources.

I will look too but many time you guys will point to a better one that
I can find.

thanks

 

[bitrex]

On 9/22/19 9:52 PM, mook Jonhon wrote:

I'd like to serially transfer a hex program file to one pic then have
that PIC burn this firmware to another pic.

In this case it would be a PIC18 recieving the FW serially and a PIC16
having this burned to its memory. The PIC16 does support LV
programming.

I'm thinking something like the circuits in the ICD3 but I dont need
debugging. Simply erase, burn and verify functions.


Due to the limited SRAM in teh PIC18 can I burn the FW in cnunks?
Recieve 1K via serial, write 1K, verify, repeat for the next 1K,

When done perform a checksum match over hte address range.


I know this has been done before, can you point me to some resources.

I will look too but many time you guys will point to a better one that
I can find.

thanks

this is only incidentally related to your Q but if inter-PIC code
transfer is an operation you have to do a lot for some reason, and the
application is not a high-performance one you can run a PIC or AVR
emulator on a PIC or AVR, using its SRAM as an instruction cache for
just regular .bin "compiled" asm files in binary format, loaded from an
SD card or other mass storage (Flash mass storage can be written from
incoming serial port data easily enough.)

the slowdown is about 25-50x depending. That's fine for a lot of
applications if the clock is e.g. 50MHz

 

[bitrex]

On 9/22/19 9:52 PM, mook Jonhon wrote:

I'd like to serially transfer a hex program file to one pic then have
that PIC burn this firmware to another pic.

In this case it would be a PIC18 recieving the FW serially and a PIC16
having this burned to its memory. The PIC16 does support LV
programming.

I'm thinking something like the circuits in the ICD3 but I dont need
debugging. Simply erase, burn and verify functions.


Due to the limited SRAM in teh PIC18 can I burn the FW in cnunks?
Recieve 1K via serial, write 1K, verify, repeat for the next 1K,

When done perform a checksum match over hte address range.


I know this has been done before, can you point me to some resources.

I will look too but many time you guys will point to a better one that
I can find.

thanks

AFAIK on all the Harvard-arch 8-bit models that can self-program Flash
(not all PICs can) they can only execute the instructions that write to
Flash from within the boot-loader section, which can't write itself and
can only be HV programmed (to prevent obvious probs)

I don't recall if on the PIC the program counter can jump into the
bootloader section at times other than power-up, if it can then
basically would have to set a flag byte on the serial that tells it to
do that. The boot-loader section is usually very small like 256 or 512
bytes or something so not much room for much more than writing and
check-summing and returning ack or nack, the transmitter PIC would have
to carry the responsibility of handling re-transmissions or trying to
re-sync in case of problems.

<http://www.etc.ugal.ro/cchiculita/software/picbootloader.htm>

 

[bitrex]

On 9/23/19 12:38 AM, bitrex wrote:

On 9/22/19 9:52 PM, mook Jonhon wrote:

I'd like to serially transfer a hex program file to one pic then have
that PIC burn this firmware to another pic.

In this case it would be a PIC18 recieving the FW serially and a PIC16
having this burned to its memory.  The PIC16 does support LV
programming.

I'm thinking something like the circuits in the ICD3 but I dont need
debugging.   Simply erase, burn and verify functions.


Due to the limited SRAM in teh PIC18 can I burn the FW in cnunks?
Recieve 1K via serial, write 1K, verify, repeat for the next 1K,

When done perform a checksum match over hte address range.


I know this has been done before, can you point me to some resources.

I will look too but many time you guys will point to a better one that
I can find. 

thanks


AFAIK on all the Harvard-arch 8-bit models that can self-program Flash
(not all PICs can) they can only execute the instructions that write to
Flash from within the boot-loader section, which can't write itself and
can only be HV programmed (to prevent obvious probs)

I don't recall if on the PIC the program counter can jump into the
bootloader section at times other than power-up, if it can then
basically would have to set a flag byte on the serial that tells it to
do that. The boot-loader section is usually very small like 256 or 512
bytes or something so not much room for much more than writing and
check-summing and returning ack or nack, the transmitter PIC would have
to carry the responsibility of handling re-transmissions or trying to
re-sync in case of problems.

http://www.etc.ugal.ro/cchiculita/software/picbootloader.htm

but my general feeling on using microcontrollers to flash other
microcontrollers in anything other than in the application of "a
microcontroller programmer for lab/shop use" is - don't

 

[Jan Panteltje]

On a sunny day (Mon, 23 Sep 2019 01:52:02 GMT) it happened "mook Jonhon"
<mook@mook.net> wrote in <6zVhF.315436$597.89983@fx17.iad>:

I'd like to serially transfer a hex program file to one pic then have
that PIC burn this firmware to another pic.

In this case it would be a PIC18 recieving the FW serially and a PIC16
having this burned to its memory. The PIC16 does support LV
programming.

I'm thinking something like the circuits in the ICD3 but I dont need
debugging. Simply erase, burn and verify functions.


Due to the limited SRAM in teh PIC18 can I burn the FW in cnunks?
Recieve 1K via serial, write 1K, verify, repeat for the next 1K,

When done perform a checksum match over hte address range.


I know this has been done before, can you point me to some resources.

I will look too but many time you guys will point to a better one that
I can find.

thanks

I program all my PICs with my own software and a modified version of the very simple NOPP programmer
http://panteltje.com/panteltje/pic/jppp18/

I have a parport PCI card in my modern PC for that,
IMNSHO every PC needs I/O, parport has many pins...


I do not use low voltage programming, simply never needed it.
Programming in chunks? why not,, 18F is fast enough,
but then you have to read it in from the PC via serial port,
or from some SRAM, or from code memory?
Full circle.

 

[mook Jonhon]

Jan Panteltje wrote:

On a sunny day (Mon, 23 Sep 2019 01:52:02 GMT) it happened "mook
Jonhon" <mook@mook.net> wrote in <6zVhF.315436$597.89983@fx17.iad>:

<snip>

I program all my PICs with my own software and a modified version of
the very simple NOPP programmer
http://panteltje.com/panteltje/pic/jppp18/

I have a parport PCI card in my modern PC for that,
IMNSHO every PC needs I/O, parport has many pins...


I do not use low voltage programming, simply never needed it.
Programming in chunks? why not,, 18F is fast enough,
but then you have to read it in from the PC via serial port,
or from some SRAM, or from code memory?
Full circle.

The firmware is somewhere in the 3-4Kbyte range. The PIC18 I can play
with does not have that much free SRAM avaialble. What I would like
to do is send 1K packets to the pic18 from the serial port of a PC.
Have the PIC18 emulate the ICD3 with, low votlage programming mode, and
load a 1K block of FW into the PIC16. I assume there is some verify
process that could take place by reading the address locations back
that were just written. The PIC 18 would check this and only send an
ACK to the PC for the next 1K packet.

when the last packet is sent by the PC and it gets the last ACK, the PC
sends a verify command with checksum inside to check.

One last ACK and you should be golden.


Just looking to see if someone has already done a version of this and
found some "gottchas"

 

[Johann Klammer]

On 09/23/2019 01:54 PM, mook Jonhon wrote:

Jan Panteltje wrote:

On a sunny day (Mon, 23 Sep 2019 01:52:02 GMT) it happened "mook
Jonhon" <mook@mook.net> wrote in <6zVhF.315436$597.89983@fx17.iad>:


snip

I program all my PICs with my own software and a modified version of
the very simple NOPP programmer
http://panteltje.com/panteltje/pic/jppp18/

I have a parport PCI card in my modern PC for that,
IMNSHO every PC needs I/O, parport has many pins...


I do not use low voltage programming, simply never needed it.
Programming in chunks? why not,, 18F is fast enough,
but then you have to read it in from the PC via serial port,
or from some SRAM, or from code memory?
Full circle.


The firmware is somewhere in the 3-4Kbyte range. The PIC18 I can play
with does not have that much free SRAM avaialble. What I would like
to do is send 1K packets to the pic18 from the serial port of a PC.
Have the PIC18 emulate the ICD3 with, low votlage programming mode, and
load a 1K block of FW into the PIC16. I assume there is some verify
process that could take place by reading the address locations back
that were just written. The PIC 18 would check this and only send an
ACK to the PC for the next 1K packet.

when the last packet is sent by the PC and it gets the last ACK, the PC
sends a verify command with checksum inside to check.

One last ACK and you should be golden.


Just looking to see if someone has already done a version of this and
found some "gottchas"

Only tried with some of the newer PIC16. also, just parport.
not cascaded. what I noticed is that the row sizes for
erase/programmig differ a lot(8-32 bytes or somesuch).
The sram of your processor won't be a problem.

You can get away using the minimum row size. might slow things a bit.
or you download the atpack files. There's machine readable xml files
in there which are convenient for extracting those parameters.

Some mcus also need different commands for different operating voltages.
(I haven't played with that yet)

Implementation wise it's usually easier to implement simple
pin hi/pin lo/get pin commands and do the actual business
logic&sequencing on the pc. I believe the protocol is
timing insensitive. It might not be fast enough, depending
on the speed of the uart. Maybe bearable if you only have2 do
it once.

 

[Jan Panteltje]

On a sunny day (Mon, 23 Sep 2019 11:54:31 GMT) it happened "mook Jonhon"
<mook@mook.net> wrote in <Xn2iF.275097$Zz1.55806@fx35.iad>:

The firmware is somewhere in the 3-4Kbyte range. The PIC18 I can play
with does not have that much free SRAM avaialble. What I would like
to do is send 1K packets to the pic18 from the serial port of a PC.
Have the PIC18 emulate the ICD3 with, low votlage programming mode, and
load a 1K block of FW into the PIC16. I assume there is some verify
process that could take place by reading the address locations back
that were just written. The PIC 18 would check this and only send an
ACK to the PC for the next 1K packet.

when the last packet is sent by the PC and it gets the last ACK, the PC
sends a verify command with checksum inside to check.

One last ACK and you should be golden.


Just looking to see if someone has already done a version of this and
found some "gottchas"

I assume you have the Microchip 18F1XK22_FLASH_programming_specs_41357B.pdf.
For low voltage programming (I think I actually tried that too, but long ago),
it has all the data flow diagrams.
But I wonder, why the PIC in-between for programming?
Would it not be possible to use serial port DTR and RTS as output and DCD for example as input?
And do the timing on the PC?
In my jppp18 programming software I added a delay loop as PCs became faster and faster..
Timing is not critical at all, just do not go too fast, it is simply data written / read by a clock pulse.
I guess it depends on the OS too, I run Linux only.

 

[Clive Arthur]

On 23/09/2019 02:52, mook Jonhon wrote:

I'd like to serially transfer a hex program file to one pic then have
that PIC burn this firmware to another pic.

<snip>

I would have the PIC16 self-program from data transferred from the PIC18
in blocks rather than have the PIC18 emulate a programmer.

Cheers
--
Clive

 

[Johann Klammer]

On 09/23/2019 03:37 PM, Johann Klammer wrote:

You can get away using the minimum row size. might slow things a bit.
or you download the atpack files. There's machine readable xml files

<https://packs.download.microchip.com/>

 

[Clive Arthur]

On 23/09/2019 14:23, Jan Panteltje wrote:

<snip>

> But I wonder, why the PIC in-between for programming?

Probably the PICs are in an instrument which may need occasional
firmware upgrades and which is physically very difficult to access
except through a proprietary telemetry port connected to the PIC18.

For example, some oilfield instrumentation can take many hours to get at
through pressure barriers etc (maybe 20kpsi or 140MPa), and if it's
assembled in a drill string or down a hole even more, not to mention the
huge cost involved in stopping a job and delaying production.

But that's just a guess

Cheers
--
Clive

 

[Jan Panteltje]

On a sunny day (Mon, 23 Sep 2019 15:09:12 +0100) it happened Clive Arthur
<cliveta@nowaytoday.co.uk> wrote in <qmajmb$8r5$1@dont-email.me>:

On 23/09/2019 14:23, Jan Panteltje wrote:

snip

But I wonder, why the PIC in-between for programming?

Probably the PICs are in an instrument which may need occasional
firmware upgrades and which is physically very difficult to access
except through a proprietary telemetry port connected to the PIC18.

For example, some oilfield instrumentation can take many hours to get at
through pressure barriers etc (maybe 20kpsi or 140MPa), and if it's
assembled in a drill string or down a hole even more, not to mention the
huge cost involved in stopping a job and delaying production.

But that's just a guess

Cheers

Yes, and in space..
But I would expect to be a bit more complex computer there...
I have done PIC programming (on earth) with a raspberry Pi:
http://panteltje.com/panteltje/raspberry_pi_noppp/
Plenty of I/O and memory, easy to program in C.
Can do other things at the same time.

 

[Clive Arthur]

On 24/09/2019 09:07, Jan Panteltje wrote:

<snip>

> But I would expect to be a bit more complex computer there...

180'C is hard for complex things.

Cheers
--
Clive

 

[Martin Brown]

On 23/09/2019 12:54, mook Jonhon wrote:

Jan Panteltje wrote:

On a sunny day (Mon, 23 Sep 2019 01:52:02 GMT) it happened "mook
Jonhon" <mook@mook.net> wrote in <6zVhF.315436$597.89983@fx17.iad>:


snip

I program all my PICs with my own software and a modified version of
the very simple NOPP programmer
http://panteltje.com/panteltje/pic/jppp18/

I have a parport PCI card in my modern PC for that,
IMNSHO every PC needs I/O, parport has many pins...


I do not use low voltage programming, simply never needed it.
Programming in chunks? why not,, 18F is fast enough,
but then you have to read it in from the PC via serial port,
or from some SRAM, or from code memory?
Full circle.


The firmware is somewhere in the 3-4Kbyte range. The PIC18 I can play
with does not have that much free SRAM avaialble. What I would like
to do is send 1K packets to the pic18 from the serial port of a PC.
Have the PIC18 emulate the ICD3 with, low votlage programming mode, and
load a 1K block of FW into the PIC16. I assume there is some verify
process that could take place by reading the address locations back
that were just written. The PIC 18 would check this and only send an
ACK to the PC for the next 1K packet.

when the last packet is sent by the PC and it gets the last ACK, the PC
sends a verify command with checksum inside to check.

One last ACK and you should be golden.

Wouldn't it be easier to use a slightly more potent intermediate device
like one of the ARM development kits. They are cheap, speak USB have
plenty and can toggle their IO lines in a suitably arbitrary fashion.

Just looking to see if someone has already done a version of this and
found some "gottchas"

Main one is having to squeeze it into a PIC.

--
Regards,
Martin Brown

 

[mook Jonhon]

Clive Arthur wrote:

On 23/09/2019 14:23, Jan Panteltje wrote:

snip

But I wonder, why the PIC in-between for programming?

Probably the PICs are in an instrument which may need occasional
firmware upgrades and which is physically very difficult to access
except through a proprietary telemetry port connected to the PIC18.

For example, some oilfield instrumentation can take many hours to get
at through pressure barriers etc (maybe 20kpsi or 140MPa), and if
it's assembled in a drill string or down a hole even more, not to
mention the huge cost involved in stopping a job and delaying
production.

But that's just a guess

Cheers

Very good guess.

 

[Hul Tytus]

Mook - I put together a similar AVR programmer for AVRs. The input to the
AVR programmer came from the parallel port (8 bits wide) of a pc. The in coming
data filled a buffer of about 512 bytes, if memory serves. The data flow
was goverened by handshaking with two lines. The parallel port outran
the serial avr to avr rate, which was a treat. 32k of flash data is
programmed in a little less than 6 seconds. The key was the interupt driven
input.

Hul

mook Jonhon <mook@mook.net> wrote:

I'd like to serially transfer a hex program file to one pic then have
that PIC burn this firmware to another pic.

In this case it would be a PIC18 recieving the FW serially and a PIC16
having this burned to its memory. The PIC16 does support LV
programming.

I'm thinking something like the circuits in the ICD3 but I dont need
debugging. Simply erase, burn and verify functions.

Due to the limited SRAM in teh PIC18 can I burn the FW in cnunks?
Recieve 1K via serial, write 1K, verify, repeat for the next 1K,

When done perform a checksum match over hte address range.

I know this has been done before, can you point me to some resources.

I will look too but many time you guys will point to a better one that
I can find.

thanks

 

[Hul Tytus]

Mook - the buffer size was 256 bytes not 512 as I'd guessed. Worked
well for the avr. Your application, though, may need more.

Hul

mook Jonhon <mook@mook.net> wrote:

Clive Arthur wrote:

On 23/09/2019 14:23, Jan Panteltje wrote:

snip

But I wonder, why the PIC in-between for programming?

Probably the PICs are in an instrument which may need occasional
firmware upgrades and which is physically very difficult to access
except through a proprietary telemetry port connected to the PIC18.

For example, some oilfield instrumentation can take many hours to get
at through pressure barriers etc (maybe 20kpsi or 140MPa), and if
it's assembled in a drill string or down a hole even more, not to
mention the huge cost involved in stopping a job and delaying
production.

But that's just a guess

Cheers

> Very good guess.