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.

MSP430FR5964: Linker locates ISR's in RAM

Part Number: MSP430FR5964

I’ve been tripped up porting some existing code to an FR5964. This is code that has run happily on the older 4 series, and the non-FR 5 series, but I’ve been having problems around interrupts on the FR – basically it disappears into la-la land as soon as it hits an interrupt. As this is the first play I’ve had with the FR processors, my initial thoughts were that it was something specific to the FR’s that I was missing (akin to the LOCKLPM5 needed to release the GPIO’s on startup). However, I’m not totally convinced this is the case.

To try and get to the bottom of this, I stole the initialisation code for the FR5994 evaluation board, and pared this down to some simple code, which does nothing more than initialise the MCLK and SMCLK, then enables UNMI interrupts. This immediately fires (not sure if it should do this, or its just the DCO settling, but that is a secondary question). I can catch this with the debugger, but any attempt to step past the ISR entry point immediately aborts.

I’ve followed this through the UNMI vector, which is correctly initialised to the ISR address (just happens to be 1C36). What is at the ISR memory looks like rubbish, and the disassembly in CCS looks nothing like a valid ISR. It took me a while to figure out that the ISR has actually been placed in RAM (starts at 1c00 on these processors), and that what I am seeing is pretty much uninitialised RAM being treated as code. While it would be technically possible to run the ISR’s from RAM in these processors, I assume it would need some of the non-volatile storage support to enable this, and I would hardly expect this to be a default. I haven’t found any references anywhere to this behaviour, so I’m still tilting towards some option (probably linker related) that I have wrong.

Can anyone explain what is happening here, and more specifically any hints on where the problem lies and how to resolve it.

BTW, I’m using the GCC toolchain 9.2.0.50, and CCS 9.3.0.

Thanks and regards - Andrew

  • Your ISR code should be going into section .lower.text which is put into FRAM. Treated not much differently than any other code.

    Have you looked at a .map file or anything else (msp430-elf-readelf) that would show you where everything is located?

  • Hi David,

    Thanks for confirming that the ISR's should be going into ROM (or FRAM in this case)....but that doesn't appear to be happening.

    I'm no whiz at reading linker maps, but here is what I can see (couple of other ISR's I've been playing with as well, so they appear here).

    .lowtext           0x0000000000001c00               0x60 load address 0x0000000000004064
    .lowtext           0x0000000000001c00               0x60 ./trunk/Int.o
                           0x0000000000001c00                         SYSNMI_ISR
                           0x0000000000001c04                         TIMERA1ServiceRoutine
                           0x0000000000001c14                         TIMERA2ServiceRoutine
                           0x0000000000001c3c                         UNMI_ISR

    This is the only reference I can find to a section .lowtext anywhere, but, from my understanding, this is placing all .lowtext targeted code into RAM (starting at 0x1C00). There is a section for .lower.data, which also references 0x1c00, which is what I would have expected.

    .lower.data      0x0000000000001c00                 0x0 load address 0x0000000000004064
                           0x0000000000001c00                           . = ALIGN (0x2)

    There is also a .lower.text section, which is located in FRAM, also as expected

    .lower.text        0x00000000000040c8                 0x0
                            0x00000000000040c8                           . = ALIGN (0x2)

    So just what is the .lowtext section, and what is directing GCC to try and locate ISR's there? 

    Regards - Andrew

  • Just before we delve a lot further, I just found the following under GCC's Bugzilla, 78838.

    Summary: 

    msp430 option -mcode-region=either, -ffunction-sections, and interrupt function attributes cause incorrect section to be created

    Text: 

    On the msp430 target, when using -mcode-region with -ffunction-sections (as is semi-suggested by the documentation), any functions which are marked with the interrupt attribute and which also specify an interrupt number are placed into an incorrect section ".either.lowtext", which is clearly nonsensical.

    This was back in 2016, and supposedly resolved. It's not exactly my situation (I'm actually using mcode-region=none, but it sounds like much the same combination of triggers). Its nothing specific to the FR processors though, and the same logic (and options) built fine for the non-FR processors. I'll keep searching!

    Andrew

  • and the following  (hopefully the link comes through fine, but just in case its TI title is 

    MSP430-GCC-OPENSOURCE: GCC 9.2.0.50 msp430fr5994.ld .lowtext bugfix""

  • Looks like its a known GCC problem with this group of processors as at GCC 9.2.0.50. The referenced TI thread includes a workaround patch to the linkers .ld, so I'll go ahead and apply that, and hopefully we will be running again.

    I'll do this now, verify all is OK, then close this.

    Andrew

  • Just closing this off. Applied the linker patch as described in the attached, and ISR's are now back in ROM and working as expected.

    Thanks for the help - Andrew

**Attention** This is a public forum