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.

Potential conflict with _lock.h and intrinsics.h on definition of _nop()

Hello TI insiders,

I would like to report a potential issue that may cause a lot of confusion to some people (and it took me a bit of time scratching my head).

I got the following error while building the project 430BOOST-SHARP96_GrlibExample_FR5969 (from here).

"C:/ti/ccsv6/tools/compiler/ti-cgt-msp430_4.4.0/include/_lock.h", line 48: error #56-D: too many arguments in invocation of macro "_nop"

I find that the error was fixed if I just added #ifndef block  to code in _lock.h as...

#ifndef _nop
_CODE_ACCESS void _nop(void);
#endif

(Normally changing any code that came with the compiler is a no-no for me too.  In this case, I do not have much of a choice.)

The intrinsics.h (the other file involved in this conflict) was also in the ti-cgt-msp430_4.4.0/include folder.  I am pretty sure I have the latest version of everything. 

If there is a better way to resolve this, please post your solution.  I am sure someone will need this as well.

Thanks!

NOTE: SLAC645 link updated by MikeS to latest on 20-Jul-2015


For future reference, this is the content of main.pp (preprocessor output).

main.obj: ../main.c
main.obj: F:/~Workspaces/CCSv6/MSP430FR59/Play-0000/430BOOST-SHARP96_GrlibExample_FR5969/driverlib/MSP430FR5xx_6xx/inc/hw_memmap.h
main.obj: C:/ti/ccsv6/ccs_base/msp430/include/msp430.h
main.obj: C:/ti/ccsv6/ccs_base/msp430/include/msp430fr5969.h
main.obj: C:/ti/ccsv6/ccs_base/msp430/include/in430.h
main.obj: C:/ti/ccsv6/tools/compiler/ti-cgt-msp430_4.4.0/include/intrinsics.h
main.obj: C:/ti/ccsv6/tools/compiler/ti-cgt-msp430_4.4.0/include/intrinsics_legacy_undefs.h
main.obj: F:/~Workspaces/CCSv6/MSP430FR59/Play-0000/430BOOST-SHARP96_GrlibExample_FR5969/grlib/grlib.h
main.obj: C:/ti/ccsv6/tools/compiler/ti-cgt-msp430_4.4.0/include/assert.h
main.obj: C:/ti/ccsv6/tools/compiler/ti-cgt-msp430_4.4.0/include/linkage.h
main.obj: F:/~Workspaces/CCSv6/MSP430FR59/Play-0000/430BOOST-SHARP96_GrlibExample_FR5969/LcdDriver/Sharp96x96.h
main.obj: F:/~Workspaces/CCSv6/MSP430FR59/Play-0000/430BOOST-SHARP96_GrlibExample_FR5969/LcdDriver/HAL_MSP-EXP430FR5969_Sharp96x96.h
main.obj: F:/~Workspaces/CCSv6/MSP430FR59/Play-0000/430BOOST-SHARP96_GrlibExample_FR5969/images/images.h
main.obj: ../driverlibHeaders.h
main.obj: F:/~Workspaces/CCSv6/MSP430FR59/Play-0000/430BOOST-SHARP96_GrlibExample_FR5969/driverlib/MSP430FR5xx_6xx/cs.h
main.obj: F:/~Workspaces/CCSv6/MSP430FR59/Play-0000/430BOOST-SHARP96_GrlibExample_FR5969/driverlib/MSP430FR5xx_6xx/inc/hw_regaccess.h
main.obj: C:/ti/ccsv6/tools/compiler/ti-cgt-msp430_4.4.0/include/stdint.h
main.obj: C:/ti/ccsv6/tools/compiler/ti-cgt-msp430_4.4.0/include/stdbool.h
main.obj: C:/ti/ccsv6/tools/compiler/ti-cgt-msp430_4.4.0/include/yvals.h
main.obj: C:/ti/ccsv6/tools/compiler/ti-cgt-msp430_4.4.0/include/stdarg.h
main.obj: C:/ti/ccsv6/tools/compiler/ti-cgt-msp430_4.4.0/include/_lock.h
main.obj: F:/~Workspaces/CCSv6/MSP430FR59/Play-0000/430BOOST-SHARP96_GrlibExample_FR5969/driverlib/MSP430FR5xx_6xx/timer_a.h
main.obj: F:/~Workspaces/CCSv6/MSP430FR59/Play-0000/430BOOST-SHARP96_GrlibExample_FR5969/driverlib/MSP430FR5xx_6xx/gpio.h
main.obj: F:/~Workspaces/CCSv6/MSP430FR59/Play-0000/430BOOST-SHARP96_GrlibExample_FR5969/driverlib/MSP430FR5xx_6xx/wdt_a.h
main.obj: F:/~Workspaces/CCSv6/MSP430FR59/Play-0000/430BOOST-SHARP96_GrlibExample_FR5969/driverlib/MSP430FR5xx_6xx/eusci_b_spi.h
main.obj: F:/~Workspaces/CCSv6/MSP430FR59/Play-0000/430BOOST-SHARP96_GrlibExample_FR5969/driverlib/MSP430FR5xx_6xx/pmm.h

  • Interesting. The line you ifdef'd is a function declaration, declaring a function '_nop' with no parameters (void). However, there seems to be already a macro of this name defined, and the precompiler tries to expand _nop(void) while the macro _nop() doesn't want 'void' as parameter, as it takes no parameters.
    It seems that there is some conflict in the order things are included, maybe even a problem with including things inside an 'extern "C"' block.
    Including _lock.h before intrinsics.h should solve the problem.
    i don't recommend disabling things without exactly knowing why they are there at all. :)
  • quark said:
    I would like to report a potential issue that may cause a lot of confusion to some people (and it took me a bit of time scratching my head)...

    First of all I'd like to thank you for your post. I just hit this issue myself and remembering that I'd seen a thread about it recently saved me some head-scratching!

    I've started a thread on the TI compilers forum with some more detail on how this bug occurred and a suggested fix.

  • There are two known issues, SDSCM00051212 and SDSCM00051278, which cover this.

**Attention** This is a public forum