TI_auto_init() problem mixing C++ and C files.

I doubt that --cpp_default is the issue here. The only thing that this option does is treat files with extension .c as if they had extension .cpp; if your program compiles, it's unlikely you need to mess with --cpp_default

I've got no idea why you would be having a problem with autoinit, there really isn't enough information here.

Try compiling with -O4, which does cross-file type checking, to see if there are any mismatches.

Did this project work previously, perhaps before you added the C files?

Yes the project work previously before I added the C files.

Without the --cpp_default option, the project doesn't compile, I'm forced to use it on several .C files and then they compile and build.

I've just tried the -O4 option, no change.
Which information could I give-you, do you want the project code itself ?

If you need the --cpp_default option to build a file, then that file is a C++ file, not a C file, despite the file extension.

I think I'd need to see the entire CCS project. Build the project such that the execution fails in auto init, then zip the whole thing up and sent it to me by private message. Click my user name to get to my profile; from there you can send a private message.

« If you need the --cpp_default option to build a file, then that file is a C++ file, not a C file, despite the file extension »

R: maybe this is not the option I'm talking about, this is this option I were refering:

Anyway, finally I've got the problem and you were right, it seems nothing related to this option. The problem was a singleton pattern stuff that I'd added along the .C files stuff. But I still don't know why it interferes with TI_autoInit(). The code change is:

There were many places I use GetInstance()-> and as I remove this stuff, it goes through TI_autoInit() no problem at all.

Thanks.

I'm glad you have the program working, but I still don't know what might have been the trouble.

It's possible that you might have interrupts enabled during auto initialization; the interrupt might fire before the global object has been constructed, which could cause problems in the interrupt, but shouldn't impact auto initialization itself. The "after" version of the code constructs the static instance "instance" on demand when it is needed; it might come before or after auto initialization without trouble.

I've performed a refinement of the test, and keep the same code but replace local static definition by a global, and the problem dissapear.
Maybe you can test this little code on your side if it causes problem on your setup.
Regards.