• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 3 answers
  • Subscribers 15 subscribers
  • Views 476 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.

ISO1050: Receiving missing frame information

user4932132
Prodigy 80 points
Part Number: ISO1050

Hello! I have a question to ask for advice

Using F2803x CPU and ISO1050DW,  for the CPU, CAN is full duplex, while for ISO1050, is it half duplex?

We found a small probability of frame information loss, where a node cannot receive one frame of data from the bus before sending the message, and the two frames of information appear continuously on the bus

Is there a situation where two nodes simultaneously send a frame of information? When ISO1050 of node A processes the sending information, node B first preempts the bus. The information that node A is waiting to send is waiting for the bus to be idle in ISO1050, and ISO1050 is currently occupied. Can it receive information from node B correctly? Or will this frame of information be discarded?

Best regard！

  • 0
    TI__Expert 8030 points

    Hello,

    Thanks for reaching out.

    We are currently looking into this, and will get back to you within the next 24 hours.

    Regards,

    Kenneth

  • 0 in reply to Kenneth Arnold
    TI__Expert 8030 points

    Hello,

    Thank you for your patience.

    user4932132 said:
    Using F2803x CPU and ISO1050DW,  for the CPU, CAN is full duplex, while for ISO1050, is it half duplex?

    The CAN Bus itself is half-duplex bus. When using the ISO1050, any message transmitted from the MCU to the CAN bus will also be reflected on the RXD pin of the device after a certain period of time.

    user4932132 said:
    Is there a situation where two nodes simultaneously send a frame of information?

    This possibility of this situation is dependent on the application.

    user4932132 said:
    The information that node A is waiting to send is waiting for the bus to be idle in ISO1050, and ISO1050 is currently occupied. Can it receive information from node B correctly?

    As previously mentioned, any information being sent from the MCU to the CAN Bus using the TXD pin of the ISO1050 can be read on the RXD pin of the device after a certain period of time. The time it takes for data transmitted from the MCU to the CAN Bus to be reflected on the RXD pin of the ISO1050 is known as loop delay, and it can be found in Section 6.8 of the device datasheet. 

    Regards,

    Kenneth

  • 0 in reply to Kenneth Arnold
    TI__Expert 4430 points

    Kenneth，

    as talked with customer, there are about 20 CAN note on the bus,  all CAN note ID are the same, the issue occur when two CAN note are sending frame data almost at the same time, these two CAN note(let's name CAN note A, and B) data frame can be transmit successfully one by one on the bus,  CAN note A send firstly, CAN note B send secondly, and other CAN note can receive both of these two frame data , but CAN note B can not receive the frame data from CAN note A and lost this data. 

      we are thinking that there have possibility that two CAN note are sending data with same ID at the same time, in this case there will fail to do arbitration, as the data from two CAN note are not the same, then there will have bit error on the bus and will generate error frame, so this may still not be able to explain the reason of the phenomenon that customer see. 

    in their code there have set three mailbox to receive data for same ID, and overwrite the data is not allowed. 

    any other explanation why CAN note B will lost data? 

  • 0 in reply to Strong ZHANG
    TI__Mastermind 29595 points

    Hello Zhang,

    Thanks for the added input. 

    From my understanding, the applications have a CAN node set to receive data from a specific ID. This ID corresponds to two nodes both responding and sending data onto the Bus. As you have noticed this will cause issues with the packet as the two nodes try to use the same space. 

    Strong ZHANG said:
      we are thinking that there have possibility that two CAN note are sending data with same ID at the same time, in this case there will fail to do arbitration, as the data from two CAN note are not the same, then there will have bit error on the bus and will generate error frame, so this may still not be able to explain the reason of the phenomenon that customer see. 

    When the bus is being driven by more than one node, it can create unpredictable results. This may be bit error or packet loss (or a different effect) depending on the drive strength and impedance of the drivers. If node A is closer to the receiver or a stronger drive strength then it can be overpowering node B, and there for the node B packet will be "lost". 

    I hope this helps. Let us know if you have further questions. 

    Best,
    Andrew

  • 0 in reply to Andrew J
    Prodigy 80 points

    Kenneth and Strong,

    thanks for your answer

    supplement：

    PCAN（PCAN system technik Gmbh） can receive correct data from two nodes. On the bus, node A's data comes first, followed by node B's data. Node B did not receive data from node A, node A can receive data from node B, while other nodes can receive data from node A and node B.

    Best regards

  • 0 in reply to user4932132
    TI__Expert 8030 points

    Hello,

    Thank you for providing additional information about this issue.

    Based on the information that both you and Strong have shared in your previous posts, it sounds like all of the ISO1050 devices in the design are correctly converting between logic and CAN bus signals. Therefore, I don't believe that the ISO1050 itself is causing the communication error that is being observed at node B.

    To determine the cause of this issue, I recommend that you look into the software portion of the design to determine what is happening to the CAN bus transactions both before and after arbitration. This communication error is likely being caused by a software issue, since the information that you have provided suggests that all ISO1050 devices are functioning correctly in the design. For some additional information on how message priority is determined on a CAN bus, you can refer to Section 4 of this application note: https://www.ti.com/lit/an/sloa101b/sloa101b.pdf. 

    Regards,

    Kenneth