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.

msp430 main flash / information flash

Other Parts Discussed in Thread: MSP430G2744

Hi all,

I want to use the flash to save large amount of variables during run time (several kb's), in all the tutorials all I see is about the information memory which has a significantly smaller size then the main flash.

Is writing to the memory flash is the same procedure as writing to the information flash? and if so, where can I find the address for the different segments to which I will want to write to?

Thanks in advance,

Omri.

  • Hi,

    Omri Berg1 said:
    Is writing to the memory flash is the same procedure as writing to the information flash?

    Yes, information memory is just "normal" flash with smaller segment size.

    Omri Berg1 said:
    and if so, where can I find the address for the different segments to which I will want to write to?

    In the microcontroller datasheet available on TI website.

    Regards,
    Maciej 

  • Thanks for the fast reply,

    In the data sheet I see that the code memory address is 0xffff - 0x8000,

    just to see if I understand correctly, the first segment starts at 0x8000 and the second at 0x8200 ? 

    Also I would like to know, how can I tell when in the memory I can start using for my own flash writing to save variables without overwriting code memory or any other important data? I guess I should use the *.map file made by the linker but I'm not sure where exactly should I look,

    Thanks,

    Omri.

     

  • Omri,

    You have never mentioned why device you are using therefore I am unable to verify your findings. There is a plenty of information on the internet how to read/write information memory.

    Ex: http://processors.wiki.ti.com/index.php/Placing_Variables_in_Specific_Memory_Location_-_MSP430

    Regards,
    Maciej 

  • Sorry,

    forgot to attach this file from the data sheet

  • My question would be how can I know where in the code memory is it safe to save? 

  • You can look into/edit linker file.

  • Omri Berg1 said:
    how can I know where in the code memory is it safe to save? 

    You can know by tellign the linker to not use this area.

    In your project folder (for CCS), tehre is a linke rocmmand file. It was copied there from default when the project was created, adn is MSP specific. It tells the linekr where ram and flash is and what to put where.

    If you change the beginning (and the size) of the code segment by 0x200, then you will know that the first 512 bytes (one segment) are safe to use as the linker will never put anything there.

  • Thanks Jens-Michael,

    After changing the linker command file located under "C:\ti\ccsv5\ccs_base\msp430\include\lnk_msp430g2744" (this is the msp I'm using) I'm getting a list of errors

    "Description Resource Path Location Type

    #10264 INT00 memory range MPOD_lnk_msp430g2744.cmd /MPOD_MSP430 line 64 C/C++ Problem"

    All the way to INT14 and RESET.

    The change I made was:

    from : 

    FLASH : origin = 0x8000, length = 0x7FDE

    to:

    FLASH : origin = 0xAC00, length = 0x53DE

    As I was looking to make sure I have 22 segments free for my later use.

    I was hoping you or someone else could point me to the fix,

    Thanks.

  • Since the chip you are using has main flash from 0x8000 to 0xFFFF and the linker was told so, the linker can put code (and constants)  any where in that address range. But most likely it will only use the last segment (0xFE00 to 0xFFFF) for the interrupt/reset vectors plus as many segments as necessary starting at 0x8000 and ending at 0x????. You can find what 0x???? is from the map file generated by the linker. You may use the segments starting at:

    ((0x???? + 0x01FF) / 0x0200) * 0x0200

    (that is rounding up 0x???? to the next address divisible by 0x0200)

    An alternative way is. Instead of telling the linker it can use 0x8000 to 0xFFFF, tell it to use, for example, 0xC000 to 0xFFFF (provided that this is enough for the code). This way you can use 0x80000 to 0xBFFF yourself.

  • First you shouldn’t change CCS default files, but the local file in your project ‘lnk_msp430g2744.cmd’.

    After you have changed under MEMORY the FLASH entry (as you did) you can create here a new memory area;

    MyFlash        : origin = 0x8000, length = 0x2BFF

    Under SECTION you create a new section;

    MyFlashInfo   : {} > MyFlash

    In you program you declare;

    #pragma DATA_SECTION(MyFlashData,"MyFlashInfo")

    unsigned int MyFlashData

  • Hi,

    does anyone of you know, where to change the settings within IAR Workbench.

    I can find a "Ink430f5438a.xcl"-File within the IAR directory, but I can't find a config file within my project folder.

    Has IAR Workbench no local linker file for every project? 

    Thanks and best regards!

  • When I looked for the file, I found the "generic" in

    C:\Program Files (x86)\IAR Systems\Embedded Workbench 6.4\430\config

    You will want to copy the file into the directory where you have your workspace, and then edit it there.

    To point at the edited file (instead of generic), you can go to Project-->Options-->Linker-->Config and check the box "Override default" - then point at your new version of the linker command file. You can use $ type pointer or specifically show the address.

    To avoid any confusion, you could also rename the linker command file from the original name of "lnk430f5438a.xcl" to something that is along the lines of your project...

    Hopefully, that helps.

  • Hi Todd,

    thanks for that hint!

    In the last weeks my focus were on other topics, but now I'm again on writing to the flash. As I only found examples for adjusting the CCS files I'm not sure how to do it exactly in IAR.

    In the mentioned file I found this part:

    // -------------------------------------
    // All memory 0-FFFFF
    //
    
    // ---------------------------
    // Code
    //
    
    -P(CODE)CODE=5C00-FF7F,10600-45BFF  //10600 - 45BFF or 10000
    -Z(CODE)CODE_ID

    -Z(CONST)MYDATA=10000-10199
    -Z(CONST)MYDATA_COPY=10200-10399
    -Z(CONST)FLASH_STATUS=10400-10599

    // ---------------------------
    // Constant data
    //
    
    -Z(CONST)DATA20_C,DATA20_ID=5C00-FF7F,10000-45BFF
    
    
    // -------------------------------------
    // Interrupt vectors
    //
    
    -Z(CODE)INTVEC=FF80-FFFF
    -Z(CODE)RESET=FFFE-FFFF

    The lines between the code-snipets are my changes. Are they right in this section and/or do I have to do some additional changes?

  • A good starting point may be the TI example files. On the F5529, there are at least 3 different examples of flash writing - perhaps one of them may be close enough to your application that it could be used as a starting point.

    I have been struggling with a linker item on 5529, so I am not the best resource for the IAR linker command file...sorry!

     

  • Address ranges for Z option are interpreted by IAR XLINK tool as hexadecimal values unless they are preceded by a .(period). In your directives it looks like you logically use decimals. In hex the number after 10199 is 1019A, not 10200. So the range of memory from 1019A to 101FF and from 1039A to 103FF is not used. Was it your intention?

    Also you should change

    -Z(CONST)DATA20_C,DATA20_ID=5C00-FF7F,10000-45BFF

    to

    -Z(CONST)DATA20_C,DATA20_ID=5C00-FF7F,10600-45BFF

     

  • When you override the default linker file and make your own, be careful when updating the compiler. Sometimes, changes in the header files require changes in the linker scripts. And you modified script in the project folder won’t be updated. So a compiler update may break the build process or produce non-working binaries until the changes are ported into the local copy.
    This should be written with big exclamation points into the project documentation.

  • Hi Serge,

    thanks, in both cases you are right! Got confused while switching between dec and hex ;)

    But in prinicple it will work and I can save my data without any trouble in this address ranges? 

    Can I address e.g. the "MYDATA" section by this tag? 

  • S. L. said:

    Hi Serge,

    thanks, in both cases you are right! Got confused while switching between dec and hex ;)

    But in prinicple it will work and I can save my data without any trouble in this address ranges? 

    Can I address e.g. the "MYDATA" section by this tag? 

    Yes, it will work. You can put, say

    -Z(CONST)MYDATA=10000-10199

    to your .xcl file and in your C source file explicitly locate some const variables to this area using '#pragma location':

    #pragma location="MYDATA"
    const uint8_t myArray[3] = { 1, 2, 3 };

    In this example myArray will be placed at address 0x10000 by linker.

    You can also use MYDATA in your C source files implicitly via address pointer:

    uint8_t *myDataPointer = (uint8_t*) 0x10000u;

    and pass this pointer to your flash writing function as a destination address.

    Make sure you have excluded area occupied by MYDATA from all other declared memory sections in your .xcl file, otherwise linker may put some program code or constant data there as well. In this case when you write some data to MYDATA, it will clash with data/code placed there by linker and your program will crash.

  • Thanks Serge,

    that's exactly what I wanted to know! Thanks a lot!

  • This is a very helpful thread, and since it's only a few weeks old I'll post here before starting up a new one:

    I'm working on a 430g2553 in IAR and I've successfully (I think) changed my linker file to reduce the code memory space by 5122 bytes:

    //originally this all started at C000 but I moved it to C000 + (dec)5122 = 0xD402?

    -Z(CONST) DATA16_C,DATA16_ID,TLS16_ID,DIFUNCT,CHECKSUM=D402-FFDF

    -Z(CODE)CSTART,ISR_CODE,CODE_ID=D402-FFDF
    -P(CODE)CODE=D402-FFDF

    Now, I want to define my own memory segment.  Is this correct?

    -Z(CONST)STORED_DATA=C000-D400
    //leaving 2 Bytes because I think memory locations only start on even bytes?

    I have a few questions:

    Most important, did I do what I hoped for?  Did I, in fact, set aside 5120 bytes of flash memory for my own stored data? If I did everything correctly, this is 10 flash segments, is that correct?

    Second, is it correct to use CONST?  Is there some other thing it's supposed to be?

    Third, is there documentation for this feature so I can better understand what is in the xcl file?

    Thanks,

    Mike

  • Michael Stachowsky said:

    This is a very helpful thread, and since it's only a few weeks old I'll post here before starting up a new one:

    I'm working on a 430g2553 in IAR and I've successfully (I think) changed my linker file to reduce the code memory space by 5122 bytes:

    //originally this all started at C000 but I moved it to C000 + (dec)5122 = 0xD402?

    -Z(CONST) DATA16_C,DATA16_ID,TLS16_ID,DIFUNCT,CHECKSUM=D402-FFDF

    -Z(CODE)CSTART,ISR_CODE,CODE_ID=D402-FFDF
    -P(CODE)CODE=D402-FFDF

    Now, I want to define my own memory segment.  Is this correct?

    -Z(CONST)STORED_DATA=C000-D400
    //leaving 2 Bytes because I think memory locations only start on even bytes?

    I have a few questions:

    Most important, did I do what I hoped for?  Did I, in fact, set aside 5120 bytes of flash memory for my own stored data? If I did everything correctly, this is 10 flash segments, is that correct?

    Second, is it correct to use CONST?  Is there some other thing it's supposed to be?

    Third, is there documentation for this feature so I can better understand what is in the xcl file?

    Thanks,

    Mike

    1. If you need to reserve exactly 5120 bytes, your STORED_DATA description should look like 

    -Z(CONST)STORED_DATA=C000-D3FF

    2. //leaving 2 Bytes because I think memory locations only start on even bytes?

    .xcl file is normally used to assign all available physical memory to named segments. You don't normally have to explicitly exclude some areas just because of alignment issues. When you run your C compiler or assembler, it produces object files for linker and these object files already have all necessary alignment info for the linker.

    In your case above you excluded one byte from use at address 0xD401. But this byte can well be used, for example, to store one byte const variable. Let the linker decide instead :-)

    3. Yes, (CONST) is OK.

    4. IAR Linker and Library Tools Reference Guide is the document related to .xcl file contents.

    5. The best teacher and document is your .map file. Try to play with settings of .xcl file and see how it affects your resulting memory map. 

  • Great, thanks.  I made the change to keep the two bytes.  One question that I'm still trying to figure out:

    For example, 0xD401 is an address that contains a single word, and thus it is two bytes long, is that correct?  Then why can I directly access 0xD402 to store a byte?  This caused me some trouble when I forgot how pointers worked :-P I assumed that int *addr = 0xD401 means that addr+1 = 0xD402, rather than "the next integer after 0xD401" (which would be 0xD403?)

    Mike

  • > For example, 0xD401 is an address that contains a single word

    This can't be right. The MSP430 microcontroller can access memory using 8- or 16-bit accesses. However, when a 16-bit access is performed, the data must be located at an even address. This also applies to the code sections. The compiler ensures this by assigning an alignment to every data type. So for your example address of a 'word' variable should be 0xD400, 0xD402, etc. In this case you can access your word via pointer to a 'word':

    uint16_t *myWordDataAddr = (uint16_t*) 0xD400u;

    Also you can access separate bytes of this 16-bit data via pointers to a 'byte':

    uint8_t *myLoByteDataAddr = (uint8_t*) 0xD400u;

    uint8_t *myHiByteDataAddr = (uint8_t*) 0xD401u;

     

    > Then why can I directly access 0xD402 to store a byte?

    - You can access directly any location in the whole memory as a 'byte' variable via corresponding pointer. Even though if this location is a part of 'word' or 'long' variable or part of  executable code. That's how the whole pointer concept works. There are architectures which provide some protection against free memory access via pointers, but MSP430 is not the case.

  • Yes you're right.  Sorry, my pointers are a bit rusty.  That makes sense. 

**Attention** This is a public forum