This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430F2132: MSP430F2132 Controller writing issue

Part Number: MSP430F2132

We had a project utlize TI MSP430F2132 as product controller, stored product information within the chip's B and C segments of the FLASH information storage.
After a certain test everthing was normal, two days later the product was repowered on , and it was found that the data in area B and C changed to FF (initial flash state). During the two tests, only an electrical performance test was performed on the product. However, only the D area of FLASH has been read and written in the electrical performance, and there is no read or write operation in the B and C areas. We wanna consult the possible reasons for this phenomenon.
Remark: After the problem occurs, we test the read and writing function of the FLASH's B and C area, the chip can still use normally.

我公司某项目应用了TI公司的MSP430F2132作为产品控制器,在其片内FLASH的信息存储器B段、C段存储了产品信息。
某次测试正常后,隔两天对该产品再次上电测试,发现B区、C区数据均变为FF(flash初始状态),在两次测试期间,对该产品做过一次电性能测试,但是只对FLASH的D区进行过读写操作,B区、C区无读写操作。咨询一下产生该现象可能的原因。
注:出现该问题后,对该产品FLASH的B区、C区进行读写测试,可以正常使用

  • Hi, Mandy, 

    When doing the electrical performance test, do you have erased the code in segment B and C? Could you share the code how to access segment D? 

    In the user's guide, Segments A to D can be erased individually, or as a group with segments 0 to n. Just want to confirm you didn't erase them as a group. 

    Thanks, 

    Lixin 

  • Hi Lixin,

    When doing the electrical performance test, we only utlize writeflash wirte and erase segment D, didn't take any action on the other segments.

    Erase only done within the software performs segment, didn't erase them as a group. The code write in segment B, C and D all the same, as shared in below pictures, the subprogram in writeflash.

  • Hi, Mandy, 

    1. The FSSEL_1 = 0x0040. This means the MCLK selected instead of SMCLK. Please double check your clock setting is within FLASH speed specification. 

    2. From the errata sheet, FLASH24 mentioned the an erroneous code execution may occur if there is abrupt termination of the flash write or erase. Could you check if there is any clock issue for flash operation? 

    3. Another thing you may check: if there is any voltage drop during the FLASH operation. Please make sure the MCU VCC has enough de-coupling capacitors.

    A question, can this issue be reproduced reliably? If this issue only occurs once and not easy to reproduce, it should be due to abnormal clock stop or voltage drop. 

    Thanks,

    Lixin 

  • Hi Lixin,

    1. If the clock setting is abnormal, caused he abonormal action in flash read and wiriting, will this lead to the erase of full content in the flash or only change some part?

    2. Voltage drop can cause flash abnormal? how to explain? Is it causing the software to run away and rewriting the flash, or the power failure will directly affect the flash?

    3.Under what situation will the flash data memory be erased for multiple consecutive segments while the main memory (where code stored) is not affected?

    Below is the software writing code:

  • Hi, Mandy, 

    Mandy Ke said:
    1. If the clock setting is abnormal, caused he abonormal action in flash read and wiriting, will this lead to the erase of full content in the flash or only change some part?

    If the clock speed is over specification for FLASH operation, there will be unexpected behavior. Based on the datasheet, fFTG (Flash timing generator frequency) should be within 257kHz ~ 476kHz. 

    Mandy Ke said:
    2. Voltage drop can cause flash abnormal? how to explain? Is it causing the software to run away and rewriting the flash, or the power failure will directly affect the flash?

    Same thing, over specification will cause unexpected behavior. Based on the datasheet, the Vcc should be witin 2.2V ~ 3.6V during Flash memory programming. If the voltage drop causes the flash programming error for code area, code will run abnormally: anything can happen, may jump to unexpected code and write flash with unexpected data or erase flash. 

    Mandy Ke said:
    3.Under what situation will the flash data memory be erased for multiple consecutive segments while the main memory (where code stored) is not affected?

    Do you have code to erase the consecutive segments? For your case, do you have code to erase sector B and sector C? 

    Thanks, 

    Lixin 

  • Hi Lixin,

    Our last two questions:

    1. Does a voltage drop or clock abnormality affect the flash when the microcontroller is not operating on the flash?

    2. Under the premise of such a software design, what is the probability that segments B and C of the flash data storage area will be erased but at the same time the main storage area is not affected? We can eliminate the possibility of software runaway leaded to that circumstances right? Under our understanding that runaway will only affect one segment of the storage area at most, won't affect both segments at the same time?

    Thanks,

    Mandy

  • Our last two questions:

    1. Does a voltage drop or clock abnormality affect the flash when the microcontroller is not operating on the flash?

    2. Under the premise of such a software design, what is the probability that segments B and C of the flash data storage area will be erased but at the same time the main storage area is not affected? We can eliminate the possibility of software runaway leaded to that circumstances right? Under our understanding that runaway will only affect one segment of the storage area at most, won't affect both segments at the same time?

    Thanks,

    Mandy

  • Hi, Mandy, 

    Mandy Ke said:
    1. Does a voltage drop or clock abnormality affect the flash when the microcontroller is not operating on the flash?

    Yes. Even though the MCU is not operation flash, the voltage drop or clock abnormality will cause unexpected issue. Maybe the code jump to unexpected area to cause the unexpected FLASH operation. 

    Mandy Ke said:
    2. Under the premise of such a software design, what is the probability that segments B and C of the flash data storage area will be erased but at the same time the main storage area is not affected? We can eliminate the possibility of software runaway leaded to that circumstances right? Under our understanding that runaway will only affect one segment of the storage area at most, won't affect both segments at the same time?

    It is same as my question above: do you have code to erase sector B and sector C and if you can reproduce the issue reliably?

    If you can reproduce the issue reliably, you can try to remove the operation code for sector B and sector C and see if the issue is gone. 

    There are many ways to increase the software robustness in software engineering theory including error handling. But the basic is to guarantee the hardware no problem and there is no violation on specification. 

    Thanks, 

    Lixin