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.

RTOS/EVMK2H: I can't read a 0xff byte over the UART

Part Number: EVMK2H

Tool/software: TI-RTOS

Hi Yordan,

How is the status of the RTOS team? As I am faced with the same problem, please let me know if you have any solution for this problem.

> Yordan Kovachev Yordan Kovachev

> May 31, 2018 6:30 AM

> In reply to HWAYOUNG LEE:

>

> Hi,

>

> I've notified the RTOS team. They will post their feedback directly here.

>

> Best regards,

> Yordan

Best regards,

Takashi

  • Hi Takashi,

    Sorry, I've escalated this. The team must have been overloaded with other priority tasks.
    It is being looked at.

    Best Regards,
    Yordan
  • Hi Yordan,

    Thank you for your attention. A member of our project found that the following code cannot distinguish between the error code(-1) and 0xff data.

    "C:\ti\pdk_am57xx_1_0_10\packages\ti\csl\src\ip\uart\V1\priv\uart.c"

    967 int8_t UARTCharGetNonBlocking(uint32_t baseAddr)
    968 {
    969     uint32_t lcrRegValue = 0;
    970     int8_t   retVal      = -((int8_t) 1);
    971
    972     /* Switching to Register Operational Mode of operation. */
    973     lcrRegValue = UARTRegConfigModeEnable(baseAddr, UART_REG_OPERATIONAL_MODE);
    974
    975     /* Checking if the RX FIFO(or RHR) has atleast one byte of data. */
    976     if ((uint32_t) UART_LSR_RX_FIFO_E_RX_FIFO_E_VALUE_0 !=
    977         (HW_RD_REG32(baseAddr + UART_LSR) &
    978          UART_LSR_RX_FIFO_E_MASK))
    979     {
    980         uint32_t tempRetVal = HW_RD_REG32(baseAddr + UART_RHR);
    981         retVal = ((int8_t) tempRetVal);
    982     }
    983
    984     /* Restoring the value of LCR. */
    985     HW_WR_REG32(baseAddr + UART_LCR, lcrRegValue);
    986
    987     return retVal;
    988 }

    Best regards,

    Takashi

  • Takashi-san,

    Can you please indicate what is the configuration Params and the HWAttr used in your application. You should not see this issue if you have the UART paramters configured as

    uartParams.readDataMode = UART_DATA_BINARY; // do not handle CRLF Default UART_DATA_TEXT
    uartParams.writeDataMode = UART_DATA_BINARY; // do not handle CRLF
    uartParams.readReturnMode = UART_RETURN_FULL;

    Can you confirm if that it the case.

    Regards,
    Rahul
  • Hi Prabhu-san,

    Thank you for your reply. We set the UART parameters as follows:

    params.readDataMode = UART_DataMode::UART_DATA_BINARY;
    params.writeDataMode = UART_DataMode::UART_DATA_BINARY;
    params.readReturnMode = UART_ReturnMode::UART_RETURN_FULL;
    params.readEcho = UART_Echo::UART_ECHO_OFF;

    Therefore, we cannot find any difference from your parameters in your previous reply. In addition, we found that UART_v1_readData() in UART_vi.c is always calling UARTCharGetNonBlocking() regardless of the above parameters.

    That's why, we think that the UARTCharGetNonBlocking() does not have enough I/F to return the read data with 8-bit and the error code by a return value with int8_t.

    Best regards,

    Takashi

  • Hi Prabhu-san,

    As I would like to decide how to deal with the problem, could you tell me about the current status?

    Best regards,
    Takashi
  • Hello Rahul

    no, issue is still when I set as it. In current platform, many guys block here, please give complete solution.

    Br
    Leonard
  • issue is still
  • Have you fix this issue>? any suggestion? thank you.
  • Leonard,

    Yes, I acknowledge the observation UART_charGetNonBlocking_v0 in CSL doesn`t seem to be distinguishing between 0xFF and -1 which seems to be causing this issue in the driver.

    The temporary workaround would be to remove the code in the driver that checks if the return value is (-1) but this is being discussed with the driver developer to separate out the error code and the read value and not merge the two in the implementation.

    Regards,
    Rahul
  • Rahul

    I'm glad to hear you, could you show me the details of workaround without other errors, I have to implemented it now, it's urgent for us. I mean give the actually source code update.
    BTW when your driver developer has the solution for this issue?

    Leonard
  • Leonard,

    I have filed the bug ID for the issue  which is PRSDK-4529. Our development team is reviewing this so I don`t have a timeline when the fix will be available in the driver.  This issue occurs because UART_charGetNonBlocking CSL function doesn`t distinguish between -1 and 0xFF  so in the UART_v0.c or UART_v1.c , locate the CSL function call UART_charGetNonBlocking or UART_charGetNonBlocking_v0  and remove detection of -1 as a error condition.

    For example  in UART_v0_readData function or UART_v1_readData:

    readIn = (int32_t)UART_charGetNonBlocking_v0(hwAttrs->baseAddr);

       /* Receive chars until empty or done. */

       while ((size != (int32_t)(0)) &&

              (readIn != (-((int32_t)1))))

    After you make the updates, rebuild the UART driver and test your code to confirm that it receives 0xff.

    Regards,

    Rahul

  • Rahul

    I have tried above updating to test, but when I call API UART_read, always and continuously get 0xFF even though PC has not sent 0xFF. please check and give an available  workaround, thanks.

    Leonard

  • Hello Rahul

    Is there any update? we need your help, thank you.

    Leonard
  • We are discussing either create a new API or modify existing API to address this issue from:

    int8_t UART_charGetNonBlocking_v0(uint32_t baseAdd)

    to:

    int32_t UART_charGetNonBlocking_v0(uint32_t baseAdd)


    We will address this issue in 5.2 release by the end of this year.