MCU erases its flash memory at higher temperatures

cancel
Showing results for 
Search instead for 
Did you mean: 

MCU erases its flash memory at higher temperatures

Jump to solution
892 Views
Contributor I

Hello

I was trying to write a service request but it does not work -gives me an error when I am trying to send it . So I am posting it here.

 

We (UNIS company) are using Freescale DSP MC56F8323 and we just observed anomalous behaviour of MCU delivered to our customer.

 

The part of the MCU flash memory starts to lose the information when temperature is above the 65°C. Some memory cells change its values from 0 to 1 (erase state - MCU forget).

The higher temperature is - the more cells are erased.

When temperature drop back under  50°C, all memory cells has their original value (MCU remember)

 

More detail information is, that behavior is observed only in program flash memory, other parts of flash memory does not change with temperature. For programing the MCU, we do not use the default Freescale bootloader, but our own. The used programming process is in accordance with programming process described in chapter 6.5.2 "Write Operation" in MC56F8300UM.pdf

 

 

Anomalous behavior was not observed in our company, but after delivering our unit (with the MCU) to customer.

Now, we are trying to figure out, what could cause this behavior.

Our suspicion is, that our customer exposed the MCU to temperature higher than 125°C.

 

We have following questions:

1) Could this anomalous behavior of MCU be caused by exposure the MCU flash memory to temperature higher than 125°C?

 

2) Do you have an idea, what anomalous behavior could be caused, if not temperature?

 

3) Other units in delivered batch were probably exposed to higher temp as well as the problematic one, but they are functional. We did not observed any anomalies in behavior on them, but If answer to question [1] is "yes" , then the question is: Can service life or reliability of exposed units be affected?

 

4) Can service life or reliability of exposed units deteriorate within time?

 

5) Do you have customers who observed similar problem?

 

Thank you

 

S pozdravem / Best regards

 

Jan Coufal

Labels (1)
0 Kudos
1 Solution
205 Views
Senior Contributor IV

I'm not familiar with 56F, but it sounds to me like an inproper flash clock divider setting, which may lead to premature programming completion and unstable bits and high temps. FMCLKD register is write once according to peripheral user manual. This means that you can't set PRDIV8 bit and DIV bits in different write cycles. Make sure yo write FMCLKD once with all bits values (PRDIV8 and DIV) specified in one C statement

FMCLKD= xxx;

or in one asm store instruction

View solution in original post

0 Kudos
3 Replies
205 Views
Contributor III

I have also seen this problem on a suppliers component several years ago. The reason was not easy to find, but finally we found the problem in Freescale's Bootloader v. 1.0.1 which was configured to run on the internal 'Relaxation Oscillator' and using a factory-programmed trim-value. The error was that it did OR in the trim-value in the trim register (instead of overwriting the default value). This was fixed in the version 1.0.3 of the Bootloader. You say that you are using your own bootloader, but if you have used this part from the Freescale loader, it is possible that you also have the same error.

Sten

0 Kudos
206 Views
Senior Contributor IV

I'm not familiar with 56F, but it sounds to me like an inproper flash clock divider setting, which may lead to premature programming completion and unstable bits and high temps. FMCLKD register is write once according to peripheral user manual. This means that you can't set PRDIV8 bit and DIV bits in different write cycles. Make sure yo write FMCLKD once with all bits values (PRDIV8 and DIV) specified in one C statement

FMCLKD= xxx;

or in one asm store instruction

View solution in original post

0 Kudos
205 Views
Contributor I

We have to confirm this and run the tests to assure, that this really solves our problem. But right now, looks like you are right.

The manual MC56F8300UM chapter 6.7.1 is clear:

you have to write PRDIV8 bit and DIV bits at the same time (Bits six through zero cannot be modified once written.)

Our code:

  _fmclkd.prdiv8 = FLASH_PRDIV_ENABLE;

  _fmclkd.div    = (UINT16)FLASH_DIV_CONST;

Thank you

UPDATE:

Inproper flash clock divider setting (register FMCLKD) confirmed by tests.

0 Kudos