• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 814 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.

Original question:

MSPM0G3507: ti_drivers_config.c not generated by sysconfig

MSPM0G1107: MSPM0 SDK (2.02.00.05) SysConfig support for FreeRTOS/TI-Drivers

Derrick
Intellectual 395 points
Part Number: MSPM0G1107
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

According to this thread 5 months ago, MSPM0G3507: ti_drivers_config.c not generated by sysconfig, SysConfig supports generation of ti_msp_dl_config.c/h which are required for DriverLib, but not ti_drivers_config.c/h which are required for TI-Drivers. This seems to be a huge hole in product functionality that's available on other TI microcontroller families.

Can we expect this to be supported in the near future? If not, can someone provide guidance on how to properly generate ti_drivers_config.c/h manually? Half the value in using a FreeRTOS implementation is in using TI-Drivers rather than DriverLib directly.

  • 0
    TI__Mastermind 26870 points

    Hi Derrick,

    I this won't be done for near future (won't be done by end of the year).

    For the ti_drivers_config.c/h, I would open the project that has the IPs (UART, ADC, I2C, etc.) you need. You can then copy and paste the files or alternatively you can drag the files from the Drivers example into the project you're making your application in.

    If you look at the FreeRTOS example the sysconfig generated files are the IP resets, power enable for the IPs, and clock initialization. Since sysconfig and TIDrivers are not fully linked for MSPM0, it might be easier to work with one of the Driver Examples only.

    Regards,
    Luke

  • 0 in reply to Luke Ledbetter
    Intellectual 395 points

    We'll consider that an option (modifying ti_drivers_config.c/h).

    Right now, we're looking at the alternative of rolling our own thread-safe drivers and interrupt handlers. In particular, I'm referencing the UART module from TI-Drivers to see if anything special is being done to write interrupt handlers that work with/do not interfere with FreeRTOS. I do not see anything in particular indicating that it needs to coordinate directly with the RTOS. It seems that the UARTMSP_interruptHandler function allows the NVIC to nest interrupts like normal, but I did notice some callouts for hardware interrupts to be disabled. In particular, the receive function is preceded by this comment:

    /*
 *  ======== UARTMSP_getRxData ========
 *  Must be called with HWI disabled.
 */
__STATIC_INLINE size_t UARTMSP_getRxData(UART_Handle handle, size_t size)
{
    UARTMSP_HWAttrs *hwAttrs           = UART_HWAttrs_Ptr(handle);
    UART_Object *uartObject            = UART_Obj_Ptr(handle);
    UART_Buffers_Object *buffersObject = UART_buffersObject(uartObject);

    size_t consumed = 0;
    uint8_t data;

    while (!(DL_UART_isRXFIFOEmpty(hwAttrs->regs)) && size)
    {
        data = DL_UART_receiveData(hwAttrs->regs);
        RingBuf_put(&buffersObject->rxBuf, data);
        ++consumed;
        --size;
    }
    return (consumed);
}

    This code is only referenced in this same file (it's called directly in UARTMSP_interruptHandler) and no where else. But, I do not see any calls to HwiP_disable anywhere. Is this a bug or an obsolete comment?

  • 0 in reply to Derrick
    TI__Mastermind 26870 points

    Hi Derrick,

    The code comment should be obsolete, as the UART data won't be overwritten by other UART processes due to this function getting called inside of the UART ISR.

    Regards,
    Luke