CCS/MSP430FG4618: Spurious "a NOP may be needed here..." warnings using_enable_interrupts() in GCC on MSP processors

Hi,

Are you able to provide a short snippet of C code that produces these warnings?

Thanks,

That would be too easy!

Just gone and reduced this to some minimal code, and of course it works perfectly. What a surprise. With this minimal code I can turn the warnings off and on by switching between _enable_interrupts() and the raw eint as expected.

The warnings all follow the following form;

C:\Users\Andrew\AppData\Local\Temp\ccwZeFhA.s: Assembler messages:
C:\Users\Andrew\AppData\Local\Temp\ccwZeFhA.s:48: Warning: a NOP might be needed here, before an interrupt enable instruction

I've been trying to trap the intermediate assembler listing to have a peek in there, but it all seems to be cleaned up, either by GCC or CCS, and haven't found a way to retain it. I've been using the -S option on the compiler, which 'should' retain the assembler listing, but I suspect CCS is removing this in any case, as I've not been able to capture one. Any ideas on how to retain the generated assembler file? Any other ideas for getting a handle on what is happening? That would at least give us a indication on whether the NOP's are being inserted or not (I'm guessing not?).

(Actually just had another thought, which is to actually run the code with an assembler window open in CCS. Haven't done this for years, and currently don't have an MSP set up to do it, but give me a couple of days...)

Thanks and regards

Andrew

Andrew McLaren said:

I've been trying to trap the intermediate assembler listing to have a peek in there, but it all seems to be cleaned up, either by GCC or CCS, and haven't found a way to retain it. I've been using the -S option on the compiler, which 'should' retain the assembler listing, but I suspect CCS is removing this in any case, as I've not been able to capture one. Any ideas on how to retain the generated assembler file? Any other ideas for getting a handle on what is happening? That would at least give us a indication on whether the NOP's are being inserted or not (I'm guessing not?).

(Actually just had another thought, which is to actually run the code with an assembler window open in CCS. Haven't done this for years, and currently don't have an MSP set up to do it, but give me a couple of days...)

The "--save-temps" option is what you're looking for. I added this option to "Miscellaneous C source specific flags" in Project Properties>Build>GNU Compiler>Miscellaneous. GCC will now retain some useful files in the build directory. I think it would be useful to have a specific check box for this option in the project properties dialog. I'll work with TI to see if we can add this.

The "*.i" file is the preprocessed C source. This is useful if you want to extract a testcase without also having to provide supporting header files. All definitions and declarations needed to compile that file will be in the ".i", it's just a matter of reducing that to a smaller test case.

The "*.s" file is the assembler code we can inspect to see where the NOP warnings are being triggered.

Regards,

Thanks for the pointer Jozef.

I can see what is happening, but haven't a clue why. I'll put in a dump of the appropriate bits of the .c, the .i and the .s, together with the compiler command and the warnings generated.

First the C within the library routine

_disable_interrupts ();
status = EVT_RaiseInterruptEvent(vector, flags, evt_context);
_enable_interrupts ();

And the preprocessed C (the .i)

__asm__ __volatile__ ("dint { nop");
status = EVT_RaiseInterruptEvent(vector, flags, evt_context);
__asm__ __volatile__ ("eint");

The generated assembler - not surprising without any nop's around the eint

dint { nop
; Removed the assembler implementing the call
eint

The compiler command and output;

Invoking: GNU Compiler

"C:/ti/ccs910/ccs/tools/compiler/msp430-gcc-8.3.0.16_win32/bin/msp430-elf-gcc-8.3.0.exe" -c -mmcu=msp430fg4618 -mhwmult=none -I"C:/Data/Projects/Software/Micro/Common" -I"C:/ti/ccs910/ccs/tools/compiler/msp430-gcc-8.3.0.16_win32/msp430-elf/include" -I"C:/ti/ccs910/ccs/ccs_base/msp430/include_gcc" -O0 -g -gdwarf-3 -gstrict-dwarf -Wall -mlarge -save-temps -mcode-region=none -mdata-region=none -MMD -MP -MF"trunk/EVT_EventHandler.d" -MT"trunk/EVT_EventHandler.o" -o"trunk/EVT_EventHandler.o" "../trunk/EVT_EventHandler.c"

EVT_EventHandler.s: Assembler messages:
EVT_EventHandler.s:264: Warning: a NOP might be needed here, before an interrupt enable instruction
EVT_EventHandler.s:267: Warning: a NOP might be needed here, after an interrupt enable instruction
Finished building: "../trunk/EVT_EventHandler.c"

Just for comparison, I did the same sequence with a bit of dummy code - this generates an executable rather than a library, but don't think that should affect anything.

First the C - just threw a loop between the enable and disable.

_disable_interrupts ();
while (ctr < 10) {ctr++;}
_enable_interrupts ();

And the preprocessed C (the .i)

__asm__ __volatile__ ("dint { nop");
while (ctr < 10) {ctr++;}
__asm__ __volatile__ ("nop { eint { nop");

The generated assembler

; 17 "../trunk/NOP_Test.c" 1
dint { nop
; Removed the stuff in the middle
; 19 "../trunk/NOP_Test.c" 1
nop { eint { nop

The compiler command and output;

Invoking: GNU Compiler

"C:/ti/ccs910/ccs/tools/compiler/msp430-gcc-8.3.0.16_win32/bin/msp430-elf-gcc-8.3.0.exe" -c -mmcu=msp430fg4618 -mhwmult=none -I"C:/Data/Projects/Software/Micro/Common/trunk" -I"C:/Data/Projects/Software/Micro/Common_Tests" -I"C:/ti/ccs910/ccs/tools/compiler/msp430-gcc-8.3.0.16_win32/msp430-elf/include" -I"C:/ti/ccs910/ccs/ccs_base/msp430/include_gcc" -O0 -g -gdwarf-3 -gstrict-dwarf -Wall -mlarge -save-temps -mcode-region=none -mdata-region=none -MMD -MP -MF"trunk/NOP_Test.d" -MT"trunk/NOP_Test.o" -o"trunk/NOP_Test.o" "../trunk/NOP_Test.c"
Finished building: "../trunk/NOP_Test.c"

Its many years since I've touched assembler, but the style of the nop { eint { nop is a bit foreign to me. Are the intervening braces some sort of statement separator?

I did have a peek at the in430.h (where the _enable_interrupts macro is expanded), and interestingly, the nop { eint {nop sequence is only substituted for MSP430X and XV2, processors, otherwise its simply an eint. The dint { nop sequence is applied to all processors. Made me wonder if its failing to detect it''s compiling for a 430X, but nothing in the compile instruction looks wrong. Any ideas? For now I can simply add _no_operations around the _enable_interrupts, which should be safe.

Thanks and regards

Andrew