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.

Compiler/CC2640R2F: Compiler complains of missing types "bStatus_t" and "uint8" when adding new files to project

Part Number: CC2640R2F
Other Parts Discussed in Thread: BLE-STACK

Tool/software: TI C/C++ Compiler

Hello everyone,

I am working on a project that requires more than one gatt_profile,and is based on the Simple BLE Peripheral example included with BLE-STACK 1.50. I modified the original simple_gatt_profile to hold some of my BLE characteristics and that worked just fine. I added new files to add a second profile (just copy/pasted versions of simple_gatt_profile .h/.c) and modified it to contain my characteristics, but am now getting odd compiler errors. The compiler complains that it can't find types such as "bStatus_t" and "uint8" in the header. 

I checked basic things like making sure my macro guards are correct, and that there aren't any duplicate types or names in either files, but am now stumped. My gut tells me that it's a link order thing, but I can't seem to figure out how the link order part of the preferences works. Do I add all the files in the project, and then manually attempt to re-order them?

I also tried (out of desperation) to just add the typedefs to the top of my second profile.h to see if I could fudge my way through it, but then the linker complains that my functions in my header don't exist.

I searched the forums to see if anyone else had similar issues, and found a couple similar posts, but none of the fixes I found worked.

Does anyone have any suggestions or pointers?

Thanks!

-Ben

  • I am not familiar with BLE STACK.  But I can shed some light.

    User defined types like bStatus_t and uint8 are always defined in header files (with very rare exceptions).  I presume you have searched all your source code and found the definition of these types.  The question then becomes: Why doesn't the compiler see these type definitions?

    That is usually due to some problem that occurs during preprocessing.  Some #define is set wrong, or a command line -D is missing, or something like that.  To debug problems like that, use the compiler option --gen_preprocessor_listing.  Please read more about that option in the ARM compiler manual.  It generates another file with the extension .rl, and you inspect that file to understand what occurred during preprocessing.  

    Thanks and regards,

    -George

  • Hi George,

    Thanks for the quick reply. 

    I added "--gen-preprocessor_listing" to the compiler options as you suggested, and it does generate .rl files for my source code. It shows "E" lines that correspond to the same lines that cause the the compiler errors related to "bStatus_t" and "uint8." However, I'm not sure what to do with this information? I still don't see where I can change the compile/link order.

    And also thanks for the link to the ARM Compiler manual. That will come in handy in the future.

    Any further suggestions I can try?

    Thanks,

    -Ben

  • You need to learn the simple format of the .rl file, and then do some detective work.  In this case, I suspect the lines which define the types bStatus_t and uint8 are being skipped.  In the .rl file, such lines start with S.  Find those lines, and work out why they have been skipped.

    Thanks and regards,

    -George

  • Hey again George,

    Thanks again for all the advice, but I was never able to solve my problem. I dug through the compiler manual, but just couldn't see where things were falling flat.

    Instead of dividing my BLE characteristics into 3 profiles, I've decided to just go back to one big profile and be done with it.

    Just wanted to post this in case anyone else runs into the same issue and attempts to solve it.
    -Ben
  • In the .rl file, you should be able to find out where things are getting skipped.  In my text editor, I would search for ^S.*bStatus_t .  This expression finds any line that starts with S and contains bStatus_t on it somewhere.  Once you find that, the surrounding context will have clues on why this line is skipped. It might be obvious, or you may have to search again for something else.

    I realize you have worked around this problem.  But I hope that, by showing a way to work the problem, you still see the value of using --gen_preprocessor_listing.

    Thanks and regards,

    -George