PIC buring Firmware to another PIC

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

Reply to
mook Jonhon
Loading thread data ...

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

Reply to
bitrex

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.

Reply to
bitrex

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

Reply to
bitrex

On a sunny day (Mon, 23 Sep 2019 01:52:02 GMT) it happened "mook Jonhon" wrote in :

I program all my PICs with my own software and a modified version of the very simple NOPP programmer

formatting link

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.

Reply to
Jan Panteltje

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"

Reply to
mook Jonhon

On a sunny day (Mon, 23 Sep 2019 11:54:31 GMT) it happened "mook Jonhon" wrote in :

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.

Reply to
Jan Panteltje

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.

Reply to
Johann Klammer

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
Reply to
Clive Arthur

Reply to
Johann Klammer

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
Reply to
Clive Arthur

On a sunny day (Mon, 23 Sep 2019 15:09:12 +0100) it happened Clive Arthur wrote in :

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:

formatting link
Plenty of I/O and memory, easy to program in C. Can do other things at the same time.

Reply to
Jan Panteltje

180'C is hard for complex things.

Cheers

--
Clive
Reply to
Clive Arthur

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.

Main one is having to squeeze it into a PIC.

--
Regards, 
Martin Brown
Reply to
Martin Brown

Very good guess.

Reply to
mook Jonhon

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 J> I'd like to serially transfer a hex program file to one pic then have

Reply to
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 J> > > >

Reply to
Hul Tytus

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.