Flash Memory and OSC

fabrice · ‎2002-11-08

Posted on November 08, 2002 at 15:30

fabrice · ‎2002-09-25

Posted on September 25, 2002 at 10:42

Hi,

I would like to know more about the Flash Memory:

1). When (because of stress or alteration) the Flash Memory give a wrong value, how can we see this fault: Bit error, a bit 1 is read 0, a bit 0 is read 1, a byte error, a 16 byte error a bank error?

2). Do we have the same behaviour by short circuit (osc1 and osc2) or electrical line broken on OSC when CSS active?

Thank you in advance.

fab

chrys0720003 · ‎2002-09-25

Posted on September 25, 2002 at 12:13

Hello,

To answer at your first question, you have to know that when you cross the limit (eg.1000 cycles of programming, mentioned in data sheet) of Flash programming cycles, FLASH may behave wrongly. The user doesn't have any option to find the bit or byte fail. You can simple have the option of PASS or FAIL for programming including in the programming tool.

For your question 2: If CSS is enable in option byte and there is problem in MAIN clock, Backup oscillator will be activated and set the flag (CSSD) in system control/status register. This will indicate backup oscillator activation. You can consider this bit as a detection of main clock problem, but which one that can not be predicted (Short or broken).

johan239955_stm1_stmicro · ‎2002-11-08

Posted on November 08, 2002 at 15:30

Stress, alteration but also aging (see specified Flash data retention) and frequent erase/program operations (see min write erase cycles in the datasheet) can alter your Flash memory.

It would result in the execution of incorrect code (wrong data value, opcode that becomes crytical bytes like wait or halt) or even worst the execution of illegal bytes (bytes not part of the instruction set). In this case...

There is nothing you can really do to detect Flash alteration due to aging and stress

Maybe perform a checksum on the memory (see Checksum Computation of HDFlash in the FLASH Programming manual, or checksum by software for XFlash). But if this code is also corrupted... too bad ! And when should the micro perform this checksum ??? It is therefore almost impossible to check this alteration.

However, checksum and verify operation are definitely a good way to detect Flash alteration due to excessive erase/program operations. These functions are available in any programming tool (in socket programming or ICP) or can be implemented in the user's code (bootloader) if the device is programmed through IAP.

Regards,

Jojo