MSP430FR5969: solution for fram corruption in msp430fr5969?

Hi, Santhosh, 

From the E2E post you attached, the issue has been resolved by enabling the MPU. That is good news. 

Like Flash memory, FRAM memory is also needed to be protected. FRAM is easy to write to, and its write speed is much faster than Flash. Application code, constants, and some variables residing in FRAM need to be protected against unintended writes that may result from invalid pointer accesses, buffer overflows, and other anomalies that could potentially corrupt your application. From hardware point of view, we need to guarantee the power supply meet the specification requirements. In addition, system-ESD test or similar behavior like test strip plug in-out may cause the power voltage abnormal so that MCU may run in unexpected behavior to cause the memory corruption. Memory Protection Unit (MPU) is the dedicated memory protection module in MSP430 FRAM devices. It should be enabled by default in the user code. 

Application note slaa628 discussed how to implement a memory layout according to application-specific code, constant, data space requirements, the use of FRAM to optimize application energy consumption, and the use of MPU to maximize application robustness by protecting the program code against unintended write accesses. 

In critical applications, memory integration check is required. In Flash memory introduction application report slaa334, the CRC check is introduced for this purpose. 

In the new published application report slaa932, there is also introduction how to protect memory and check memory integration in system-level ESD tests. 

Hope the information can help to answer your questions. 

Thanks, 

Lixin 

Hi lixin,

Thank you for your reply,i am so happy

the problem occurs only some boards for example out of 100ea only 3ea the board the problem occurs i am so werid.

the problem occurs only in our client's side .why the pointer access and buffer flow not occurring in the testing?

Hi, Santhosh, 

I didn't mean your board failed case is because of invalid pointer accesses or buffer overflows. I just had an example for possible failed scenarios. 

MPU enabled can protect unexpected memory access. To find the real root cause of your board failure, it needs to dig into the system debug for hardware and software. 

Regarding why the failure didn't occur in the testing before you sent to your customer, I think it might be because customer application environment is different from your test condition. You can check details about it. 

Thanks, 

Lixin 

Hi lixin,

Thank you for your reply, can you say what kind of environment for example?

Hi, Santhosh, 

In your previous E2E post link, you only described "problem is device is getting RESET when an interrupt is given via GPIO(Button)". Maybe you can share more about how to reproduce the issue in customer side and how you did the test before releasing to customer. Then you can know if the test conditions are different or not and why you couldn't find the issue in your tests. 

Thanks, 

Lixin 

Hi,Lixin

Thank you for the reply, yes what you said is a correct problem is getting reset in the device then we planned to check by using FET prob to know the Hexa file in that some memory corruption(loss some memory )we dont why?

we have some different cases like directed cases, stress cases, negative cases, random cases

Hi, Santhosh, 

Do you mean the board got reset when button (GPIO) interrupt occurs? Do you know if the board can work well after the reset? When using the MSP-FET to check the memory, the memory change only happened at the address 0x4400 which is defined as global variant? What is the global variant and is it the root cause of the reset issue?

Could you reproduce the issue? If yes, could you share the test condition of it? 

It is better you can provide more information so that we can do the further analysis. 

Thanks, 

Lixin 

Hi lixin,

I am so happy because you have reply fastly thank you so much for the reply,

1) Not like that we have two switches and two led .one for reset and another for ble discover. in that our customer i have pressed ble discover button but they got reset indication.

2) so we decided to check the memory by using MSP-FET pro

3) From 0x4400 the memory is lossed we dont why?

Hi, Santhosh, 

1) It seems the BLE discover button press will cause the MCU reset. Do you have tested before sending to your customer? Can this issue be reproduced every time reliably? 

2) What is the variant definition for 0x4400? Is this memory loss related to the reset issue, i.e. the memory loss of 0x4400 cause the MCU reset? I don't know if your code will change the data of address 0x4400. The data is changed to unexpected value? 

Thanks, 

Lixin 

Hi Lixin,

1) Yes we have test perfectly, but it is difficult to recreate the problem.

2) From 0x4400 is the starting address of FRAM .when we have tested with FET prob we have analyzed that from 0x4400 some data is loss?so we asked in the forum they said check with the mpu so we planned to check the mpu in our code the mpu is not protected. so we decided to protect the mpu. still now we are not getting any problem from our  customer . but i want to know the exact reason why it is corrupted before enabling mpu

Hi, Santhosh, 

I think your data in 0x4400 should be not lost. When you used MSP-FET to probe the device through JTAG/SBW, did you program the code again? To check the memory integration, you need to connect the running MSP-FET without download the code. Another thing, MSP-FET will reset the MCU if no operate as specific instructions. For this case, the address 0x4400 will change to reset value. Could you let me know how did you probe the MCU with MSP-FET? How does the value changed for address 0x4400? 

Thanks, 

Lixin 

Hi, Santhosh, 

1) Since it is hard to reproduce the issue, it will hard to know the exact root cause because we cannot verify our idea.  

2) Why I asked what is the variable in address 0x4400 is the variable will be reset to initialization data when connecting with FET. So I want to know details about the data loss, whether the data loss is just to change back to initialization data or change to other unexpected data. If changed to unexpected data, that means the the memory was unexpected changed. For this case, we need to check the board voltage supply if there is any violation from the datasheet power supply specification, if the voltage is higher than specification with short pulse, if there is IO powered before the DVCC powered. Another suggestion is to check the application environment, if there is system ESD case such as high EMI source like sparkle, if there is ESD test on the interface pin, etc. But all the suspected points need to be verified, i.e. we need to reproduce the issue and apply the fix solution to verify. 

Thanks, 

Lixin 

Hi Lixin,

Thank you very much for the reply, yes it is very hard to reproduce the same issue.

but still, i have some doubt 

1) even though the mpu is protected perfectly for .text in that memory corruption occurs? due to low volatge