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

TMS320F2800154-Q1: LIN communication trigger interrupt issue

Angela Zou
Intellectual 1045 points
Part Number: TMS320F2800154-Q1


Hi experts,

Customer has a question about LIN communication. 

Whether the FE interrupt (frame error) will be triggered when the length of the received message does not match the length specified by SCIFORMAT -LENGTH? And also in this case, will the ID interrupt be triggered? Will the RX interrupt be triggered? Thank you.

  • 0
    TI__Mastermind 20145 points

    Hi Angela,

    I'm assuming you are asking about the LIN mode of the LIN module. Here are the answers to your questions:

    Since there are start/stop bits surrounding each byte of data sent by the LIN module for the ID field, data fields, and the checksum field, a framing error could occur on any of these bytes if a stop bit isn't detected when expected. When the LIN module is shifting in received data for each of these fields (after a sync break and sync field have previously been received), it will sequentially look for the line to be:

    1. low for one bit width amount of time (start bit)
    2. 8 (data) bit widths later: high for a bit width amount of time (stop bit) <- if at this point it doesn't see the line high, it will flag the framing error.

    If less bytes are received than are specified in the SCI FORMAT length field but they all still have proper start/data/stop bits, then no framing error would occur. If more bytes than expected are expected are received without a proper sync break and sync field, the data would be ignored and no framing error would occur.

    In the case of a framing error occurring for the ID field reception, the received ID won't be copied over from the RXSHF register to the RECEIVEDID field of the LINID register. So, no ID match interrupt could be triggered in this case since the LIN module won't see anything in RECEIVEDID to compare to IDSLAVETASKBYTE/IDBYTE.

    An RX interrupt would not be generated in the event of a framing error since the RXRDY flag will only get set once a full frame of non-errored data is received.

    Best Regards,

    Delaney

  • 0 in reply to Delaney Woodward
    TI__Intellectual 1045 points

    Hi Delaney,

    Let me explain the background of the issue.

    The issue is found during the LIN consistency testing, and the 3.8.3 test failed when using vector LIN slave conformance tester:

    3.8.3 Send only header, does not send data, response error bit should not be set, test result fail
    3.8.4 Send header, the data sends only one byte (current project standard is 2 bytes), response error bit should be set, test result pass

    During debugging, it was found that when the length of the received message does not match the length specified by SCIFORMAT -LENGTH, a FE interrupt (frame error) is triggered, and in this case, In addition, an ID interrupt is triggered and no RX interrupt is triggered.
    Because any inconsistency in data length will trigger an FE interrupt, they cannot recognize the differences between 3.8.3 and 3.8.4, and therefore cannot meet the requirements of the consistency test. So whether the issue is caused by our chip? How to solve this issue?

  • 0 in reply to Angela Zou
    TI__Mastermind 20145 points

    Hi Angela,

    I am consulting the other LIN expert to discuss this. Please expect a response on Wednesday.

    Best Regards,

    Delaney

  • 0 in reply to Delaney Woodward
    TI__Mastermind 20145 points

    Hi Angela,

    I apologize for the delay. I don't have much knowledge of the different LIN conformance tests, but below is my understanding of what they are trying to do. Let me know if I have anything incorrect. 

    The C2000 is set up as the responder and another device is set up as the commander. All of the errors/interrupts discussed are from the perspective of a responding node and will be raised/flagged on the responder c28x.

    In test 3.8.3:

    • Commander sends header data indicating that it wants a response from the responder, but no data is put on the line, meaning the line is idle the whole time (should not trigger FE).  Or is the data being sent 0 (but with proper start/stop bits - could trigger FE, but won't always necessarily, depends on if it is sent using proper timing)? 

    In test 3.8.4:

    • Commander sends header data indicating that it wants a response from the responder, data is put on the line, but not enough or too much data is put on the line, with proper start/stop bits - could trigger FE but won't always necessarily, depends on if it is sent using proper timing.

    They are looking for an interrupt flag (to be the "response error bit") that will differentiate between the responder sending back nothing vs. the responder sending back data of the incorrect length (meaning too many or too little data bytes), and they are not able to make this distinction with the FE. Is the assumption that the issue is being caused by a framing issue of the header ID byte for these tests? In other words, is the responder's incorrect/errored response due to a bug in its own code or due to the commander sending an errored ID byte?

    If my above understanding is correct, the FE should not be used to make this distinction or even to detect this type of issue. It sounds like an NRE (no response error) should be used to detect these issues; however, it wouldn't allow them to distinguish between the 3.8.3 and 3.8.4 to my knowledge. The FE should be used for detecting issues where noise is involved or there is some timing issue of the bits themselves, rather than detecting incorrect functionality of the LIN module or LIN application code.

    Please confirm my understanding and then I will look into a solution.

    Best Regards,

    Delaney