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 GCC 4.0.1.0 - missing macros in iomacros.h

Other Parts Discussed in Thread: MSP430FR5949, SFRA

I'm using an MSP430FR5949 microcontroller.  After installing release 4.0.1.0 of the gcc tool chain (from here), assembly of a custom crt0.S through gcc results in numerous errors, all involving the new macros:

/opt/ti/gcc-4.0.1.0/include/msp430fr5949.h:155: Error: unknown opcode `sfr_w(adc12ctl0)'
/opt/ti/gcc-4.0.1.0/include/msp430fr5949.h:156: Error: unknown opcode `sfr_b(adc12ctl0_l)'

The source file, crt0.S, includes msp430.h, which includes msp430fr5949.h, which includes iomacros.h.  In iomacros.h, new macros have been defined that were mentioned in the release notes:

    • Key Changes to Header & Support Files
    • .persistent section added to linker script
    • New file for symbol definitions is added for every device
    • new macros added to iomacro.h

    #define sfr_b(x) extern volatile unsigned char x
    #define sfr_w(x) extern volatile unsigned int x
    #define sfr_a(x) extern volatile unsigned long int x
    #define sfr_l(x) extern volatile unsigned long int x

      • heap memory support added to linker scripts

    These new macros are referenced hundred of times in msp430fr5949.h, 797 times to be precise.  The only problem is that when __ASSEMBLER__ is defined, these new macros are not defined.  Instead, the older sfrb, sfrw, sfra, and sfrl are defined.

    iomacros.h needs to be updated to include definitions of the new macros when __ASSEMBLER__ is defined.

    It appears that when compiling, these macros are designed to declare an external variable, which means that such variables must be defined elsewhere.

    Thus, they should be declared as external when assembling.  The GNU assembler, as, documentation states:

    .extern

    .extern is accepted in the source program--for compatibility with other assemblers--but it is ignored. as treats all undefined symbols as external.

    Until a permanent fix for this can be published, would a good interim workaround be to modify the iomacros.h file such that the macros mentioned above expand to nothing when assembling?

    #define sfr_b(x)
    #define sfr_w(x)

    #define sfr_a(x)
    #define sfr_l(x)

    Suggestions would be appreciated.

    Thanks,

        - Chuck

    • I reported this problem some time ago here:

    • Dave,


      Thanks for the reference.  It looks like there still has been no resolution from TI, or RedHat, or the new maintainer.  That's what I was hoping for.  Like you, I figured out how to get around it.  My biggest problem with that is that a file supplied in the distribution needs to be modified, which means that somehow, I have to get it under the change management system such that the new file will get deployed to each developer's machines.

      It appears that all the (now) global symbols are being provided in a device specific module, and that asm and C source reference these at link time rather than at compile time.  I ponder the motivation for this.  Will it save a few words off the text segment, or use instructions that execute in fewer cycles?

      Another motivation for the overhaul might be that the device specific headers maybe destined to be represented by C structures with absolute base addresses.  Like the compiler's output of C source, a register would hold a pointer to the structure (the base address), and the individual SFR's within the structure will be treated as an offset from the base.  This approach is consistent with some of the other non-TI uC's with which I have worked.  SFR's that are mirrored in structures seem to be more prevalent in 32-bit cores, and non-existent in the 8-bit cores.

      Just a few thoughts.

      I'll monitor the other thread for resolution.


      Thanks for the link,

          - Chuck

    • Will it save a few words off the text segment, or use instructions that execute in fewer cycles?

      No. The compiler could optimize these things only if it knew the actual addresses.
      (The old version used asm() to specify the addresses, so the compiler didn't know either. At least it did not get worse.)

      Another motivation for the overhaul might be that the device specific headers maybe destined to be represented by C structures with absolute base addresses.

      This would be completely indendent from the mechanism used to specify addresses.

      Anyway, if you want CMSIS-style headers, you have to write them yourself. (Or copy the definitions for the common modules like eUSCI from the MSP432 headers.)

    **Attention** This is a public forum