• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 253 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.

TMS320F28388D: CM SYS/BIOS and driverlib_cm

Arjan Oskam
Intellectual 510 points
Part Number: TMS320F28388D

Hello there,

I'm trying to use SYS/BIOS on the F28388D CM, together with the driverlib_cm library, but there seems to be a conflict.

When first building my application I got a linker error:

#10010 errors encountered during linking; "cm_app.out" not built	cm_app		 	C/C++ Problem
<a href="file:/C:/ti/ccs1100/ccs/tools/compiler/dmed/HTML/10234.html">#10234-D</a>  unresolved symbols remain	cm_app		 	C/C++ Problem
gmake: *** [all] Error 2	cm_app		 	C/C++ Problem
gmake[1]: *** [cm_app.out] Error 1	cm_app		 	C/C++ Problem
unresolved symbol vectorTableFlash, first referenced in ./device/cm.obj	cm_app		 	C/C++ Problem

Then I #define'd USE_RTOS so the vectorTableFlash section would not be defined in driverlib_cm/interrupt.c. But then I got compilation errors because vectorTableRAM and Interrupt_defaultHandler are still used in interrupt.h. And interrupt.h is always included in my driverlib_cm.h (which #include's all driverlib_cm *.h files).

#20 identifier "Interrupt_defaultHandler" is undefined	interrupt.h	/cm_app/device/driverlib_cm/driverlib_cm	line 463	C/C++ Problem
#20 identifier "vectorTableRAM" is undefined	interrupt.h	/cm_app/device/driverlib_cm/driverlib_cm	line 463	C/C++ Problem

Would it be OK to simply not include "interrupt.h"? Or disable/remove the Interrupt_unregisterHandler() function from interrupt.h? In general, which driverlib_cm functions should I NOT use when using SYS/BIOS?

It seems to me I should be able to use SYS/BIOS and driverlib_cm together in a CM application, however it looks like some of the driverlib_cm code is still missing a "ifndef USE_RTOS" condition. Am I correct?

Another question:
When using SYS/BIOS, do I still need to perform this line in my initialization code, or is it taken care of by SYS/BIOS?

memcpy(&RamfuncsRunStart, &RamfuncsLoadStart, (size_t)&RamfuncsLoadSize);

Thanks and kind regards,
Arjan

  • 0
    TI__Guru 53765 points

    SYS/BIOS should have equivalent functions in its Hwi module to cover everything in the DriverLib Interrupt module, so you shouldn't need it. I think Interrupt is the only one that you definitely should not use, but there are a few other potential conflicts to look out for. For example, you can use the timer functions in the DriverLib, but you need to make sure that SYS/BIOS isn't already using that timer instance for something (like Timer, Clock, or Timestamp). The Boot module also contains from Flash and PLL configuration options that may conflict with some DriverLib functions. You can use either method--just make sure you have removed the configurations/function calls for the whichever one you aren't using.

    You do still need to do the memcpy for ramfuncs in your code, yes.

    Whitney

  • 0 in reply to Whitney Dewey
    Intellectual 510 points

    Hi Whitney,

    Thanks for your reply. I'm using the driverlib_cm functions mostly for accessing interface peripherals like Ethernet, CAN and UART. So for example I would replace this call
      Interrupt_registerHandler( INT_UART0, &UART_ISR );
    with a call to Hwi_create(), correct?

    But in the driverlib functions there can also be 'hidden' access to the interrupt registers, like UART_enableInterrupt(). Will that present any conflict when using it with SYS/BIOS?

    I'm just a little apprehensive that I might unknowingly use a driverlib_cm function that messes up SYS/BIOS execution. Which is why I was hoping that the "USE_RTOS" definition would protect me from that.

    Kind regards,
    Arjan

  • +1 in reply to Arjan Oskam
    TI__Guru 53765 points
    Arjan Oskam said:
    I would replace this call
      Interrupt_registerHandler( INT_UART0, &UART_ISR );
    with a call to Hwi_create(), correct?

    Yes, exactly.

    Arjan Oskam said:
    But in the driverlib functions there can also be 'hidden' access to the interrupt registers, like UART_enableInterrupt(). Will that present any conflict when using it with SYS/BIOS?

    If you look at the code for UART_enableInterrupt(), it's only writing to the peripheral-level interrupt enable which is fine and necessary. It's mainly the NVIC and vector table functions that you need to look out for. You can double check the source code to be sure if you suspect a function may be doing this, but from what I've seen it's usually just the register/unregister functions (e.g. UART_registerInterrupt) that do this.

    Whitney

  • 0 in reply to Whitney Dewey
    Intellectual 510 points

    Thanks Whitney, will do that.

    Kind regards,
    Arjan