8-bit Microcontrollers中的主题 Re: MC9S08JM60 Flash all 00s

MC9S08JM60 Flash all 00s

kh8324987 — Thu, 18 Apr 2019 01:44:05 GMT

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

Re: MC9S08JM60 Flash all 00s

kef2 — Thu, 18 Apr 2019 06:48:33 GMT

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

Re: MC9S08JM60 Flash all 00s

kh8324987 — Thu, 18 Apr 2019 07:19:08 GMT

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

Re: MC9S08JM60 Flash all 00s

kef2 — Thu, 18 Apr 2019 10:13:39 GMT

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.

Re: MC9S08JM60 Flash all 00s

kh8324987 — Thu, 18 Apr 2019 11:00:33 GMT

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?

Re: MC9S08JM60 Flash all 00s

kef2 — Fri, 19 Apr 2019 06:31:34 GMT

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?

Re: MC9S08JM60 Flash all 00s

kh8324987 — Fri, 19 Apr 2019 06:57:48 GMT

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.

Re: MC9S08JM60 Flash all 00s

kh8324987 — Fri, 19 Apr 2019 08:41:57 GMT

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.

Re: MC9S08JM60 Flash all 00s

tonyp — Fri, 19 Apr 2019 08:45:23 GMT

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?

Re: MC9S08JM60 Flash all 00s

kef2 — Fri, 19 Apr 2019 09:00:03 GMT

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

Re: MC9S08JM60 Flash all 00s

kh8324987 — Thu, 25 Apr 2019 01:59:29 GMT

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.