• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 79 subscribers
  • Views 145 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FR5949: Memory segmentation difference on 5949 vs 5849?

Jim Beck
Prodigy 80 points
Part Number: MSP430FR5949
Other Parts Discussed in Thread: CCSTUDIO, , MSP430WARE

I have a couple PCBs where the MCU is a MSP430FR5949 instead of _5849.  We have a loader piece of firmware that we put on using CCStudio.  This loader in turn will load a hex file of the 'real' firmware allowing users to update in the field.  It works fine on the _5849 and I modified it to run on the _5948 (48K). 

It seems like it should work on the _5949 without any changes since both are 64K.  After loading firmware I am having an issue with memory segmentation.  It crashes during erase that specifies memory start/end.  Since both MCUs are 64K and in same family, it seems they should be laid out the same. 

In the firmware definitions I see

#define USERSTART     0x5200        //end of Loader reserved FRAM - on 5949 use 5000, 5849 use 5200
#define USEREND     0x13FFF    //end of physical FRAM MSP430FR58x9 63K
#define USER_CK_END_L   0xFF7F      //applies to checksum also don't erase our vectors
#define USER_CK_START_H 0x10000      //Erase and checksum
#define USER_CK_END_H   0x13FFF      //Erase and checksum

Note the comment on using different end of reserved memory for 5949 vs 5849.  I have tried changing USERSTART to 5000 as suggested, and moving USER_CK_END_L back by 200 as well.  I have poked around in the documentation and can't find anything to sort this out.  Would appreciate any insight someone could offer.

regards

Jim

  • 0
    TI__Mastermind 26470 points

    Hey Jim,

    Did you load the exact same image on both?  Or did you switch the project from FR5849 to FR5949 and rebuild then try this?  

    I agree that from a memory standpoint they should be identical.  Only thought I have is that if you are switching to the new device, it might automatically refer to a new .cmd linker file that is causing you issues?  

    Thanks,

    JD

  • 0 in reply to JD Crutchfield
    Prodigy 80 points

    I should've thought to double check the link file instead of assuming they would be the same - sure enough, in the 5949 .cmd  I found this:

        FRAM2                   : origin = 0x10000,length = 0x3FF8 /* Boundaries changed to fix CPU47 */

    In the 5849 .cmd length is 0x4000, and our firmware assumes this to be the case on erase, so I'm erasing past the boundary.  I will try that tomorrow, but seems very likely to be the problem.  I think the comment in our f/w was a red herring that sent me looking for a problem that doesn't exist.  Thanks!

  • 0 in reply to Jim Beck
    TI__Mastermind 26470 points

    Yeah, sounds like that's probably the issue. 

    Also, CPU47 applies to FR5849 as well.  If I import an example from the latest MSP430ware, I see this note in both .cmd files.  The .cmd file was probably updated in MSP430ware after your original project was created and so the update never got pulled in until now. 

    Check if this fixes your issue, but then I'd probably update both versions to avoid the possible errata. 

    Thanks,

    JD  

  • 0 in reply to JD Crutchfield
    Guru 19025 points

    My reading of CPU47 is that you have to be executing code from those addresses. And not just any code:

    "An unexpected Vacant Memory Access Flag (VMAIFG) can be triggered, if a PC-
    modifying instruction (e.g. - ret, push, call, pop, jmp, br) is fetched ..."

  • +1 in reply to JD Crutchfield
    Prodigy 80 points

    Well despite the promising idea, this was not the problem.  I (finally) looked at the  map.out files from the 2 different MCUs.  In the _5849 everything for the loader is written to the first FRAM area, but in the _5949 the loader is written to both FRAM and FRAM2.  Searched down thru the .cmd file and found following mod had been made:

    ifndef __LARGE_DATA_MODEL__
        .text             : {} > FRAM           /* Code                              */
    #else
        .text             : {} > FRAM            /* Code - modfied from FRAM2 | FRAM  */

    I will modify to account for  CPU47 though.  Thanks for pointing me in right direction.

**Attention** This is a public forum