MC9S08JM60 Flash all 00s

[kh8324987]

Hi,

We have a unit of MC9S08JM60 which after several months in the field, appears to have had the contents of its Flash memory cleared. When we examined the contents of Flash memory via HCS08 Flash Programmer, we see that memory at all locations is 00, so program data has somehow been erased (or overwritten since erasing results in FF?).

There is no possibility of the MCU being reprogrammed out in the field so we are investigating how this might have happened. I would appreciate any ideas or details of similar experiences. Thank you.

Ken

[kef2]

Hi

Are you sure it is not secured and thus not readable by programmer?

[kh8324987]

Hi Edward,

Thank you for pointing out this possibility. Security is not engaged.

I should also add that after we verified that the Flash was all 00s, we have been able to successfully program the MCU with the original program and verify Flash contents. We are unable to reproduce the all 00s.

Ken 

[kef2]

If flash is all 00's, then indeed it is secured. The fact is you can't read all 00's from JM60 flash. If NVSEC is not 0bxxxxxx10, then device is secure and you can't read any meaningful data from flash, you may read fake zeros, but in reality memory contents most likely is different.

[kh8324987]

As an experiment, we tried reading flash after securing the device by changing the value at 0xFFBF. In our codewarrior v6 environment, when we try to read the flash (save command) we get an error stating "protected memory in given range". 

In this state, we are unable to read anything, which leads me to believe that our device was not secured when we read the all 0's using the same steps. Please let me know if I'm missing something.

[kh8324987]

We were finally able to reproduce the problem. It seems the device does in fact get secured as well as something else getting overwritten in flash so our application does not run. Apologies for the confusion.

At this point, it seems the problem arises very infrequently when the power is toggled on our unit.
Since we are unable to read the flash after the device gets secured, it's not clear exactly which areas are overwritten (i.e. areas in addition to 0xFFBF).

We do have some flash routines used only during calibration and not normal operation (which should not be running when issue is occurring) that write to flash that might inadvertently be executing and overwriting the wrong location in flash? Flash is not protected (which I now realize we probably need to do). Thank you.

[kef2]

Are "In our codewarrior v6 environment" and "we examined the contents of Flash memory via HCS08 Flash Programmer" the same programmers? Did you write to NVSEC 0x00? I think if you read everything as 0x00 (including NVSEC) it must be secured and can't be trusted that flash contents is all 0x00's. Next time you get all 0x00's you should inspect security bits in FOPT register.

Edward

[tonyp]

If it's not security related, then the chip was accidentally programmed with all zeroes.

Check for bugs in your flashing routines.

Or, perhaps, stack overflow issues causing runaway code.

Do you protect flash right after reset?

[kh8324987]

Interesting, thanks for that bit of info. Strange since we do not ship with the MCU secured. Is there any other situation where we'd read all 00's?

[kef2]

Aren't you using any bootloader for FW upgrades? If you are, aren't you updating top flash sector? Sudden power loss or reset could make MCU secured and not responsive. BTW, if your bootloader update all code including bootloader, unless NVSEC value is specified in your code, MCU will get secured after first update (erase top sector, write top sector back with NVSEC omitted, default erased state NVSEC=0xFF is secure).

S08JM doesn't have dedicated data EEPROM. Chances are not big, but perhaps something is wrong in EEPROM emulation routine?

[kh8324987]

We are actually not using a bootloader as it's a rather simple application.

Can you elaborate on the EEPROM emulation possibly going wrong? The application does not write to flash once out in the field, it is only written to during calibration before it ships.