MSP-EXP430F5438: Flash bank erase issue

Hi Leon,

Can you use an oscilloscope to measure VCC on the board during the flash erase test? It is possible that repeatedly calling the FlashEraseBank function causes VCC to drop low enough to cause a reset.

You can also add the following code structure toward the beginning of your code main function and add breakpoints during debugging to test what exactly is causing the reset:

    switch(__even_in_range(SYSRSTIV, SYSRSTIV_PMMKEY)) {
        case SYSRSTIV_NONE:        /* No interrupt pending */
            _no_operation();
            break;
        case SYSRSTIV_BOR:         /* SYSRSTIV : BOR */
            _no_operation();
            break;
        case SYSRSTIV_RSTNMI:      /* SYSRSTIV : RST/NMI */
            _no_operation();
            break;
        case SYSRSTIV_DOBOR:       /* SYSRSTIV : Do BOR */
            _no_operation();
            break;
        case SYSRSTIV_LPM5WU:      /* SYSRSTIV : Port LPM5 Wake Up */
            _no_operation();
            break;
        case SYSRSTIV_SECYV:       /* SYSRSTIV : Security violation */
            _no_operation();
            break;
        case SYSRSTIV_SVSL:         /* SYSRSTIV : SVSL */
            _no_operation();
            break;
        case SYSRSTIV_SVSH:         /* SYSRSTIV : SVSH */
            _no_operation();
            break;
        case SYSRSTIV_SVML_OVP:     /* SYSRSTIV : SVML_OVP */
            _no_operation();
            break;
        case SYSRSTIV_SVMH_OVP:     /* SYSRSTIV : SVMH_OVP */
            _no_operation();
            break;
        case SYSRSTIV_DOPOR:        /* SYSRSTIV : Do POR */
            _no_operation();
            break;
        case SYSRSTIV_WDTTO:        /* SYSRSTIV : WDT Time out */
            _no_operation();
            break;
        case SYSRSTIV_WDTKEY:       /* SYSRSTIV : WDTKEY violation */
            _no_operation();
            break;
        case SYSRSTIV_KEYV:         /* SYSRSTIV : Flash Key violation */
            _no_operation();
            break;
        case SYSRSTIV_PLLUL:        /* SYSRSTIV : PLL unlock */
            _no_operation();
            break;
        case SYSRSTIV_PERF:         /* SYSRSTIV : peripheral/config area fetch */
            _no_operation();
            break;
        case SYSRSTIV_PMMKEY:       /* SYSRSTIV : PMMKEY violation */
            _no_operation();
            break;
        default:   break;
    }

Regards,

Ryan

Hi Leon,

Have you had a chance to look at the F5438 Erratasheet to see if one of the known issues resembles the behavior you're seeing? One of the Flash Errata Numbers may be affecting the performance, or if the behavior only appears when the F5438 is connected to the debugger, one of the JTAG ones might be a cause.

Regards,

Ryan

Hi Leon,

Has the .cmd file (linker file) for the project been modified to prevent any code from being unexpectedly placed in the Flash bank being erased? You may also want to disable interrupts before erasing the flash bank and re-enable them afterwards in your FlashEraseBank function to be safe.

Regards,
Ryan

Hi Ryan,

You can try to run the attached code. It doesn't need the bluetooth module, but keeps the stack in place (altough I do not like to return a valid bluetooth stack id, while it isn't valid). It allows you to enter the console and type "server" and than e.g. "flash 100". It ends up with the same result. So you only have to install the bluetooth stack as mentioned and replace the SPPDemo.c file in the samples directory with this one. Open the IAR project, build and go.

Regards,

Leon

3173.SPPDemo.c

Hi Leon,

I was able to replicate the behavior you're seeing thanks to the code and test setup you provided. After testing many possible root causes, I think the issue stems from instability on the voltage supply line caused by the power requirements needed to repeatedly erase a flash bank. As stated in the MSP430F5438A Datasheet, up to 11 mA is needed during a Flash bank erase which can cause noise on DVCC that could erroneously set the SVM low-side flag.

According to Errata Flash37 having the SVM low-side flag set may cause a corrupted flash read. Based on reading through the MSP430x5xx and MSP430x6xx Family User's Guide, it seems like fetching the corrupted instruction of 0x3FFF from Flash is common under these circumstances because it will be returned from a corrupted Flash read or trying to access an invalid memory address. 0x3FFF corresponds to a jump command to address 0x4 which itself contains 0x3FFF, causing an infinite loop. If the noise on DVCC is severe enough, it could generate the resets that you saw as well. 

Implementing code before and after the flash bank erase to make sure that the supply voltage is stabilized seems to have solved the problem. The updated code is attached. Please test it in your system and let me know if it corrects the behavior.

Thanks,

Ryan

0250.SPPDemo.c

Ryan,

Thanks for the code you sent me. I tested the code on the development board, and it works fine. So the next step I made is replacing the code in my own platform with this one, and it did not work. It still crashes as before.

So I went back to your code running on the development board and did some simple empirical testing. Now based on your voltage suspect, the entry and exit code of the flash erase should cover the voltage issue. However the behavior of this phenomena is really strange (as you have probably already seen by the tests you performed yourself). During testing some small modification were made to your code and the code onto the development board fails again.

I really don't understand why, but maybe you can help me out. I attached the modifications I made in the code, and surprisingly enough, I only added some "nop" instructions which normally do not cause any harm. In my opinion, this issue tends to be something out of normal behavior of the MSP.

Please let me know what you think about it and maybe there's still a good explanation for the behavior.

Regards,
Leon

4544.SPPDemo.c

Hi Ryan,

I tested the code you send me. First I made a linker file for IAR, because the one which is attached to your post is a linker file from CCS as I am not mistaking. Copying code to RAM for execution, I have never used before, but seems to work fine, without crashing.

The code I have adopted to run at my own platform, and surprisingly enough, it seems to run fine as well. So we have a big win here :-). Thanks for the effort so far.

What keeps me thinking however, why didn't I find any of this in the user manual or maybe in the MSP Ware library, since it doesn't dictate the "FlashCtl_eraseBank" function to reside in RAM ? So can you tell me in some more detail, what is the specific reasons for executing the code from RAM and what is the cause of the MSP fetching corrupted Flash instructions?

From my opinion, the code should be able to run from flash as well. Maybe you can tell me what I am missing?

To complete the post, I attached the code which I used for testing. I went back to the original situation, with the only difference that the code is copied to RAM. Further more, the IAR linker file is attached for completeness of this post.

Hope to hear from you soon,
Regards,Leon

3288.SPPDemo.c

lnk430f5438aRamCopy.zip