8051 FLASH concept for In Applicaton Programming.

I am in the process of trying to devise a scheme to support in application re-programming of a C51 program in FLASH memory of a Cygnal processor. I have a desire to implement this capability in such manner as to meet the following goals:

1) The application would be a single program image including the loader function such that when this image is programmed into a raw part at the initial manufacturing level that the complete application plus loader are programmed all in one step.

2) During the time of in-application re-programming it would be desired to not erase the portion of the FLASH memory where the interrupt vectors and the loader code is located. This is so that if the re-programming process is compromised somehow that the loader can still get control via the reset vector to support re-started attempts at the programming process.

3) The loader plus application code image would be validated as to integrity via a check system such as an XOR type CRC as opposed to the normal check sum codes that are commonly used. The loader would contain a routine to validate this code and would not permit the main application code to start up if the validation code was not correct.

4) The loader function would be activated by re-starting the target product via a powerup. The loader code, which would normally always take control of the system at power up would have a short delay loop wherein it looks to receive an 8 byte reprogramming wakeup sequence from the UART port from some host re-downloader system such as a notebook computer. If the 8 byte sequence was not received the loader would proceed to valdate the existing code image and try to start it up. If the code image is invalid then the loader would loop again to retry the receipt of the 8 byte wake up key.

Some design details I have thought of that would be part of the implementation of this scheme would be...

A) I would try to use a normal image file such as a .HEX file or .BIN file on the host side as the program source. This would minimize special tool and utility development.

B) A tool would be built that reads the linker outputs (probably in binary format that was derived from a combination of OH51 and HEX2BIN) and inserted an appropriate XOR type CRC code into the binary image. Note I already have a scheme for inserting a 16-bit checksum into a program image that is kind of clever. This works via a post processing tool that converts the linker OMF output to Hex and then to Binary. The tool then computes the check code but unstead of placing it into the binary image it instead re-writes a small assembler language include file with the current code. I then re-compile and link the program a 2nd time thus capturing the proper check code into the program image in the OMF format. This lets a program with the proper check code to be run with the debugger. I would expect to use much the same scheme to get a 32-bit CRC plugged into the application image for the loader validation process.

C) The loader function would be resident with the normal physical interrupt vectors of the processor. These vectors would be handled in a way so as to pass interrupt dispatching to an offset vector table produced by the C51 compiler and linker. I would expect the loader and interrupt vector functions to occupy 1K or 2K at the base of the FLASH memory space.

D) The loader would contain some handshaking sequence it sent back out the UART port to the host PC so that the host knows there is a loader present in the target and that re=programming is possible.

E) The loader function would also include functions to permit the host computer to read out the pages of the FLASH image.

F) A program such as a Visual Basic utility would be written that implements the re-programming function from the host end. This program would take care of sending the wakeup re-programming key, verifying the handshake back from the loader, be able to read out portions of FLASH, support erasing portions of the FLASH and support for downloading image records to the target for programming the FLASH.

G) The host program upon, loader wakeup, should be designed to read out the existing flash program base pages (1K or 2K bytes) and compare those bytes to the base butes of the new program image that has been requested for download to the target. If there is a mis-match in these compares it is an indication that the pass-through interrupt vector configuration and loader program are different from that originally programmed into the microcontroller FLASH. Under these conditions the host program would refuse to continue programming operations. If the base pages do compare then the host program would continue with re-programming past the base 1-2K area.

--------------------------------

Does anybody, that is interested in this subject matter, have any additional ideas or comments about the scheme I propose above. Have I left out some critical consideration, does the scheme seem like it should work, or do you like my idea of finding a way to avoid having to erase the base page area?

Also has anybody implemented a similar scheme? Any experiences to share about it? My goal is to find a reliable solution to the In Application Reprogramming system that is reasonably recoverable if there is a re-programming disruption.

Michael Karas