David Mayen

AZ32A EENVR changing value at run time with out explicit write

Discussion created by David Mayen on Nov 14, 2006
Latest reply on Nov 15, 2006 by Alban Rampon



 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 …..