reliability of using flash for storage.

[TurboBob]

I have a question for the experts here.

I want to use part of the flash in a S08JM60 to log data on an occaisional basis.  I won't be wearing out the flash, so that's not a problem.

I will have a bootloader (AN2295) for updating the application,  so locking the flash segment where the app resides is not possible.  (unless I misunderstand the flash block protection mechanism)

How reliable is the flash writing process?  Is it risky to do this without having the flash block protection?

What's the collective wisdom on this?

Thanks!

Bob

[tonyp]

Given that with the 9S08 you cannot update applications in protected Flash because there is no way to temporarily un-protect it (even if using the backdoor -- I still haven't figured out what the real benefit for the backdoor mechanism is if it can't do this one basic thing), there is no way around putting the app into unprotected space (assuming you use a bootloader for app updates, that is).

So the only 'risky' aspect of using unprotected Flash is if your code has 'bugs' and attempts to write over portions of Flash that aren't supposed to be written (eg. code segment, sensitive data, etc).  Good code design can make this an impossibility.

Besides that, there is always the risk of writing to Flash while the power goes off, but this can be taken care of with various hardware and/or software methods.



Message Edited by tonyp on 2009-01-29 10:59 AM

[JaimeR]

What do you mean by this sentence?
"Besides that, there is always the risk of writing to Flash while the power goes off, but this can be taken care of with various hardware and/or software methods."

I am really interested in flash reliability when power goes off. I hope you can share with me a little more information about this subject.

Regards,

Jaime

[tonyp]

I think you misunderstood.  There is no reliability issue with the power being off.  The issue is if while you're actually writing to Flash you lose power.  Then you may end up with corrupted memory, if not careful.

[JaimeR]

Ohh, I see, thank you for your fast answer.

[kef]

Backdoor allows to unsecure the part, not to write-unprotect it. Benefits? Say you use chip security and receive some board with very strange failure. What if you need to read eeprom-flash settings that are not accessible over sci or something like that? Or verify if flash is programmed ok. Or what if after field tests (with secured chip), you want to debug without erasing all calibration data? Backdoor comes to help. The only problem - how to tell target what backdoor key is? There must be some communications channel (sci, iic etc), unless backdoor key is known to the firmware and you use some secret procedure to trigger backdoor unsecure.

To answer OP, FPROT register can be written to increase the size of protected flash. You bootloader may have NV write protection register set to protect just the bootloader. Then just before bootloader jumps to application code, or in applications startup, there could be a write to FPROT to protect whole flash or whole flash minus flash data area.

[tonyp]

About the backdoor, this is all fine and dandy but most of what you describe is not something you can't do with a simple dump utility from within your code.  A backdoor should be able to go beyond what you can do in software.  If the MCU is in good enough condition to run code (and it must be to be able to run the backdoor procedure itself), then the code can also provide some secret or 'PIN-enabled' method to provide all that debugging info you're talking about.  Another problem with backdoor is that all BDM equipment out there (that I know of) don't have a method of entering Background mode after a backdoor sequence.  They seem to assume that they have to have full control and always start by resetting which cancels the backdoor.

Anyway, I'm not saying Backdoor is totally useless, only that I don't see any real benefit for it.

Now, regarding:

---

To answer OP, FPROT register can be written to increase the size of protected flash. You bootloader may have NV write protection register set to protect just the bootloader. Then just before bootloader jumps to application code, or in applications startup, there could be a write to FPROT to protect whole flash or whole flash minus flash data area.

---

I believe FPROT is not user writable (at least not in all MCU derivatives, don't know about the specific MCU mentioned).  FPROT becomes loaded automatically with NVPROT which is always in protected space if you have protected the bootloader, above any code.  So, I don't see how this would work.


Message Edited by tonyp on 2009-01-29 12:00 PM

[kef]

Codewarrior debugger, at least for S12 one, has special option, that allows to debug after backdoor unsecure. Option is called "At connection, the target is running (hot plugging)".

FPROT is user writeable. At least S12C, S08QE and many other quite fresh parts grant FPROT writes that increase protection. You can't unprotect what's protected, but you can protect more than protected at the moment. Very useful feature.

Message Edited by kef on 2009-01-29 01:19 PM

[tonyp]

I knew QG8 for example, can't do it.  But you're right, it seems newer members can.  I just checked with the QE128 and its FPROT is writable for increasing the protection.  Good news!  Thanks.

[TurboBob]

Below is an excerpt from the S08JM documentation:

4.7.4 Flash Protection Register (FPROT and NVPROT)

During reset, the contents of the nonvolatile location NVPROT is copied from flash into FPROT. This

register may be read at any time, but user program writes have no meaning or effect. Background debug

commands can write to FPROT.

So, sadly I cannot manipulate the FPROT register.  That said,  the code will be very 'tight' regarding erasing and writing the flash,  and the RAM routine will be refreshed each time I run the flash routines.

Are there any other issues?  Will the LVI mechanism prevent the chip from shooting its foot off in case of a power fail?  This should be very unlikely, as the app monitors the raw power supply and can stop the flash routines long before we have a power problem.

Thanks!

Bob

[kef]

Hm, I thought new parts should be not worse than predecessors. Maybe FSL started JM long before than QE, or copypasted existing flash module.

Well, if FPROT is not writeable, then maybe try to avoid setting FCDIV until write is required. Programming before FCDIV is initialized should cause FACCERR error and work like poor write protection. If write to flash sessions are rare, then consider resetting MCU and keep FCDIV not set until next write session?

If something goes wrong, then bootloader should be able to start in any case. Checksuming application code and staying in bootloader when checksum fails is a good idea. At least user would be maybe able to reflash his device, not the same like dead device. 

[TurboBob]

I suppose it could be a misprint in the datasheet as well.  I'll cross my fingers until I get a chance to test it.

The FCDIV is a cool idea.  I will see if that fits into the scheme of things. 

I guess my only real worry is an inadvertent power fail in the middle of writing.  If the VCC drops when the chip is in the middle of a flash routine,  is there any way if could erase or corrupt the wrong sector?

Bob

[bigmac]

Hello Bob,

If you check the Vcc level just prior to each erase or write, it is unlikely there would be an issue, provided you have sufficient bulk capacitance connected between Vdd and Vss to maintain adequate voltage.  The worst case period is 20 milliseconds for sector erase.

If the device you are using has LVW, in addition to LVD, this might be used for early voltage sensing.  The LVW flag might even be tested within the command completion wait loop, and the erase command aborted if the flag becomes set.

An even earlier warning could be achieved by monitoring the input voltage to the regulator, using ADC channel or comparator.

Regards,
Mac

[TurboBob]

I monitor raw supply voltage before a 1000uf filter cap  (separated by a diode, I can tell when the input power is switched off.)  So I should have plenty of warning.

Additionally,  I will only be writing during the critical period,  so no erase (20ms) delays will be occurring.

I feel more confident now,  I didn't want to put a serial flash chip in there when there is a lot of space free in the CPU.

Bob

[Lundin]

The main risk is that you have to run the flash writing code from RAM. Hardened engineers consider RAM as unreliable, especially over time. That is, you shouldn't rely on the contents of the RAM to be preserved without corruptions for hours/days/weeks/years. The solution is easy: simply copy-down the code to RAM before each flash write. If you are serious, you also include a checksum with it.