Jump to content
43oh

JozefL

Members
  • Content Count

    4
  • Joined

  • Last visited

Posts posted by JozefL

  1. 4 hours ago, jackak said:

    Hi Jozef,

    Thanks for that info, however I tried your recommendation and found that the variable, once set at 5, could not then be changed by other lines in the code (i.e. FRAM_count++) and instead would remain at five.  This is similar to the behaviour I observed from the energia-defined PLACE_IN_FRAM, despite the fact that the data memory region the .persistent section is in is rwx.  Is this the intended behaviour and am I simply misunderstanding the persistent attribute, or are there other factors at play here?  I wondered if it could be an MPU issue, but my understanding is that the MPU is disabled by default?  

    Thanks again for your suggestion!

    Yes, you shouldn't need to change any settings to be able to read and write from the main FRAM block.

    I'm able to observe a persistent variable being incremented with the following code on the FR5994

    #include <stdio.h>
    #include <msp430.h>
    
    unsigned long __attribute__((section(".persistent"))) persist = 5;
    
    int main (void)
    {
      WDTCTL = WDTPW | WDTHOLD;
      while (1)
      {
        persist++;
        printf ("persist %ld\n", persist);
        for (int i = 0; i < 1000; i++);
      }
      return 0;
    }

    I don't know what setup Energia does by default, but you should check that at least the watchdog is disabled, if it fires before you get to the modification of the persistent variable, then it will just stay at 5.

    There's plenty of posts about writing to FRAM on the TI E2E forums, you could check there if you continue to have problems. Particularly check out the code examples included in this thread https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/911028?tisearch=e2e-sitesearch&keymatch=msp430%20fram%20write

    Regards,

  2. Hi,

    It seems there is a bug using the "persistent" attribute in C++. Internally, the compiler validates the attribute and emits that warning before the initializer has been parsed.

    The attribute works fine in a C program.

    As a work-around I would suggest explicitly putting the variable in the ".persistent" section, this has the same effect as the "persistent" attribute.

    unsigned long int __attribute__((section(".persistent"))) FRAM_count = 5;

    Apologies that this bug caused confusion!

    Regards,

    Jozef

  3. Hi,

    It's good to see people using the new MSP430-GCC toolchain. I'm glad it's being made available within the Energia client.

    I'll note that you can use the "upper", "either", "lower" attributes to place code/data in a specific memory region, instead of having to manually specify a section.

    So you can do

    ADI_REG_TYPE  __attribute__((upper))  Param_Data_IC_1[PARAM_SIZE_IC_1] ...

    instead of

    ADI_REG_TYPE  __attribute__((section(".upper.rodata")))  Param_Data_IC_1[PARAM_SIZE_IC_1] ...

    I'd also like to point out that the MSP430-GCC version used by "package_msp430_elf_GCC_index.json", 8.3.0.16, is nearly a year old and there have been significant improvements to code generation and some new features in the latest 9.2.0.50 release. However, I do understand that Energia might want to to focus on maturity rather than using the very latest release.

    I think a specific feature that is somewhat relevant to the discussion in this thread is new "location" attribute which lets you place code/data at a specific memory address.

    The MSP430-GCC user guide on the TI website has some documentation on other features you may not be aware of: https://www.ti.com/tool/download/MSP430-GCC-OPENSOURCE

    Thanks,

    Jozef

×
×
  • Create New...