MSP430FR5730: FRAM write issue

Part Number: MSP430FR5730

Hi,

I'm using MSP430FR5730 to store a camera flash counter in the FRAM. Both counter and start_flag are noinit variable, and are stored in the FRAM. Following code worked fine at simulation, however it does not work when a real camera flash fires. I toggled a pin to make sure the edge detection logic worked. When the flash fired, I could see the pin toggling on the oscilloscope every time. However, the counter never changed. 

Does this mean that the FRAM can not be used in a such environment that may be a little noise? Or am I missing something here?

thanks

Peng

////////////////////////////////////////////////////////////////////////

// in the .cmd file

//.TI.noinit  : {} > FRAM                /* For #pragma noinit                */

////////////////////////////////////////////////////////////////////////

/*
* ======== Standard MSP430 includes ========
*/
#include <msp430.h>

/*
* ======== Grace related includes ========
*/
#include <ti/mcu/msp430/Grace.h>
#include "stdint.h"
#include "driverlib.h"

#include "board.h"
/*
* ======== main ========
*/

#pragma NOINIT(counter)
uint16_t counter;
#pragma NOINIT(start_flag)
uint16_t start_flag;

int main(void)
{
Grace_init(); // Activate Grace-generated configuration
// >>>>> Fill-in user code here <<<<<

uint8_t port1, port1_delay;
uint8_t i;

//init counter at on a blank board
if(start_flag != 0x1298) {
start_flag=0x1298;
counter=0;
}
GPIO_setOutputLowOnPin(GPIO_PORT_P2,GPIO_PIN4);
port1=1;
port1_delay=1;
while(1){
port1=P2IN & BIT6;
if((port1_delay!=0) && (port1==0)){ // falling edge
for(i=0;i<100;i++); // delay about 1us
port1=P2IN & BIT6; // verify the pin status again for de-jitter purpose
if(port1==0){
// flash detected, increase the counter and write it back the FRAM
counter++;
GPIO_setOutputHighOnPin(GPIO_PORT_P2,GPIO_PIN4); // toggle the pin for debug purpose
for(i=0;i<10;i++);
GPIO_setOutputLowOnPin(GPIO_PORT_P2,GPIO_PIN4);

}
}

port1_delay=port1;

}


return (0);
}

11 Replies

  • Hi Peng,
    How did you simulate this?
    Can you check to make sure the variable isn't being placed in an MPU protected region? (easy way is to check if the MPU violation flags get set).

    You might also try using the persistant declaration. Here is an appnote outlining how to this in both CCS and IAR www.ti.com/.../slaa628.pdf

    Best regards,

    Cameron P. LaFollette


    If this answers your question, PLEASE, click on the  Verify Answer  button below! :-)

  • It could be that counter variable is being optimized out, since you are reading it only to increment itself...

    Try putting a "volatile" modifier in its declaration.

    Best regards,

    P.


    Help make the forums a better place. Please click [Verify Answer] when someone helps solve your issue.

  • In reply to Cameron LaFollette:

    Hi Cameron,

    I used an FPGA to toggle the input pin. I can see the counter changing as well as the pulse generated on P2.4. However, when I hooked it up to optical sensor on the flash board. I only saw the pulse on P2.4, the counter never changed.

    I tried persistent. However,  because it requires initialization, and the debugger does the initialization automatically, so I lost the counter when I hook up the debugger.

    Peng

  • In reply to Piergiuseppe Tundo:

    I disabled the optimization. But volatile is a good point, I'll give that a try.
  • In reply to Peng Peng:

    Hi Peng,
    Did you have any luck with this?

    Best regards,

    Cameron P. LaFollette


    If this answers your question, PLEASE, click on the  Verify Answer  button below! :-)

  • In reply to Cameron LaFollette:

    Peng,
    I will need to close this, unless I get a response from you soon.

    Best regards,

    Cameron P. LaFollette


    If this answers your question, PLEASE, click on the  Verify Answer  button below! :-)

  • In reply to Cameron LaFollette:

    Hi Cameron,
    I did not figure a way to make it work. It looks like that the FRAM is vulnerable  to the noise spike. We decided not to use FRAM any more. So if you need close it. I'm OK with that. But the root cause still remain unknown.
    Peng
  • In reply to Peng Peng:

    This is really odd. I'd try to replicate this, but I don't have a camera flash and photodiode to replicate your setup.

    Can you try stepping through the code to see if you do indeed hit the increment line? While you are doing this, set a watch expression for the variable so you can observe the counter increase.

    I really doubt this is an issue attributable to noise, but, can you go ahead and send me a screenshot of the signal/noise on an oscilloscope?

    Best regards,

    Cameron P. LaFollette


    If this answers your question, PLEASE, click on the  Verify Answer  button below! :-)

  • In reply to Cameron LaFollette:

    Hi Peng,
    Do you have any update here regarding my questions above? Please respond or I will need to close the issue.

    Best regards,

    Cameron P. LaFollette


    If this answers your question, PLEASE, click on the  Verify Answer  button below! :-)

  • In reply to Cameron LaFollette:

    Hi Cameron,

    I don't have any data to update you because we decided not to go with the FRAM. The test environment was removed. You can close this ticket.

    thank you
    Peng