We are using a TMS320F2812 processor. It is programmed with a boot loader in the internal flash and an application in the external flash.
We program the boot loader in the internal flash by using Code Composer. Inside Code Composer there is a tool called the "F2812 on chip flash programmer". This tool allows one to unlock the CPU (if the pass code is known), program the flash and optionally lock the flash afterward. We DO NOT LOCK THE CPU after programming the internal flash.
As I understand it, this is the ONLY method of programming internal flash on this CPU.
Once we have loaded the boot-loader into internal flash, when it executes, it reads executable application data from a CANBUS device on the board, and stores the data on the external flash, one word at a time. Then if its checksum is valid, jumps to the beginning of the application.
On 3 CPUs (out of about 300 that we have programmed so far) we have had
a strange occurrence that we simply cannot explain. What happens is that the
CPU suddenly stops communicating with its controller. As part of the
post-mortem, we looked at the contents of internal flash and find that the
entire content has been overwritten with zeroes.
Here are screen shots of first the “good” code and second, an example of
the erased flash.
I discussed this with a TI technical representative several months ago and was given two conflicting diagnoses:
1. noise on the ADCREFP and ADCREFM pins.
2. Our application program may have gone off the rails and started
writing to internal flash and we should carefully examine our application.
We have programmed our external flash perhaps a thousand times so far
and we have programmed the internal flash about 300 times. We have never
accidentally programmed the internal flash while we were programming the
external flash (even when we were developing and debugging the external flash
programming code about 4 years ago). Nor has this ever happened in a controlled
environment (our lab). This has only happened in the field as part of a
power-cycling of the CPU.
On very rare occasions (perhaps once out of a thousand times), when we
power cycle a previously good CPU that had been running debugged, mature code,
it fails to boot and is found to be dead with the internal flash erased. The
code that was running was not attempting to program anything during this
abortive boot up, it was just restarting its external flash application.
Attempts to reprogram our CPUs require us to connect a special piece of
hardware that feeds the code to the CPU through a CANBUS channel. That piece of
hardware was not connected to the device, so no flash programming code was ever
executed.
And furthermore, we DO NOT EVER program internal flash, so:
How can I possibly program internal flash on the TMS320F2812 from my application?
I thought that was impossible.
In fact, if I had known there were a way to program the internal flash from our code that would be a boon to us to exploit such a method, because right now, the only way we know to do this is from Code Composer. Doing this from Code Composer is very cumbersome and causes our technicians some difficulty in loading the code.
