Pic to Pic Firmware upgrade

[rjones2102]

Hi all,

Has anyone know if it is possible to write a program in PBP that will read firmware from a serial interface and then program another Pic with the firmware?

Ultimately I want to upgrade firmware wirelessly (RF and GPRS modem) so Pic to Pic will get me moving in the right direction.

If it looks too hard, how do people who use Pics do downloadable firmware upgrades? It might give me a starting point to think laterally for a solution.

Thanks

Rich

[mister_e]

Bootloader should work. But this may require a two-way communication.

[BobP]

Hi,

Have used several telecommunication products that upgraded it's firmware by radio. It’s not as straightforward as it seems.

It should not be too difficult to transmit the firmware to the receiving GSM as internal error correction should keep errors to a minimum. But a RF link to the reciving PIC may give problems? The bigger the firmware the harder it will be. External memory will most likely be required. The biggest problem is getting an accurate copy of the firmware over to the receiving PIC. One company sends the firmware twice and compared it for errors. The firmware must be stored and checked before loading into the PIC's own memory. Remember any corruption of the transmitted firmware when loaded and run could ‘lock’ the receiving PIC. Necessitating a visit to do a hardwire re-programming.

One system I had to use solved all these problems but forgot to allow for the phone connection 'dropping' in mid transfer. The result was a trip on site and reseting and reloading software.

As has been said previously a modified version of a bootloader followed by a reset should do the job.

Bob

[rjones2102]

Thanks guys,

OK, I already figured some external memory might be necessary to fit the code into prior to the actual reprogramming of remote Pic.

The GPRS modem will have a TCP/IP stack so the file will be FTPed across air. So, that will deal with the data integrity of the firmware that reaches the actual hardwired network.

When sending to the ultimate destination transmitting it twice and doing a compare sounds a good idea. It might end up more than twice but as long as it doesn't loose integrity that will be fine.

Using a bootloader should eliminate the problem of failed firmware upgrade requiring a trip to 'shop' as the code will not be loaded unless it has been received error free providing the bootloader has the smarts.

I guess what I need is bootloader code for a Pic. I am not clever enough (yet!) to write it so has anyone got any starting points for me? I bet someone has written one even if not in the PBP world. Hummm, a wider google search needed I think. I will post anything I find as this thread could be interesting as it develops.

Thanks

Rich

[Ioannis]

Please note that if you are going to use a bootloader, your precious hex code will be free for anyone to copy it! There can not be bootloader AND code protection at the same time!

Ioannis

[Jumper]

It works great with a bootloader and codeprotection together. It is even possible to encrypt the hexfile into jibberish on your PC and later letting the bootloader de-jibberish it while flashing it. This way the code is safe all the way (depending on what encryption used) and if you use a PIC that is safer (i.e 18 series).

With codeprotection you can not read or write with an external programmer but the software inside the PIC (loader) can always erase and write in the codespace.

This can be done PIC to PIC or I2C or serial or what ever kind of way....

/me

[rjones2102]

Hi Jumper,

That was my understanding and plan. To use encrypted hex files and decrypt them at PC.

Do you have any recommendation of the best bootloader or any good information on how to code to talk to them?

Cheers

Rich

[milestag]

Microcode Studio's Bootloader offers a distribution license for about $400 USD and it includes the DLL library if you want to write your own interface and still use their bootloader core. I haven't purchased this yet but been very tempted. I think you could write an app to encrypt/decrypt the hex file then send it to the PIC using the DLLs. Of course the serial data to the PIC is still vulnerable to capture. Also you could distribute a simplified app with the update file already embedded.

I've been forever watching and searching for a secure bootloader. Unfortunately there seems to be no such beast on the market at present. Curious that no one offers this. My own programming skills/knowledge aren't quite up to tackling that yet, but I would certainly be willing to pay a few hundred dollars for a good reliable encrypted bootloader.

[rjones2102]

I found a bootloader the other day that professed to secure the code. It set a code protect flag in Pic. I have just been googling for it and it has gone. Or rather my memory of the search terms used is gone. How annoying.

I guess it comes down to the Pic. Is it possible to stop people reading the code back out. If the Pic doesn't have the capability, then it isn't going to happen. I will keep looking and will post if I find it.

Rich

[Jumper]

Write your own loader in PBP, this link will tell you how. Encrypt the hexfile on the PC-side and let the loader read the data serially or whatever way and at the same time decrypt it and writing the code to the codespace.

This way the hexfile is safe all the way ........ and I trust Microchip's ability to keep the code inside the chip after I have set it to CP. At lest for a reasonable cost and effort :-)


http://www.picbasic.co.uk/forum/showthread.php?t=4498


Maybe it is time to start a real thread with bootloaders in this forum. That link is full with errors and is quite long.... An I2C decryption loader using an external EEprom became 8 kbytes and is working great.

And no, I will not tell you my encryption

/me

[mister_e]

There's still the option to use and understand asm and some some open source ones. As far as i remind TinyBootloader is one of them.

But yeah... if you plan to change the code to add your own encryption, you will also need to change the PC software as well.

[Josuetas]

It will be... a bit complex..

First i used th microchip bootloader, it works nice and gives the Software in Visual Basic to be modified and also the ASM to be modified.

Not an easy task again.... it is always hard to understand other peoples coding, and you will have to do this twice (ASM and Software loader).

The PDF that comes with the bootloader explains as much as it can the transfer protocol.

Recommended to avoid your hex file being copied: Change the bootloader and the software.. change the C libraries included to encrypt your file. Protect the bootloader code space (only in 18F) otherwise someone could just overwrite it with original and then reading everything!!.

Its a hard but nice job to do because you can always use it for your next projects :D

[Jumper]

Code protect the entire PIC not just the boot block. Then no-one can do anything except from inside the loader.

And with a home-made loader, creative codeing and 3 months later I bet it is protected even from the developer. But then, just erase it and start all over again.



/me

[Josuetas]

Off Course!! Protect the whole device!!

I was thinking on protect the boot block from being writen or erased... 18F has special protection for the boot block!

[jason]

My goal here is almost exactly like your all talking about. I'm thinking of having an 8 pin dip socket on my new version of an on going production board. the goal would be to send a client a 15 cent serial eeprom that has updated encrypted firmware code in it. Once power is supplied, the bootloader would decrypt the code in the serial eeprom and program itself. Without the decrypted code from ever seeing daylight and having at least 64bit encryption method It should be next to impossible from using it to make clones. Once programed a green light would come on and the client could power down and take out the ereased serial eeprom and through it away.

Any suggestions would be greatly aprpeciated. Here in this topic you guys have givin me several helpful tips, Thank you.