QY4 Flash Memory Content Corrupted

[wheelmonitor]

Hello,

I am using MC68HC908QY4CDW in my products( the date code is XAB0526). I experienced field return units problems. The return units failed start up. It will resume work properly after I reprogram them. Obviously, the content of flash memory has been corrupted, but the user code never call the ROM-resided code to either erase, or write any contents of the flash memory.

I contacted at support@freescale.com a few month ago. I was advised with below suggestions, (1) protect the whole flash memory by programming FLBPR with all zeros. (2) shielding the MCU.

After I programmed the FLBPR with all 0s, some units still failed after a few thousands time of power ON and Off cycles. (Due to the physical constraint of the PCB board, we didn’t employ the shielding solution) 

In my application, no external reset and brown out circuit are used and the LVI reset function was DISABLED so that the MCU can poll the LVI to implement other functions.  After I enable the LVI reset function and programmed the same failed units, I have not witnessed  the units fail by cycling the power for more than 10,000 times.

My question is if this problem can be eliminated by enabling the LVI reset, is there any possible reasons that may cause the flash corrupted?  

Any thoughts or suggestions are welcome.

Tony

[wheelmonitor]

Thanks Alban,

There is a difference between mine and the attached.

I never call any ROM-resided code to erase or write any location of the flash.

The only possible reason for me is the disabling the LVI reset. After I enabled the LVI reset, it seems ok.

[peg]

Hi Tony,

Well now you have proved that you were running your MPU with an out of spec power supply.

Running when the PS is not in range can cause all sorts of issues.

Protecting the FLASH may provide some level of protection angainst this.

If you don't want to use the internal LVI then fit an external one.

Regards

David

[bigmac]

Hello Tony,

I concur with Peg about always enabling the LVI reset.  If you also need to sense an intermediate "low battery" condition you will need to connect an external voltage reference to one of the ADC channels.

It appears you may be experiencing a "code runaway" situation, quite possibly during power down, that the LVI reset eliminates.  I guess it is also possible that the FLBPR setting may sometimes be ineffective under these abnormal conditions.

I would also be wary about using an external reset device with the QY4 since the PTA3 pin is a shared pin that depends on the CONFIG2 setting, and its default state is as a port pin.  I have no idea at what supply voltage the CONFIG2 value could become corrupted,  and the external reset device would cease to cause reset.

Regards,

Mac

[quickdraw88]

Hi:

Our company has experienced the same loss of Vector Flash Memory (erased to $FF) while the main program memory remains intact. Probably 1 to 2% of units sent out. I'm planning to enable the LVI as per the recommendations in the thread here.

I also tried to set the FLBPR register to 0x00 with the following code:

const byte FLBPR_INIT @0xFFBE = 0x00;

It's located in the main user module just before the program code. It gives no errors in compiling, however, the expected line doesn't show up in the s19 file. Based on what I've read in this forum and elsewhere, I should be able to include this statement to make the setting of FLBPR automatic when programming the device, is that correct?

On another note, when enabling the "Initialize Trim Value" in the CPU bean of processor expert, I get random internal clock frequencies everytime I power up. Instead I've added the following code just prior to the main program:

asm LDA $FFC0
asm STA OSCTRIM

It seems to be working just fine.

Any help you can provide on how to include the initialization of FLBPR in my code would be much appreciated.

Gordon

[wheelmonitor]

Hi David,

Did you mean that my +5V power supply dropped too solwly when the power is off?

Tony

[peg]

Yes, or rose too slowly when you turned it on!

[wheelmonitor]

The datasheet only requires the rising ramp rate which was easily fulfilled not the falling ramp?

[peg]

Hi,

The ramp rate to which you refer is to allow the internal LVI to function properly. If you are not using it, it is irrelevant. The important thing here is to only allow the processor to run while its power supply is in spec.

Regards

David

[Alban]

Hello Tony,

Your post is quite similar to the following.

So similar that the search engine of this Forum returns a 100% match...

Have you read it and all the solutions provided ?

SCORE	SUBJECT / MESSAGE BOARD		AUTHOR	RATING	REPLIES	VIEWS	DATE/TIME
100%		QT4 security bytes being erased / 8-Bit Microcontrollers	irob		28	3077	2006-02-15 08:48 PM

Cheers,

Alban.