S12XEP100 D-Flash Unexpected Erase

[mroczeks]

Hi Guys,

I am facing a very strange behaviour of my S12XEP based board (some prototype board).

There is a bootloader and some main application in P-Flash memory.

I store startup address of main app in D-Flash so when the uC starts, it enters into bootloader code, reads the address from D-Flash memory and performes jump to that address (where main app is).

The strange thing is that from time to time the uC does not start the main app.

The first inspection shows that the bootloader is working ok, but is not able to jump to the main app.

I have had no time to examine it more deeply yet but I suppose the main app code is still there (it is in the same memory type as bootloader) but the D-Flash is erased. If so then the bootloader would not make jump.

Today it happened when I disconnected DB9 plug connecting USB CAN interface and board cable harness.

Tried to repeat that several times with no effects.

Any ideas? Anyone facing something similar? The only thing I can think of now is some ESD.

It already happened several times.

Regards

[jsmcortina]

Have you checked the mask-set errata for the chip you have?

I have an early DEMO9S12XEP100 and the mask-set of the CPU on there has a bug with flash bootup. If the supply voltage ramps up slowly the P-flash is unwritable.

For the technique you are using, I would suggest having the equivalent of an else clause in you bootloader. What to do if the D-flash IS erased? You need the code to do something in that case. i.e. do a global load and see if the address is 0xffff.

Why is the startup address of you application code variable?

In my application I'm using D-flash and P-flash and am also checking variables in the D-flash on boot with no ill effects that I'm aware of.

James

[mroczeks]

Hi,

As we use more S12XE based boards we face this problem more frequently. Finally we were able to find something...

We are able to reproduce the problem fairly easy now - we close and open supply circuit very quickly (manualy) like several times per second and usually after few tries we have this problem produced. We had a look at voltage waveforms all over our boards and no problems were found.

Here's the code

  /* INIT CLOCK */  /* 1. configure mcu clock: Fosc = 4MHz >> Fbus = 8MHz */  _SYNR.Byte = 0x03;  _REFDV.Byte = 0x40;  _POSTDIV.Byte = 0x01;    /* 2. wait for PLL to lock */  while(!_CRGFLG.Bits.LOCK) {  }    /* 3. select PLL as clock source */  _CLKSEL.Bits.PLLSEL = 1;  /* INIT FLASH */  /* clear the illegal address reset flag */  CRGFLG_ILAF = 1;       /* initialise the memory controller prior to any  */  /* commands being launched or EEE data access     */  while(!FSTAT_CCIF) {  }    /* load the clock divider before any flash command. Assumes 4MHz XTAL */  FCLKDIV = 3;            /* wait for ready state */     while(!FSTAT_CCIF) {  }  /* setup no protection */  FPROT = 0xFF;  /* wait for ready state */    while(!FSTAT_CCIF) {  }    bt_flag_value = Read_Flash_Byte(bt_flag_addr);    app_ok_value = Read_Flash_Byte(app_ok_addr);    app_start_value = Read_Flash_Dword(app_start_addr);

Where Read_Flash_Byte and Read_Flash_Dword are:

byte Read_Flash_Byte(dword globalAddress) {    globalAddress &= 0x00FFFFFF;     return *(byte * __far) globalAddress;  }dword Read_Flash_Dword(dword globalAddress) {    globalAddress &= 0x00FFFFFF;     return *(dword * __far) globalAddress;  }

What we found out is if we insert wait loop before first Read_Flash_Byte(bt_flag_addr) instruction the problem is impossible to reproduce.

while(delay) delay--;bt_flag_value = Read_Flash_Byte(bt_flag_addr);app_ok_value = Read_Flash_Byte(app_ok_addr);app_start_value = Read_Flash_Dword(app_start_addr);

Where delay is set to arbitrary value of 0x0008FFFF (589 823 idle cycles). We tried with different values and this is just somewhere close to minimum OK value.

Placing wait loop between Read_Flash... functions or after last Read_Flash_Dword we were still able to reproduce the problem. So placing wait loop before those three instructions is our only solution for now but it results in a ~2 seconds delay

PS. We use startup address as a code variable as we have many projects with different applications (with different flash locations) and we use common bootloader everwhere. During application upload the startup address is set depending on the application being uploaded.

I would greatly apreciate your help

[kef]

It is not clear a bit. From you desciption it seems like MCU reads wrong data from DFLASH, if accessed too early from reset, ~2s delay is required. Could you read the same flash before 2s delay and after 2s delay? Are values read before 2s delay wrong, and values read after 2s delay ok? Or both are are wrong?

is your DFLASH partitioned and do you have EEE partition? If so, did you try to wait for MGBUSY=0?

[mroczeks · Accepted solution]

Solved it. My app was doing writes into D-Flash on the very first moment after power up.
Processor Expert's function makes D-Flash write with sector backup in RAM.

I was "lucky" enough to face conditions when power was down in the middle of this function - exactly after sector erase and before updated content being writen into sector back from RAM.
So apart from improving supply stability during power on I will have to write D-Flash write mechanism with nonvolatile backup (into some dedicated D-Flash sector instead of RAM).

I did not have enough time yet to look closer to on-board's external watchdog chip operation but it is possible that due to supply stability problems during power up it was that watchdog resetting uC in the middle of D-Flash write function. I believe uC alone would handle those supply conditions better - the watchdog just puts more restriction on supply conditions.