AZ32A EENVR changing value at run time with out explicit write

[mDavid]

Hello,

 I was wondering if someone has experience the same thing as me. In a project using the HC908AZ32A,  using the cyclone pro I created a SAP file with the s19 of my application. In the project the user has the ability to save some information in the EEPROM.

The problem was that in the code the EENVR was not touch assuming that it would stay in the factory programmed value of 0xF0 ( it was ok before starting using the cylone pro). But once we started using the cyclone pro we had to specify in the sap file creation process the value to put in the EENVR else it would be set to the erase state by the cyclone to 0xFF.

In one release, I forgot to set the EENVR to 0xF0 in the sap creation. The technician notice that it would take 2 or 3 tries and some power cycles before the data was save the first time around on new boards. After that there would be no saving problems. When eventually I was made aware of the situation I did some investigation an notice that once the card where programmed with the sap file the EENVR would be 0xFF when probing the code with the cyclone. So in theory it would have been impossible to save to eeprom.  I tried the application and indeed I had trouble to save data but eventually it worked. I connected to the board with the cyclone once more but this time the EENVR was 0xF0.

I tried looking in the code to see where the EENVR would be set to 0xF0 after some Eeprom erroneous writing  attends. I was unable to find where in the code the EENVR could be written to 0xF0, function to write to Eeprom where program to only access the EEPROM on the AZ32A but not addresses beyond that ( like EENVR @0xFE1C) .

So as unlikely at it may sound It seems as if the EENVR will go to 0xF0 after you try to do some writing operations to the eeprom and power cycle the unit.

My questions is then has someone experience this or in an infinitely subtle manner  in the code the EENVR is eventually set to 0xF0 event thought it is modified like an EEPROM byte .

Your comments …..

MDavid

[Alban]

Hi MDavid,

The behaviour you are describing is indeed surprising.

Let me first re-assure you as milions of these devices have already been shipped in the last years and work perfectly. That's why I would like to concentrate on your application.

I don't say it's not possible to have a device failure but all of them (no exception) are tested before leaving the factory.

Having bits going from one state to another without anyone touching them is called "bit-flip".

It does happen when the programming timings are not respected.

If you think as a Flash cell as a tyre with a slow leak. In our case, the air are electrons, and the tyre is the floating gate of the transistor making the bit cell.

Due to the technology (nothing linked to Freescale or any other manufacturer), some electrons will migrate with time. A one or a zero is recognized if the transistor is passing or not.

If not programmed properly, a tiny loss of electron may basculate the level of the transistor.

However, as you don't only program this byte but all the others, you should see other occurences.

I suggest you do a dump of the memory and see if the Flash/EEPROM matches your S19.

Another probable cause is code run-away.
As you mention the power-up sequence solves you problem after a few occurences.

Do you use LVI routine to detect low voltage conditions ?

Cheers,

Alban.