• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 2572 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.

F28377 SCI Rx FIFO interrupt Timeout

shuen jan hsu
Intellectual 340 points

Hi,

I'm deal with the SCI communication in F28377, and find out there isn't have receive FIFO timeout in this mcu.

Thus i need to use extra timer (like cputimer1) to implement timeout.

However there is a problem, if use two sci channel (scia & scib) for communication purpose.

Does that means i need to use two timer (cputimer1 & 2) for each sci?

If the answer is YES, then how can i avoid this problem?

Because i also need one timer to do another thing not just for sci communication.

 

  • 0
    TI__Mastermind 42195 points

    Shuen,

    can you explain to me what is a "have receive FIFO timeout", and why you need it? Maybe we can find you a solution.


    Regards,
    Cody

  • 0 in reply to Cody Watkins
    Intellectual 340 points

    I'm using the Rx FIFO without timeout, and set the threshold RXFFIL = 8(every 8 bytes data cause interrupt and extract it).

    Nevertheless, during the transmit period MCU get the dummy data (eg. 2 bytes data), so the Rx FIFO will receive total 10 bytes data.

    Therefore, those dummy data will cause MCU extract the wrong 8 bytes data every interrupt after first Rx interrupt.

  • 0
    Intellectual 340 points
    Could somebody give me any suggestion?
    Thanks!
  • 0 in reply to shuen jan hsu
    TI__Mastermind 42195 points

    Shuen,

    1.Do I read your diagram from left to right? or from right to left?

    1.1 To me it looks like the dummy data occurs at the end of the first RX interrupt, is this correct?

    2 When does the dummy data occur? Is it only transmitted once?

    I don't know the exact details of your system, but you should configure the device to capture the dummy data and the real data, then throw the dummy data away.

    Regards,
    Cody

  • 0 in reply to Cody Watkins
    Intellectual 340 points
    Cody,
    1.
    It is read from left to right.

    1.1
    Yes. For this example the dummy data come after the 8 bytes data.

    2.
    The dummy data may occur anytime anywhere ( before the data or inside the 8 bytes data ) not just after my transmit data.
    It might be caused by environmental noise where has high power device ( 100kW or more) surrounded.
    If sci communication doesn't have time axis (Rx FIFO interrupt is fired by quantity of receive data ), it can't identify the period of a legal transmission.
    And the dummy data left by previous transmission will affect the next transmission to extract the wrong data.

    It is necessary for me to explain my communication roughly. SCI is implemented by the MODBUS protocol, and slave need the right 8 bytes command data from master to do the data write (06) or data read(03) at certain address.
  • 0 in reply to shuen jan hsu
    TI__Mastermind 42195 points

    Shuen,

    you will need to do some sort of handshaking between the devices because UART does not check for unexpected frames. This could be done many ways, you could add a checksum, or add start and end of communication frames, or if the data is more critical you could echoback the received frames and verify for correctness.

    When you detect some "dummy data" you can use "RXFIFORESET" bit, of the SCIFFRX register, to reset the RX FIFO. Clearing this bit will reset the RX FIFO, a full description can be found in the Technical Reference Manual.

    Also note that it is rare for random noise to 'look like' a UART frame. Often times noise appears as an error to find this you should check the RXERROR bit of SCIRXST. A full description of this can also be found in the Technical Reference Manual linked above.

    Regards,
    Cody

  • 0 in reply to Cody Watkins
    Intellectual 340 points
    Cody,

    when using the MODBUS protocol on my sci communication, i do use CRC to check every 8 bytes receive data right or not. It can't solve the problem in my case if the data is always wrong (CRC can't match), and then my sci communication will stuck in this loop.
    I try to set RXFIFORESET in RXFIFO interrupt if i receive the wrong data.

    SciaRegs.SCIFFRX.bit.RXFIFORESET = 0; // reset FIFO pointer to zero
    SciaRegs.SCIFFRX.bit.RXFIFORESET = 1; // Re-enable receive FIFO

    In my code i add these two setting when the receive CRC doesn't match with transmit one, and then i should clear the RXFIFO no matter how many data left in RXFIFO. However, these setting don't clear RXFIFO when it receives more than 8 bytes data, of course, RXFFST doesn't equal to zero.

    The RX FIFO Interrupt isn't good enough to deal with unexpected situation (if data less than or more than FFIL). I use counter to do receive data every same period (like polling) in my sci communication before. At least, I won't have to care about the data size are 10 bytes or 2 bytes. If timer times out, it will clear RXFIFO by extracting all data from RXFIFO and then check CRC is correct or not. The drawback of my method is that it have to check RXFFST every same period even though there don't have data received. This isn't efficient for mcu especially sci just a piece of my project. Anyway, i expected RX FIFO interrupt can improve my sci communication. It seems that it doesn't quite good for me to use in my sci communication.
  • 0 in reply to shuen jan hsu
    TI__Mastermind 42195 points

    Shuen,

    if you're concerned about the timer running when it is not needed you should start the timer after the first byte of data, and stop the timer after the CRC is received and matches. This will keep the timer from running while no data is being sent.

    Secondly, there are many ways to solve this synchronization issue, I would suggest that in the event of a CRC error you should have the F28377 handshake with the master causing a short dead time for both devices to clear buffers and resynchronize.

    You could also define a "Start of Transmission" frame from which you could determine where the CRC should be in the frames. Note: To use this method you would need to account for the possibility of data frames looking like start of transmission frames, but this only matters if you detect a CRC error.

    Hope it helps,
    Cody