• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 342 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.

LP-MSP430FR2476: pointer troubles using FRAM for large code

Florian Rohleder
Prodigy 20 points
Part Number: LP-MSP430FR2476
Other Parts Discussed in Thread: MSP430FR2476

Hi,

I've been seeing some problems using pointer operations when using large code and data model. For example memcpy does not really work. If I pass a pointer to a function and within that function I declare a new pointer to reference the input variable it seems to get stored in a higher address space. E.g. my original pointer is located in RAM between 0x2000 and 0x8000, the pointer in the new function is then located in FRAM e.g. 0xe000.

This causes pointer operations to be faulty and the original variable remains untouched. Is there any other setting I can use to fix this?

  • 0
    TI__Guru 68151 points

    Hi Florian,

    Can you provide small code example showing this problem?

  • 0 in reply to Dennis Lehman
    Prodigy 20 points

    Sure, so here is a code fragment in which this occurs:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    static int32_t mode_app_stop(struct v_mode *self)
    {
    struct i2c_msg_t *i2c_msg;
    struct mode_app *app;
    app = member_of(self, struct mode_app, mode);
    i2c_msg = to_i2cmsg(app);
    i2c_msg->size = 0;
    .
    . // continues here but irrelevant
    .
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    and here is a screenshot from the debugger values after i2c_msg->size = 0. You can see nothing changes. A similar thing happens for memcpy operations on newly allocated pointers.

    I can be sure, that it's not the code, since it's a third party driver code and I verified the behavior on another MCU with larger continuous RAM. On there the behavior is just as expected.

    Edit:

    To add here is an example for the memcpy issue:

    Fullscreen
    1
    memcpy(calib->data + calib->calib_len, i2c_msg->buf, len);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    You can see after the command, the data in calib->data and i2c_msg->buf is still different. The only explanation I have for that would be the different memory locations, since this works on other platforms

  • 0 in reply to Florian Rohleder
    Guru 22945 points

    Since the compiler is putting data into FRAM it is then vital that FRAM not be write protected. Or at least that section used for read/write data.

  • 0 in reply to David Schultz
    Prodigy 20 points

    How do I make sure of this?

    I guess it's related to this part of the linker file, but I don't think the symbol mentioned here is even defined, so the write protection shouldn't be active

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    #ifdef _FRWP_ENABLE
    __mpu_enable=1;
    start_protection_offset_address = (fram_rx_start - fram_rw_start) >> 10;
    program_fram_protection = 0x1;
    #ifdef _INFO_FRWP_ENABLE
    info_fram_protection = 0x1;
    #else
    info_fram_protection = 0x0;
    #endif
    #endif
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Florian Rohleder
    TI__Guru 68151 points

    Hi Florian,

    It's been a while since we have heard from you, so I'm going to assume you were able to move forward with your project.
    I will mark this posting as RESOLVED, but if this isn’t the case, please click the "This did NOT resolve my issue" button and reply to this thread with more information.
    If this thread is locked, please click the "Ask a related question" button, and in the new thread describe the current status of your issue and any additional details you may have to assist us in helping to solve your issues.

  • 0 in reply to Florian Rohleder
    Guru 92251 points
    Florian Rohleder said:
    I guess it's related to this part of the linker file, but I don't think the symbol mentioned here is even defined, so the write protection shouldn't be active

    The _FRWP_ENABLE and _INFO_FRWP_ENABLE macros can be defined by CCS.

    With CCS 11.1 created a new project for a MSP430FR2476 using the ti-cgt-msp430_21.6.0.LTS compiler. In the Project Properties under CCS General -> FRWP the "Enable FRAM Write Protection (FRWP)" and "Protect data FRAM memory (DFWP)" options were enabled:

    And from the CCS Build console could see the _FRWP_ENABLE and _INFO_FRWP_ENABLE macros were being defined in the linker command line:

    Fullscreen
    1
    2
    3
    Invoking: MSP430 Linker
    "/home/mr_halfword/ti/ccs1110/ccs/tools/compiler/ti-cgt-msp430_21.6.0.LTS/bin/cl430" -vmspx --use_hw_mpy=F5 --advice:power=all --advice:hw_config=all --define=__MSP430FR2476__ --define=_FRWP_ENABLE --define=_INFO_FRWP_ENABLE -g --printf_support=minimal --diag_warning=225 --diag_wrap=off --display_error_number --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU40 -z -m"MSP430FR2476_large_pointer.map" --heap_size=160 --stack_size=160 --cinit_hold_wdt=on -i"/home/mr_halfword/ti/ccs1110/ccs/ccs_base/msp430/include" -i"/home/mr_halfword/ti/ccs1110/ccs/ccs_base/msp430/lib/FR2xx" -i"/home/mr_halfword/ti/ccs1110/ccs/tools/compiler/ti-cgt-msp430_21.6.0.LTS/lib" -i"/home/mr_halfword/ti/ccs1110/ccs/tools/compiler/ti-cgt-msp430_21.6.0.LTS/include" --priority --reread_libs --define=_FRWP_ENABLE --define=_INFO_FRWP_ENABLE --diag_wrap=off --display_error_number --warn_sections --xml_link_info="MSP430FR2476_large_pointer_linkInfo.xml" --use_hw_mpy=F5 --rom_model -o "MSP430FR2476_large_pointer.out" "./main.obj" "../lnk_msp430fr2476.cmd" -lfrwp_init.a -llibc.a
    <Linking>
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

**Attention** This is a public forum