• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 38 subscribers
  • Views 335 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.

TIDA-01487: Communication error

Stefan Veljkovic
Prodigy 10 points
Part Number: TIDA-01487


Tool/software:

Greetings,

We wanted to use your arbitrary logic in our design. We copied everything, even the same components(not intended). Where we found the issue to be, is in communication between isolated and nonisolated CAN networks. When we want to transfer information from one side to the other we have no problem, doesnt matter the side, but when we want those two side to communicate it looks like our isolated CAN side cant get the message trough. Our device on isolated side can send only one message before getting, we are guessing, blocked by other messages on nonisolated side. Nonisolated side continues to communicate with zero issues and messages are sent every 100ms (CAN is opperating at 500kb/s), which is not enough to clog the network in our opinion.

Arbitrary circuit is on the nonisolated side of the CAN network. What we did differently is instead using the isolated power supply that you suggested, we have put TEL6-1212, and than trough LDO we are dropping it to 5V and one more thing, except using your TCAN1042 we are using NXP PCA82C250. Everything else is the same.

Is it possible that you encountered similar problems while testing yours design? 

Your help is much appreciated

Thank you in advance

Best regards,

Stefan

  • 0
    TI__Expert 5350 points

    Hi Stefan,

    Thank you for your question.

    I don't think the power supply has any impact as long as you secure proper power supply to the components/devices.

    We did not encounter any problems when testing the design on our side. I also think that low baud rates should be tested first - which you did - to check if the arbitration circuit is working correctly.

    What I am not understanding from you description is: Both sides should relay the CAN messages to the second side. So what is on the non-isolated side should be transferred over to the isolated side, and what is on the isolated side should be transferred to the non-isolated side. Based on your description, I am not sure if this does happen in you design?

    I suggest to double check two things.

    1. Check that you have implemented/wired the arbitration circuit correctly.

    2. Check how TCAN1042 and NXP PCA82C250 work similar in terms of function, signal delay, keeping the dominant state, timeout, etc.

    Hope this helps to debug further.

     Thomas

  • 0 in reply to Thomas Mauer
    Prodigy 10 points

    Im sorry for not giving more detailed description, im only now realising what i have written.

    Basically both isolated and nonisolated side send hearthbeat to the CAN network. The isolated side is sending towards nonisolated side 16 consecutive information about some measurement on every 200ms. What we have found is that when we start the system (turn on the power supply) isolated system sends all 16 messages with 0 errors but when master on nonisolated side starts sending hearthbeat (on every 100ms) it looks like it takes the priroty on the network and doesnt let our isolated system to send information to the network. What is also interesting is that after isolated system stops sending message, if we disconect our master on nonisolated side, the isolated system doesnt start to send information on the network.

    We have checked the arbitration circuit, it looks the same as yours. 

    We have checked the difference between two CAN chips, still havent found the difference that would cause the error, they heve the similar times in signal delay and keeping the dominant state. 

    Thanks a lot for the assistance, and now its only about debug and finding the error.

  • 0 in reply to Stefan Veljkovic
    TI__Expert 5350 points

    Hi Stefan,

    Thanks for the clarification and for confirming that the arbitration logic works as expected.

    I think you may need to work with NXP to figure out why the PCA82C250 seems to work differently than the TCAN1042.

    I will close this e2e now, but let me know when you need additional feedback from our side.

    Regards,

     Thomas