• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 78 subscribers
  • Views 707 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.

Changing MSP430AFE233 infoA memory size

Jaco van Zyl
Prodigy 50 points
Other Parts Discussed in Thread: MSP430AFE233

Good day,

I have ported the IAR energy library (SALC488) from TI to CCS and everything is working well with the exception that I'm not able to allocate EE memory for the nv_parms variables. There is a section in the main code;

 #pragma DATA_SECTION(nv_parms, ".infoA")

when compiled as is I get the folowing error;

"program will not fit into available memory.  placement with alignment fails for section ".infoA" size 0x80 .  Available memory ranges: lnk_msp430afe233.cmd"

I have tried to change the sizes of the infoA mem and this enables me to compile the software but the moment the debugging starts it is not able to load the software into the controller, I get the folowing error;

"MSP430: File Loader: Data verification failed at address 0x0000104C Please verify target memory and memory map."

Is there a way of increasing the memory size to be able to save this variables in EE?

Kind regards,

Jaco van Zyl.

  • 0
    Guru 227245 points

    To change the size of the InfoA segment, you'll need some silicon and a raster force microscope.

  • 0 in reply to Jens-Michael Gross
    Prodigy 50 points

    Thank you for the reply Jens,

    My question is probably more in the line of what is the work around why did they (TI) try to fit variables with the size of (128 bytes) into a memory segment of 64 bytes?

  • 0 in reply to Jaco van Zyl
    Prodigy 50 points

    Also to give more clarity on the matter when I say I change the memory size, I do the following in the lnk_msp430afe233.cmd file I change the memory section from

    MEMORY
    {
    SFR : origin = 0x0000, length = 0x0010
    PERIPHERALS_8BIT : origin = 0x0010, length = 0x00F0
    PERIPHERALS_16BIT : origin = 0x0100, length = 0x0100
    RAM : origin = 0x0200, length = 0x0200
    INFOA : origin = 0x10C0, length = 0x0040
    INFOB : origin = 0x1080, length = 0x0040
    INFOC : origin = 0x1040, length = 0x0040
    INFOD : origin = 0x1000, length = 0x0040
    FLASH : origin = 0xE000, length = 0x1FE0
    INT00 : origin = 0xFFE0, length = 0x0002
    INT01 : origin = 0xFFE2, length = 0x0002
    INT02 : origin = 0xFFE4, length = 0x0002
    INT03 : origin = 0xFFE6, length = 0x0002
    INT04 : origin = 0xFFE8, length = 0x0002
    INT05 : origin = 0xFFEA, length = 0x0002
    INT06 : origin = 0xFFEC, length = 0x0002
    INT07 : origin = 0xFFEE, length = 0x0002
    INT08 : origin = 0xFFF0, length = 0x0002
    INT09 : origin = 0xFFF2, length = 0x0002
    INT10 : origin = 0xFFF4, length = 0x0002
    INT11 : origin = 0xFFF6, length = 0x0002
    INT12 : origin = 0xFFF8, length = 0x0002
    INT13 : origin = 0xFFFA, length = 0x0002
    INT14 : origin = 0xFFFC, length = 0x0002
    RESET : origin = 0xFFFE, length = 0x0002
    }

    to the following 

    MEMORY
    {
    SFR : origin = 0x0000, length = 0x0010
    PERIPHERALS_8BIT : origin = 0x0010, length = 0x00F0
    PERIPHERALS_16BIT : origin = 0x0100, length = 0x0100
    RAM : origin = 0x0200, length = 0x0200
    INFOA : origin = 0x10C0, length = 0x0040
    INFOB : origin = 0x1040, length = 0x0080
    INFOC : origin = 0x1020, length = 0x0020
    INFOD : origin = 0x1000, length = 0x0020
    FLASH : origin = 0xE000, length = 0x1FE0
    INT00 : origin = 0xFFE0, length = 0x0002
    INT01 : origin = 0xFFE2, length = 0x0002
    INT02 : origin = 0xFFE4, length = 0x0002
    INT03 : origin = 0xFFE6, length = 0x0002
    INT04 : origin = 0xFFE8, length = 0x0002
    INT05 : origin = 0xFFEA, length = 0x0002
    INT06 : origin = 0xFFEC, length = 0x0002
    INT07 : origin = 0xFFEE, length = 0x0002
    INT08 : origin = 0xFFF0, length = 0x0002
    INT09 : origin = 0xFFF2, length = 0x0002
    INT10 : origin = 0xFFF4, length = 0x0002
    INT11 : origin = 0xFFF6, length = 0x0002
    INT12 : origin = 0xFFF8, length = 0x0002
    INT13 : origin = 0xFFFA, length = 0x0002
    INT14 : origin = 0xFFFC, length = 0x0002
    RESET : origin = 0xFFFE, length = 0x0002
    }

    In other words I'm trying to take some of the memory from infoD and infoC and moving it to infoB and then rather then using infoA I use infoB. But this does not work (propably because the page write sizes for this memory is 64 bytes). I'm not trying to get more EE out of the controller than what is available on a hardware level.

    Kind regards,

    Jaco van Zyl

  • 0 in reply to Jaco van Zyl
    Guru 227245 points

    Jaco van Zyl said:
    My question is probably more in the line of what is the work around why did they (TI) try to fit variables with the size of (128 bytes) into a memory segment of 64 bytes?

    Maybe because some MSPs have a larger segment size for the info segments (e.g. 5x family has).

    It's also possible that you made a mistake when porting the library. Maybe the variables were originally meant to overlap (like a Union). I don't know the code, so I cannot say.

**Attention** This is a public forum