• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 672 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.

Problems with C6748 UART driver.

Vadim Khutorsky
Prodigy 20 points
Other Parts Discussed in Thread: OMAP-L138, OMAPL138

There are problems with the C6748 UART driver.

 

1) I run an UART example on EVM OMAP-L138 board (pspdrivers_02_10_01\packages\ti\psp\examples\evmOMAPL138\uart\sample). I modified an example to be able to send file from PC to the EVM OMAPL138 board through the serial port repeatedly. So the startUartSample() task is running on the loop. The sent message can be repeatedly read if the length (len) of the buffer specified in the Stream_read function is exactly equal to the length of the message sent. If message is shorter than the len Stream_read doesn’t return. If message is longer than the len then the first time Stream_read returns but the second time application is terminated with the message on the Console:

 

ti.sdo.io.Stream: line 482: Generic Failure

xdc.runtime.Error.raise: terminating execution

 

2) If instead of the BIOS_WAIT_FOREVER in Stream_read function timeout is specified, like 1000000 (1 sec), then application is terminated with the message on the Console:

ti.sdo.io.Stream: line 442: E_timeout: Timeout

xdc.runtime.Error.raise: terminating execution

 

Can anybody help with these problems?

 

Thaks

  • 0
    TI__Expert 5500 points

    Hi Vadim,

    Stream_read() is a synchronous call(blocking). So, unless the number of bytes mentioned('len') is not transferred, it waits. If you transfer lesser number of bytes(compared to bytes mentioned 'len') it waits for the remaining bytes. 'The BIOS_WAIT_FOREVER' makes it wait forever.For more details on stream_read() and stream_write() calls, please refer BIOS User Guide.

    Vadim Khutorsky said:
    If instead of the BIOS_WAIT_FOREVER in Stream_read function timeout is specified, like 1000000 (1 sec), then application is terminated with the message on the Console:
    ti.sdo.io.Stream: line 442: E_timeout: Timeout
    xdc.runtime.Error.raise: terminating execution

    Why you might face this error is because, for 'BIOS_WAIT_FOREVER' it blocks the call forever. Whereas, if 1000000 (1 sec) is given then as soon as the call is made a counter starts and counts till '1000000' and if within this time still the remaining data is not sent then it times out with a error message. This a stream level error.

    Vadim Khutorsky said:
    If message is longer than the len then the first time Stream_read returns but the second time application is terminated with the message on the Console:
     
    ti.sdo.io.Stream: line 482: Generic Failure
    xdc.runtime.Error.raise: terminating execution

    Since the startUartSample() task is running in a loop, and the message sent is longer than the len(Bytes transferred > len) the first read will read the 'len' number of bytes and return successfully. But the second read, might face overrun errors or receive line status errors, which are then updated in the driver and a 'IOM_EBADIO'(-1) is returned. A 'IOM_EBADIO' is a error code which signifies a generic failure. You can also check for the type of error triggered by probing into the driver. This can help you understand the actual problem.

    To avoid such errors, the IO transactions should be made with the number of bytes mentioned before transactions.
    Please refer the BIOS User Guide which comes with the BIOS. You can also refer to the BIOSPSP Userguide for details regarding the UART driver.

    Hope this answers your questions and help you solve the issue.

     

    Thanks & regards,
    Raghavendra

     

  • 0 in reply to Raghavendra Maddikery
    Prodigy 20 points

    There is another problem with the C6748 UART driver. If error raised in Stream_read() function how it could be cleared? Even If the correct length of data is sent after that the return length is always 0. Even when the Stream_abort() function is called.

    Thanks,

    Vadim.

     

  • 0 in reply to Vadim Khutorsky
    TI__Expert 5500 points

    Hi Vadim,

    You just have to recover from the error, and then can proceed further to perform the next transaction.  Stream_abort() would not help you to recover from the error. This is because, when an error is raised we may not know the state of the UART, and the IOP may not be updated appropriately. An error can trigger anytime with an error status returned to the application.

    To recover from the UART error, you need to call the following IOCTL's:

    "Uart_IOCTL_RESET_RX_FIFO"

    "Uart_IOCTL_CANCEL_CURRENT_IO" - Since, Stream_read() is a synchronous call you just need to cancel the current IO. 

    And then you will be able to make an IO transaction without any difficulties. Hope this helps and answers your questions.

    To get more details regrding this, and to get a better insight on the issue you can also refer to the following forum query:  http://e2e.ti.com/support/embedded/f/355/p/92463/321901.aspx#321901

    Thanks & regards,

    Raghavendra