• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 3283 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CCS/SIMPLELINK-CC2640R2-SDK: Porting to new 1.40 SDK produces incompatible wchar_t warnings

Alan Ross
Prodigy 90 points
Part Number: SIMPLELINK-CC2640R2-SDK
Other Parts Discussed in Thread: CC2640, SYSBIOS

Tool/software: Code Composer Studio

Was using 1.35 SDK for the CC2640R2 and trying to change to use newer 1.40.00.45.

After changing project defs as I understand them, I get linker warnings such as:

warning #16032-D: object files have incompatible wchar_t types ("/home/arross/ti/simplelink_cc2640r2_sdk_1_40_00_45/source/ti/blestack/blelib/host/cc26xx_gap_xcxx.a<gap_centdevmgr.o>" = --wchar_t=32, "./Application/BLEBridge.obj" = --wchar_t=16)

I don't use wchars in the project (that I know of).

If I try to change the wchar_t size to 32 for the APP project, I get build errors for undefined symbols - along with warnings such as:

warning #16032-D: object files have incompatible wchar_t types ("/home/arross/Bose/Professor/BLE/BLEBridge/CC2640/config/src/sysbios/rom_sysbios.aem3<rom_sysbios.obj>" = --wchar_t=16, "./Application/BLEBridge.obj" = --wchar_t=32).

Same code builds fine with SDK 1.35.

  • 0
    TI__Guru** 105180 points
    Hello Alan,

    Are you following the migration guide in the SDK 1.40? It looks like you may be keeping remnant libs from the earlier SDK. I would start with a clean SDK 1.40, then pull in your changes. Also, please ensure you are using the toolchain version specified in the SDK release notes.

    Best wishes
  • 0 in reply to JXS
    Expert 2690 points
    I'm having the same problem, and I think the correct libs are being pulled in. An example of what I'm seeing is:

    warning #16032-D: object files have incompatible wchar_t types ("C:\ti\simplelink_cc2640r2_sdk_1_40_00_45\source\ti\blestack\blelib\host\cc26xx_gap_xxxo.a<gap_centdevmgr.o>" = --wchar_t=32, "./Application/app/awpApp_BleBeaconReport.obj" = --wchar_t=16)


    and if I change our application to use wchar_t=32, the errors shift to something like this:

    warning #16032-D: object files have incompatible wchar_t types ("C:/ti/simplelink_cc2640r2_sdk_1_40_00_45/source/ti/devices/cc26x0r2/driverlib/bin/ccs/driverlib.lib<cpu.obj>" = --wchar_t=16, "./Application/app/awpApp_BleBeaconReport.obj" = --wchar_t=32)

    I think I followed the migration guide correctly (mostly just changing some stack include files), and I'm using the same toolchain versions as is specified in the release notes.
  • 0 in reply to Ed Ferrari SD
    Expert 2690 points
    OK, I see what's going on... I didn't catch that diagnostic 16032-D was added to the suppressed list of diagnostics in the example projectspecs. We're upgrading from 1.30.00.25, so I assume that release had the wchar_t setting set to 16 for the stack.
  • 0 in reply to Ed Ferrari SD
    TI__Guru** 105180 points
    Hey guys,

    Alight, I see what is going on. I didn't realize you are updating an old project vs. starting with a new project.

    You're right, Ed. The warning is suppressed since the libs were generated with IAR 8.11.x which changed the wchart_t size. None of the TI stack libs use wchar_t, but as far as we know, there is some metadata in the libs which trips up CCS. Hence the warning is benign.

    Best wishes
  • 0 in reply to JXS
    Prodigy 90 points

    The reason I asked the original question is because the code that runs fine on 1.35 no longer starts using 1.40.

    Upon call to BIOS_start() it just locks up. So wondered if the different char sizes in the libs was a problem.

  • 0 in reply to Alan Ross
    TI__Guru** 105180 points
    To be clear, wchar_t isn't used by the BLE stack, so I doubt that's the issue.

    Can you you try starting with a clean 1.40 project, then add in your changes? That should help confirm if it's a porting issue or a fundamental issue with your code.

    , did you get your app ported to 1.40?

    Best wishes
  • 0 in reply to JXS
    Expert 2690 points
    I had to put that task aside, although I should be able to resume tomorrow or early next week. I'll report back with my results.
  • 0 in reply to JXS
    Prodigy 90 points
    Thank you for the response, but I don't currently have time to start over from a "clean" 1.40 project and then import my development code. So I have reverted to the 1.35 SDK which works for me. Maybe when (if?) things calm down I can try again to migrate to 1.40.
  • 0 in reply to Ed Ferrari SD
    Expert 2690 points
    I just got done testing with the 1.40 stack and it seems to be working fine. The only "issue" we have is the size of the stack seems to have grown significantly versus the 1.30 stack. At first glance it seems to be because the ECC drivers are now not optimized out of the build, but we will need to dig further.
  • 0 in reply to Ed Ferrari SD
    Intellectual 540 points

    Hi all,

    Did you solve the problem with wchar? I have observed the same issue of Alan and I don't know how to solve it. It seems to be a problem of system libraries but I'm not sure.

    Thank you

    Moniaga

  • 0 in reply to moniaga
    Expert 2690 points
    Hi Moniaga,

    The wchar thing is not a problem, but a byproduct of the BLE libraries having been built with a newer version of IAR. The solution is simply to add diagnostic 16032-D to the list of suppressed linker diagnostics.

    -Ed