• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 83 subscribers
  • Views 161 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.

Original question:

TMS320F28379D: Request for details on SCI error handling

TMS320F28379D: TMS320F28379D

Leo Peters
Prodigy 45 points
Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE

Tool/software:

Hi,
After having used the sci.h, etc. from the C2000ware for some years now, I looked more deeply into the registers as I experienced some unexpected behavior.


First of all, I was very surprised to find out that SCI_readCharNonBlocking filters away the SCIFFPE and the SCIFFFE bits, which I find necessary to take into consideration after receiving data.
Consequently, I built my own function that takes the entire SCIRXBUF with which I now get the unexpected behavior, which is as follows:


After triggering the SCI break-detect flag (e.g., by providing a low signal for too many bits), I run SCI_performSoftwareReset. Afterwards, SCI_getRxStatus returns zero, which is expected as I assume that the SCI is now running normally again. However, the first byte, which is being received at the correct baud rate afterwards (in my case 12.5 Mbaud), has the SCIFFFE-bit set. Every following similar byte is working completely fine. It is just the first one after a reset, which was initiated to reset the break-detect flag. This behavior can be reproduced reliably.

Is there an explanation for this behavior and an easy work around?

Kind Regards,
Leo

  • 0
    TI__Mastermind 20970 points

    Hi Leo,

    The SCIFFFFE flag will go high if the top element in the FIFO being read has a framing error. A framing error basically means that the SCI receiver missed a stop bit where it expected it. My guess here is that the software reset is still taking place when the next valid data comes in. Have you checked the data read from the SCI RX BUF? Is the following data (with no framing error) correct, or does it seem shifted? You may need to have the transmitting device hold the line high for some time after the break detect to ensure the F2837xD SCI has time to reset.

    I will loop in the software expert to comment on the SCI_readCharNonBlocking() function. I believe in most cases the SCIRXST.FE bit is used instead (which goes high whenever any data received has a framing error) since it has an interrupt condition tied to it. 

    Best Regards,

    Delaney

  • 0 in reply to Delaney Woodward
    Prodigy 45 points

    Hi Delaney,

    thank you very much for your quick response. When troubleshooting the error, I made extra sure that there is sufficient time between all steps. The Rx-line is high at least one second before performing the reset and after the reset there is at least one second before sening the first byte followed by at least one second of delay and a the second byte. Both bytes are received correctly with respect to the SAR-Bits but the first byte has the SCIFFFFE-Bit set in the SCI RX BUF register.
    It appears as if the SCIFFFFE-Bit in the FIFO did not get reset properly or that there is some other hidden latching happening.

    The resulting issue is of course, that I cannot distinguish between a correct or faulty byte after the an error and the corresponding reset-procedure.

    If you want, I can provide some MWE to reproduce the issue on your side if this is how you want to proceed.

    Kind Regards,
    Leo

  • 0 in reply to Leo Peters
    TI__Mastermind 20970 points

    Hi Leo,

    It could also be that the framing error is leftover from the break detect signal, since the frame error checker will detect the beginning of the low signal as a start bit and be looking for a paired stop bit.

    It seems like the flag is being latched for some reason as you said. If you could provide some code, I can try to reproduce the error.

    Best Regards, 
    Delaney