• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 84 subscribers
  • Views 160 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28379D: CCS

Mohammad Irfan
Prodigy 120 points

Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE

Tool/software:

Dear All,

I’m developing a TI C2000 F28379D application in Code Composer Studio that combines TI’s high-level DriverLib APIs with direct register writes for cycle-exact control. To preserve the ability to tweak the startup and device support files, I imported source, header and required cmd files from devicesupport folder into my project and added both that folder and the DriverLib include directory under Project → Properties → C2000 Compiler → Include Options.

I imported the C2000Ware `device` folder (containing `device.c`, `device.h` and `F2837xD_CodeStartBranch.asm`) into my project and added both that folder and the DriverLib include directory under **Project → Properties → C2000 Compiler → Include Options**.

During an initial build of the TI's CAN transmit example (can_ex3_external_transmit), i imported the device folder as it is in the example folder. I saw multiple-definition linker errors (e.g. symbols in my copied `device.c`/`.h` conflicting with those in DriverLib). To clear these, I removed the extra `device` directory and instead added `driverlib.lib` to Project → Properties → C2000 Linker → File Search Path, which restored a clean build.

My goal is to continue using DriverLib for standard CAN, ADC and ePWM setup, while falling back to register-level code for timing-critical routines. Could you please confirm whether this project structure—mixing DriverLib and register-access on the F28379D—works reliably, or if there’s a TI-recommended best practice or template I should follow to avoid conflicts and maintain a clean build?

Any best-practice templates or guidance would be greatly appreciated.

Thank you for your assistance.

Best regards,
Sameer Irfan

  • 0
    TI__Mastermind 21840 points

    Hi Sameer,

    I have looped in the expert from the team, please allow them 1-2 days to respond.

    Best Regards,

    Delaney

  • 0 in reply to Delaney Woodward
    Prodigy 120 points

    Hi Delaney, 

    Thanks a lot. 

    Best Regards,

    Sameer

  • +1 in reply to Mohammad Irfan
    TI__Mastermind 20421 points

    Hi Mohammad,

    It is fine to mix the DriverLib and direct register code in the same project, this is something that is quite common. It's probably not showcased in our simple software examples but is commonly done in our system-level reference design examples. A good practice is to keep the driverlib.lib in your project so that the DriverLib functions can be referenced by the compiler but keep a driverlib folder that is excluded from the build. This is so you are able to reference the DriverLib source files throughout your development to understand what each of the DriverLib functions are doing.

    Another good practice is to create a higher level HAL source file which abstracts the DriverLib / direct register writes into system-level functions which you call from your main or control loops. This creates cleaner, easier to read code and helps with maintaining and debugging code

    Regards,

    Peter

  • 0 in reply to Peter Luong
    Prodigy 120 points

    Hi Peter, 

    Thanks for your nuanced and detailed explanation.

    Best Regards,

    Mohammad Sameer Irfan