Jump to content
TheCompiler

flash corruption on msp430f5510

Recommended Posts

Hi,

I'm currently developing a software for the MSP430F5510. It worked fine with my development PCB for months, but as soon as I tried it on another one, I got very strange issues. My software is writing text to a display with a built-in font, and I'd sometimes get missing pixels, or the text "dEbug" or "debuf" instead of "debug".

 

I then simplified my code until I arrived at this:

#include <msp430.h>
#include <string.h>
#include "driverlib/MSP430F5xx_6xx/ucs.h"

static const uint16_t flash_data[] = {
        0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
        0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
        0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
        0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
};
static volatile uint16_t ram_data[] = {
        0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
        0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
        0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
        0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
};

void main(void)
{
    volatile uint32_t cnt = 0;
    static const uint32_t mclk = 25000000;

    WDTCTL = WDTPW | WDTHOLD;

    UCS_clockSignalInit(UCS_FLLREF, UCS_REFOCLK_SELECT, UCS_CLOCK_DIVIDER_1);
    UCS_initFLLSettle(mclk/1000, mclk/32768);

    while (1) {
        if (memcmp(&flash_data, (void*)&ram_data, sizeof(flash_data)) != 0) {
            _op_code(0x4343);
        }
        cnt++;
    }
} 

My code sometimes stops on the software breakpoint, so it seems sometimes the flash gets read incorrectly. Most of the times this happens very soon after the program starts (cnt <= 50), but sometimes it takes a lot longer (cnt = some millions). Then after the next reset it immediately happens again.

Some observations I made so far:

  • It does not seem to happen when the clock is 24MHz instead of 25MHz
  • It does not seem to happen on 2 of 4 prints I tested
  • When I use single values rather than arrays, it happens more seldom. If I use != instead of memcmp to compare them, it doesn't seem to happen (maybe it gets optimized away though?).
  • Optimisation level doesn't seem to make a difference
  • Inserting an ~1s delay before and after setting the clock doesn't make a difference
  • It seems it's always an 1 bit read as 0, i.e. I can't reproduce it if the data is 0x00 instead of 0xFF
CCSv5 project with the above minimal example: 3326.corruption_test.zip

The related parts of the schematics and layout look like this:

5556.schematics.png

 

The supply voltage looks good for both unaffected and affected prints.

Good:

5824.good.png

 

Bad:

8311.bad.png

 

I've seen TIs document about the flash corruption issue (slaa471), but they mention the MSP430F5510 is unaffected, and the kind of corruption doesn't seem to be the one I'm seeing.

I've also not seen anything related in the errata (slaz301j), except "Corrupted flash read when SVM low-side flag is triggered" which doesn't seem to be my issue. The chip revision is C, for both affected and unaffected prints.

Any help would be appreciated, I really have no idea what to try anymore. Thanks!

Share this post


Link to post
Share on other sites

I've noticed that you do not have a 32768Hz crystal on your schematic.

 

That would compel me to make dang sure that the ACLK (or XT1) isn't being used to drive anything. 

 

 

Instead of using this clock setup code:

UCS_clockSignalInit(UCS_FLLREF, UCS_REFOCLK_SELECT, UCS_CLOCK_DIVIDER_1);
UCS_initFLLSettle(mclk/1000, mclk/32768);

try using this clock setup code in this example and see if that makes a difference.

//******************************************************************************
//  MSP430F552x Demo - XT2 sources MCLK & SMCLK
//
//  Description: This program demonstrates using XT2 to source MCLK. XT1 is not
//  connected in this case.
//
//  By default, LFXT1 is requested by the following modules:
//     - FLL
//     - ACLK
//  If LFXT1 is NOT used and if the user does not change the source modules,
//  it causes the XT1xxOFIFG flag to be set because it is constantly looking
//  for LFXT1. OFIFG, global oscillator fault flag, will always be set if LFXT1
//  is set. Hence, it is important to ensure LFXT1 is no longer being sourced
//  if LFXT1 is NOT used.
//  MCLK = XT2
//
//               MSP430F552x
//             -----------------
//        /|\ |                 |
//         |  |                 |
//         ---|RST              |
//            |            XT2IN|-
//            |                 | HF XTAL (455kHz - 16MHz)
//            |           XT2OUT|-
//            |                 |
//            |             P7.7|--> MCLK = XT2
//            |             P2.2|--> SMCLK = XT2
//
//   Bhargavi Nisarga
//   Texas Instruments Inc.
//   April 2009
//   Built with CCSv4 and IAR Embedded Workbench Version: 4.21
//******************************************************************************

#include <msp430.h>

int main(void)
{
  WDTCTL = WDTPW + WDTHOLD;                 // Stop watchdog timer

  P2DIR |= BIT2;                            // SMCLK set out to pins
  P2SEL |= BIT2;                            
  P7DIR |= BIT7;                            // MCLK set out to pins
  P7SEL |= BIT7;
  
  P5SEL |= BIT2+BIT3;                       // Port select XT2

  UCSCTL6 &= ~XT2OFF;                       // Enable XT2 
  UCSCTL3 |= SELREF_2;                      // FLLref = REFO
                                            // Since LFXT1 is not used,
                                            // sourcing FLL with LFXT1 can cause
                                            // XT1OFFG flag to set
  UCSCTL4 |= SELA_2;                        // ACLK=REFO,SMCLK=DCO,MCLK=DCO

  // Loop until XT1,XT2 & DCO stabilizes - in this case loop until XT2 settles
  do
  {
    UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG + DCOFFG);
                                            // Clear XT2,XT1,DCO fault flags
    SFRIFG1 &= ~OFIFG;                      // Clear fault flags
  }while (SFRIFG1&OFIFG);                   // Test oscillator fault flag

  UCSCTL6 &= ~XT2DRIVE0;                    // Decrease XT2 Drive according to
                                            // expected frequency
  UCSCTL4 |= SELS_5 + SELM_5;               // SMCLK=MCLK=XT2

  while(1);                                 // Loop in place
}

Share this post


Link to post
Share on other sites

I've noticed that you do not have a 32768Hz crystal on your schematic.

 

That would compel me to make dang sure that the ACLK (or XT1) isn't being used to drive anything. 

 

...

I'm not sure why one would be needed - the crystal on the schematic is just needed for USB, for the system clocks I want to use the DCO/FLL.

 

I have posted the same in the TI e2e forums, and there it was pointed out I forgot to increment VCORE. With the default (0), the maximum allowed frequency was 8 MHz, so it's mind-blowing it actually did run that well at all ;)

 

This solved the issue.

Share this post


Link to post
Share on other sites

I'm not sure why one would be needed - the crystal on the schematic is just needed for USB, for the system clocks I want to use the DCO/FLL.

 

I have posted the same in the TI e2e forums, and there it was pointed out I forgot to increment VCORE. With the default (0), the maximum allowed frequency was 8 MHz, so it's mind-blowing it actually did run that well at all ;)

 

This solved the issue.

 

If 24 MHz XT2 is already present on board don't see any reason for sourcing any clock from DCO / FLL. Depending on used peripherals, it is possible (even datasheet say opposite) to run MSP430F5510 at 24 MHz MCLK sourced from XT2 at default VCORE, also on lower voltage than 3.3V.

Share this post


Link to post
Share on other sites

Doh! That was the other thing that I do in my 5529 code.

 

I make use of the _system_pre_init() function to setup the vcore and the dco. I should have remembered. Sorry.

 

Here's a link to that code if you're interested to see how I've done it.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...