Reading, writing, erasing flash (16F88)

[Ioannis]

This thread put me in some thoughts about updating the firmware from a remote station.

Is it possible to replace the existing firmware of a PIC with new one?

And souldn't there be some kind of bootloader for this purpose?

Ioannis

[rmteo]

http://www.etc.ugal.ro/cchiculita/so...bootloader.htm

[Ioannis]

The problem with this boot loader is that your code is not protected and anyone can copy it.

With Writecode commands, things might be different.

Ioannis

[Charles Linquis]

I mentioned it some time back, but I modified a bootloader (MCLoader) such that it was protected.

During startup, the code initially jumps to the start of the bootloader, checks for a special character coming in over the USART, and if it doesn't find it, jumps to a location just below the bootloader where the start vector is stored (it was relocated there by the bootloader routine).

All these vectors are easy to change within the program.

In other words, you can have a password-protected query within your PIC program as to whether the bootloader should be allowed or not. If you say
"YES", then the run-time code patches the program bootloader to run in the normal fashion.
When the program boots up in the normal way, it checks to see if the bootloader is in the "normal" mode. If it is, then it patches the bootloader to jump immediately to the program start vector (thereby disabling the bootloader).

So, the bootloader is normally disabled, and the only way you can get it to work is to tell your program that you want to use the bootloader ON THE NEXT RESET (only) . Your code then patches the bootloader, and invokes @ RESET, The PIC resets and the bootloader runs. Your program loads and when it starts one of the first things it does is check the status of the bootloader (by reading key FLASH locations), and patching them if necessary so that the bootloader won't run again.

I don't know if this was clear, but again, this has been tested to work on an 18F872x family using MCLoader.

If

[Ioannis]

Hi Charles.

You describe an advanced bootloader that is OK for the most situation, when you are near to the PIC device.

What I really want to investigate if it is doable: To update firmaware where physical contact to the PIC, its reset button or anything else is not an option.

Say that you have built and installed a controller in another town and one day you need to change something in the program. You have DSL connection and a RS232/RS485 to a PC/modem/router.

If you can reach through the Internet the PIC, maybe it is possible to update it too.

Ioannis

[rmteo]

There is a lot that can be done when the PIC has the capability to write to its program memory. I would select something more capable/sophisticated than a PIC16 though.

[Charles Linquis]

Yes, it is doable. But your bootloader must set up whatever communication method you are using. For example, if you are trying to do this over the internet, the bootloader has to set up the net connection, then wait for a message from the host (hopefully encrypted) before invoking itself.

A bootloader generally has only a very short timeout window when it will accept an outside command to invoke itself (otherwise it would negatively impact the start time of the PIC). Since most bootloaders are set up for RS-232 operation, a very short time (1 second or less) is OK. If you are trying to do a load over the net, you have to deal with a lot more latencies and this time must be extended.

But more of a problem is the possibility of dropped connections. RS-232 is very reliable, but if you are "net-loading" and are halfway through the bootload process and your connection gets broken, are you absolutely certain that you can get it (remotely) restarted? Probably not easy to guarantee when the unit is in China!

There are a couple of ways around this. If you have a big PIC and your code is small and is relocatable (probably not easy with PBP), then your code can reside in the lower half of the device's FLASH space. Your special code-loader could accept the new program and place it in the upper half of FLASH. After loading the new code, your "old" code would then run a CRC on the new code. If it passed, you would then move your start jump vector to point to the beginning of the new code (in the upper half of FLASH) and run. The next time you run the bootloader, it puts the new code in the lower half of FLASH and moves the jump vector again.

With PBP, it is probably easier to do this in a slightly different way; with an external EEPROM. Your bootloader would load the new code into the external device, then run a CRC on it and then copy the code from the EEPROM to the PIC. Doing this shouldn't be too hard.

Please understand that I have not done this myself, I have only pondered how it might be done.

[Ioannis]

Hi Charles.

Thanks for the reply.

The idea of external EEPROM is nice. Probably must be a fast one, like the RAMTRON FM24C64. Theres is no 10ms delay.

I am very interested in this, and soon I may have some results to post. My main concern is how to lock the code after updating the old firmware.

Ioannis