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.

[FAQ] What are the known issues of the AM335x/AM437x Processor SDK RTOS

I'm aware of the known issues of the latest RTOS SDK, as documented in the release notes. Are there any other known issues discovered after the latest release?

  • The known issues discovered up to the latest RTOS SDK release (6.3) were described in the Release Notes.

    Here we provide a list of known issues discovered after the 6.3 release, and the corresponding solutions/workarounds.

    1. CSL API CSL_rtcSetCompensationVal() not working


    CSL_rtcSetCompensationVal() is supposed to load the RTC compensation registers: RTCSS_COMP_LSB_REG and RTCSS_COMP_MSB_REG. However, it loads RTCSS_COMP_MSB_REG with the same value in RTCSS_COMP_LSB_REG. 

    This problem was caused by the wrong definition of macro CSL_RTC_COMP_MSB_RTC_COMP_MSB_SHIFT in csl\src\ip\rtc\V0\cslr_rtc.h:

    #define CSL_RTC_COMP_MSB_RTC_COMP_MSB_SHIFT ((uint32_t)(0U))



    #define CSL_RTC_COMP_MSB_RTC_COMP_MSB_SHIFT ((uint32_t)(8U))

    2. PDK example projects not building for bare-metal use case


    The CCS example projects in PDK are supposed to build for either TI-RTOS use case or bare-metal use case. However, the projects do not build for bare-metal use case. 

    For example, the following steps are needed to rebuild project GPIO_LedBlink_iceAMIC110_armTestProject for bare-metal:

    • remove USE_BIOS from compiler symbols in project settings
    • comment out task creation code in XDC config file am335x_app_iceamic110.cfg
      /* = Task.create("&gpio_test", task0Params); */
    • change Osal.osType to "nonos" in the same XDC config file
      Osal.osType = "nonos"

    With these changes, rebuilding the project has the following error:

    js: "C:/ti/pdk_am335x_1_0_17/packages/ti/osal/package.xs", line 70: Error: Soc is not defined


    Follow this FAQ to create PDK-based bare-metal application projects from scratch.

    3. PDK top level build scripts broken for Windows 10

    Rebuilding PDK from the top level makefile fails in Windows 10. Please refer to this E2E thread for details and the workaround.

    4. UART LLD race condition can occur when transfer size is small


    A race condition could occur in the UART LLD when transfer sizes are very small, as described below:

    1. A Tx transfer was started by the following line in function UART_write2_v1(): 

    object->writeSize = (size_t)UART_writeData_v1(handle, (int32_t)(transaction->count));

    Due to small transfer size of just 1 byte, the transfer was completed immediately and flag TXFIFO_EMPTY_STS in UART ISR2 was raised (this is a status bit, not an interrupt bit).

    2. Because the transfer was complete, the code also tried to enable interrupt EN_TXFIFO_EMPTY within the same function:

    object->txDataSent = TRUE;
    UARTInt2Enable(hwAttrs->baseAddr, UART_INT2_TX_EMPTY);  // set bit EN_TXFIFO_EMPTY in UART IER2 register

    3. A Rx HWI happened between the two lines above and the HWI ISR was entered to service the Rx HWI. Because the two conditions below in the ISR were both true, the ISR disabled interrupt EN_TXFIFO_EMPTY and set txDataSent to FALSE:

        if (object->txDataSent == TRUE)
            intType = UARTInt2StatusGet(hwAttrs->baseAddr);  // read bit TXFIFO_EMPTY_STS in UART ISR2 
            if ((intType & UART_INT2_TX_EMPTY) != 0U)
                UARTInt2Disable(hwAttrs->baseAddr, UART_INT2_TX_EMPTY);   // reset bit EN_TXFIFO_EMPTY in UART IER2
                UART_v1_callback(handle, (bool)false);
                object->writeTrans = NULL;
                object->txDataSent = FALSE;

    4. The HWI ISR returned to function UART_write2_v1(), which then called UARTInt2Enable() (second line in the code snippet in #2).

    5. The HWI ISR entered immediately because Tx FIFO was still empty and the interrupt line output was enabled by UARTInt2Enable() in #4. However, because txDataSent was already set to FALSE by the ISR when servicing the Rx HWI in #3, the ISR didn't call UARTInt2Disable() and set txDataSent to FALSE.

    6. After the HWI ISR returned, it immediately reentered because the interrupt EN_TXFIFO_EMPTY wasn't cleared. Then #5 and #6 repeated in an infinite loop.


    Add an additional check in the ISR to make sure txDataSent is set to FALSE only if the TX_EMPTY interrupt was enabled:

    if (  ((intType & UART_INT2_TX_EMPTY) != 0U)
                &&(HW_RD_REG32(baseAddr + UART_IER2) & UART_IER2_EN_TXFIFO_EMPTY_MASK) )
                UARTInt2Disable(hwAttrs->baseAddr, UART_INT2_TX_EMPTY);            /* Call back to application if in callback mode */
                UART_v1_callback(handle, (bool)false);
                object->writeTrans = NULL;
                object->txDataSent = FALSE;