MCU erases its flash memory at higher temperatures

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

MCU erases its flash memory at higher temperatures

ソリューションへジャンプ
2,842件の閲覧回数
jancoufal
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

ラベル(1)
0 件の賞賛
1 解決策
2,155件の閲覧回数
kef2
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

元の投稿で解決策を見る

0 件の賞賛
3 返答(返信)
2,155件の閲覧回数
StenS
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 件の賞賛
2,156件の閲覧回数
kef2
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

0 件の賞賛
2,155件の閲覧回数
jancoufal
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 件の賞賛