Reading, writing, erasing flash (16F88)

[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

[Charles Linquis]

It doesn't have to be fast - as long as you have control of the program at the "sending" end. Use a pic with at least a couple of hundred bytes of RAM and buffer the incoming data before you do a write to the EEPROM. You would send a buffer full, then pause and wait for the PIC to send a CTS or ACK, then send another buffer... As long as you do it this way, you can write as slowly as you need to in order to write the FLASH.

I do a similar thing now, were I create a 2056 byte buffer (2048 bytes of data + CRC + control) in the RAM of an 18F8722, then send EEPROM data to the PIC in Intel Hex format over a 115K baud serial line, and when it is all received, check the CRC, convert it to binary and do the write to EEPROM. After programming the chip reboots (which destroys the 2056 byte buffer so I can now use the RAM space for my program) and starts with the new configuration. In my case, the 1024 bytes of EEPROM was inside the PIC, but it wouldn't have to be.

This was really designed as a fast way to configure a whole bunch of chips with the same setup, but you could adapt the technique for boot loading.

[Ioannis]

Hmm, yes you are right on the spped matter.

Thanks for the tips.

One question, why did you use Intel hex format? Is the conversion to and back necessary for your project? It uses abit of MCU power to do that...

Ioannis

[Charles Linquis]

I mis-spoke, I actually just used HexAscii (0x0f) = "0" + "F" because I couldn't figure out how to make the VB program I used to receive and send the data handle ASCII zeroes and other odd characters.

[Ioannis]

OK. Thanks for the details so far.

Ioannis