CCS/PROCESSOR-SDK-AM437X: USART bug?

Part Number:PROCESSOR-SDK-AM437X

Tool/software: Code Composer Studio

Hi,

I'm using very old PDK (processor_sdk_rtos_am437x_3_03_00_04) but I compare code with the newest PDK (5.xx) and it seems that this part of code was not fixed yet.
Maybe I use APIs in the wrong way... but it looks like wrong API architecture. I didn't investigate if this is known issue or not.

I use UART_readPolling because in interrupt -  UART_read stay pended ...  UART_v1_hwiIntFxn never get called when I use UART3.

So I use Polling in BIN mode which call -> UART_charGet_v1 (why character in BIN MODE?) -> UARTCharGetNonBlocking (usart.c)

I think is bug in UARTCharGetNonBlocking:

int8_t UARTCharGetNonBlocking(uint32_t baseAddr)
{
    uint32_t lcrRegValue = 0;
    int8_t   retVal      = -((int8_t) 1);

    /* Switching to Register Operational Mode of operation. */
    lcrRegValue = UARTRegConfigModeEnable(baseAddr, UART_REG_OPERATIONAL_MODE);

    /* Checking if the RX FIFO(or RHR) has atleast one byte of data. */
    if ((uint32_t) UART_LSR_RX_FIFO_E_RX_FIFO_E_VALUE_0 !=
        (HW_RD_REG32(baseAddr + UART_LSR) &
         UART_LSR_RX_FIFO_E_MASK))
    {
        uint32_t tempRetVal = HW_RD_REG32(baseAddr + UART_RHR);
        retVal = ((int8_t) tempRetVal);
    }

    /* Restoring the value of LCR. */
    HW_WR_REG32(baseAddr + UART_LCR, lcrRegValue);

    return retVal;
}

If byte 0xFF is recv. from UART communication line it is interpreted as int8_t -1 !!!!
And function thinks that there is no char in FIFO.

Did I interpret/use API in the wrong way?