• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 81 subscribers
  • Views 2098 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.

C2000WARE: Issues on driverlib and device support

Disona
Genius 3050 points
Part Number: C2000WARE

Hello, everyone.

I'm migrating one of my projects to F28379D MCU. I've downloaded C2000ware with latest device support files and I'm trying to build a project, but I have some problems. I have workarounds for some, and for others - I dont. I've added almost all of the files from "...device_support/common/include", "...device_support/common/source", "...device_support/headers/include", "...device_support/headers/source", ".../driverlib/source", "..driverlib/include". Yes, I prefer to use sources of the driverlib instead of a prebuild library. Here are the issues I've found this far:

1. Driverlib "usb.c" can't be built because of missing "inc/hw_usb.h". The missing header can be found in the "deprecated" folder, but... it's deprecated. So I've just excluded "usb.c" from build.
2. Badly formed pragmas for code_section in case of "Treat C files as C++ files" option. I had to redefine pragmas in "driverlib/flash.c", "driverlib/flash.h" and "device_support/common/F28037xD_Ipc_Driver.c" with "ifdef __cplusplus .... #endif"
3. "device.c" can't be build because of undeclared "memcpy()" function in case of using flash memory. I've added "#include "string.h"" to avoid this.

Is there a special way to report such problems?

  • 0
    TI__Mastermind 30255 points
    Disona

    This forum is the place to report it, so you're in the right place!

    1. Yes, this is known and we are removing the usb.c for now. The usb library to use in under libraries. For a usb driver currently, use the one under deprecated for now.
    2. Please provide more details on what you are referring regarding the pragmas
    3. You're likely missing a header/include that pulls in the functions from the compiler. We don't have any build issues with this file.

    Best regards
    Chris
  • 0 in reply to Christopher Chiarella
    Genius 3050 points

    Thanks for your help.

    Details on part 2: in file "c2000/driverlib/f28037xD/driverlib/flash.h", some functions are placed into ".TI.ramfuncs":

    #pragma CODE_SECTION(Flash_setBankPowerMode, ".TI.ramfunc");
#pragma CODE_SECTION(Flash_setPumpPowerMode, ".TI.ramfunc");
#pragma CODE_SECTION(Flash_disableCache, ".TI.ramfunc");
#pragma CODE_SECTION(Flash_disablePrefetch, ".TI.ramfunc");
#pragma CODE_SECTION(Flash_setWaitstates, ".TI.ramfunc");
#pragma CODE_SECTION(Flash_enableCache, ".TI.ramfunc");
#pragma CODE_SECTION(Flash_enablePrefetch, ".TI.ramfunc");
#pragma CODE_SECTION(Flash_enableECC, ".TI.ramfunc");

    But for function "Treat C as C++ files" i had to rewrite it like this (before each function declaration):

    #ifdef __cplusplus
#pragma CODE_SECTION(".TI.ramfunc");
#endif

    The same thing in "flash.c"

    About case 3: this problem only occures, when option "Treat C as Cpp files" is on. When it's off, "memcpy()" is somehow known to the compiler. But when it's on, i had to include "string.h". Teh compiler is v17.6.0 STS, CCS version is 7.2.0

    I've attached example project with this issue.memcpyFail.zipSTS.

  • 0 in reply to Disona
    TI__Mastermind 30255 points
    Disona

    Ok, I'll put in issues for #2 and #3 to improve our C++ compatibility.

    Syncing with our compiler experts, the reason string.h works is because it is pulling in the std namespace for memcpy. You can change that out for "using std::memcpy;" to get rid of the memcpy issue.

    Best regards
    Chris
  • 0 in reply to Christopher Chiarella
    Genius 3050 points

    OK, thank you, Christopher!