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

RTOS/TMDXICE110: UART0 does not read 0xFF

Samuele Demicheli
Prodigy 100 points
Part Number: TMDXICE110


Tool/software: TI-RTOS

Dear RTOS team,

I am writing an application for this platform that awaits for a byte of data from the UART0

interface and have noticed that if this received byte contains the hex numeric value 0xFF (dec 255)

the software does not trigger the callback (up to 0xFE it works).

Moreover the next time the software tries to read data from this interfacethe read value is wrong.

I have checked the input from the computer with an oscilloscope and the value of the received byte should be ok.

The UART parameters I am using are the following:

UART_Params_init(&uartParams);
uartParams.readMode = UART_MODE_CALLBACK;
uartParams.writeMode = UART_MODE_BLOCKING;
uartParams.readEcho = UART_ECHO_OFF;
uartParams.readDataMode = UART_DATA_BINARY;
uartParams.writeDataMode = UART_DATA_BINARY;
uartParams.dataLength = UART_LEN_8;
uartParams.readReturnMode = UART_RETURN_FULL;
uartParams.baudRate = 115200; /* Tried also 9600 with same result */
uartParams.parityType = UART_PAR_NONE;

And the reading is performed by calling:

UART_read(uartHandle, uartBuffer, sizeof(uartBuffer)); /* uartBuffer is a char array of the size of the received message */

Is it possible to receive a full byte (0xFF) of data via UART or not?

If it is possible, what should I change in the program to achieve this?

Thank you and best regards,

Samuele

  • 0 in reply to Biser Gatchev-XID
    Prodigy 100 points

    Hi Biser,

    Thank you for the quick response. The proposed workaround did not work for me.

    I tried another approach:

    Since the problem arises from the fact that the UARTCharGetNonBlocking recognizes 0xFF as -1 and this should be a reserved return value,

    I modified the UARTCharGetNonBlocking function in both the csl uart.c and uart.h files to return a int16_t instead of an int8_t this way if it reads the value 0xFF it is not recognized as a -1.

    Then I had to modify the UART_charGet_v1 and UART_readCancelNoCB in the UART_v1.c file accordingly in order to account for the csl modification (since no other file appears to include the <csl_uart_path>/V1/uart.h file).

    This approach seems to work for me.

    Best Regards,

    Samuele

    P.S.: If you want I can list the modifications I did to the listed functions in another response.

  • 0 in reply to Samuele Demicheli
    TI__Guru** 116770 points
    Samuele,

    This is a known issue and was reported against the last version of the SDK. Thanks for sharing the fix as I believe that this work around should work. However the correct fix for this is to write the CSL uart.c function to separate out the error code from the read return value and update the driver with the new API change.

    Glad to know you have a work around working. Please list the modifications here so other who run into the same issue can benefit from the fix.

    Regards,
    Rahul