SIMPLELINK-MSP432-SDK: Flash Memory Issues - Marginal Read Example

Hi Zach,

It's highly unlikely that the FLASH memory is being marginally programmed.  My first thought would be to try reading out memory after it has been programmed and compare to a known good image.  Can you reduce your code to the absolute smallest size, but still demonstrates the issue and share?  What tools are you using?  CCS?

Hi Zach,

Any luck reducing your code?  What tools are you using?

Hi Zach,

It's been a few days since I have heard from you so I’m assuming you were able to resolve your issue.
If this isn’t the case, please click the "This did NOT resolve my issue" button and reply to this thread with more information.
If this thread locks, please click the "Ask a related question" button and in the new thread describe the current status of your issue and any additional details you may have to assist us in helping to solve your issues.

Hi Dennis!

Thanks for the help and pointing me in the right direction. I am using CCS, yes. I have reduced my code below. The check I am doing above seems to pass every time, so I am thinking you are right about that.. I am starting to wonder if the interrupt table is doing something unexpected, so i will check the memory browser and update with results. I made a recent change to include the buttonCheck because I was getting an issue with accidental double button presses. Is there a reason that clearing interrupts like this would cause potential issues? I know it's not an elegant solution..

Also, the concern is we are using a custom board (I know this is posted to the Simplelink MSP432 page, but couldn't find the correct forum for the MSP432P401R). The Vcore pin was unintentionally left floating, and later we found that this pin should have been tied to a 100 nF capacitor. Could something like this be causing our issue?

while(1)
{
    main_menu(); //displays the main test menu
    if (flag1)
    {
        buttonCheck(); //delays & clears pending pushbutton interrupts
        clearFlag();
        Foo();
    }
    else if (flag2)
    {
        buttonCheck(); //delays & clears pending pushbutton interrupts
        clearFlag();
        Foo();
    }
    PCM_gotoLPM0();
}

Port3_IRQHandler (void) //pushbutton ISR
{
    uint32_t status;
    status = GPIO_getEnabledInterruptStatus(GPIO_PORT_P3)
    for(debCount = 0; debCount < 10000; debCount++);
    MAP_GPIO_clearInterruptFlag(GPIO_PORT_P3, status);
    if(status & GPIO_PIN6)
        flag1 = true;
    else if(status & GPIO_PIN7)
        flag2 = true;
}

Hi Zach,

Yes, the 100nF cap is very important.  It helps to regulate the Vcore voltage and act as a 'tank' capacitor to provide current when some CPU operations may draw more current from the internal LDO.  If you don't have one, put one in somehow.

Regarding the buttons and double presses, this is very common when using mechanical buttons.  When you push the button, the mechanical switching may toggle many times until it settles.  This is called bouncing and you need to have some way to 'debounce' the switch.  One way is to have a series resistor between the button and the MCU IO pin, plus a small cap on the same side as the resistor and switch.  This creates an 'RC' circuit that effectively filters out the mechanical bouncing.  The other way is in software, which sounds like you figured this out.  By disabling the interrupt after the first interrupt, you are preventing a double triggering effect.  One way to improve on this is after disabling the interrupt, check the state of the IO pin after 20msec or so.  The switch should have rested in its final state by then so you can get a valid state.