• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 2 answers
  • Subscribers 34 subscribers
  • Views 1441 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.

THVD1429: RS485 collision avoidance in high-reliability systems

SlawomirM
Prodigy 60 points
Part Number: THVD1429

Hello everyone, 

I have a situation like this: there is a subsystem (around one PCB board, which utilises two MSP430 microcontroller). Subsystem communicates with satellite bus thorugh RS485 bus. Inside the subsystem, these two MCUs are both connected to the same bus, so in default operational mode, they exchange infomations between each other using this bus, but in random moment, there could be received a command from OBC (so satellite platform), which has higher priority. 
Connection like is because, if failure mode occurs, and one of the microcontrollers failed, OBC can access directly the second one. 
the question is, how I can:
a) avoid collision between standard two MCU communication and OBC high priority message,
b) avoid crating a spam on the bus, on the line to the OBC - I want to hide internal communication,
Half-duplex transceivers are used. 

So far, I found that I can avoid a) with messages priority and verifying if the bus is in idle before eachj transmission, but what about b)? I see some potential in using RS485 repeater - I can turn off the driver in specific situation, but is this really reliable solution? 

I will be glad for any suggestions, maybe solution is really easy but I don't realise this yet.

Btw. Using CAN in this case is not yet an option (compability). 

Have a great day!

  • 0
    Guru 317000 points

    This sounds as if you need separate buses for internal messages and OBC messages. (If the MCUs and the OBC can transmit at the same time, and you want to receive the OBC message, then separate receivers is the only solution.)

    With the two MCUs on the same board, you do not need an electrical RS-485 bus for them; you could connect the UARTs directly, or use another protocol like I²C or SPI.

  • 0
    TI__Guru 52262 points

    Hi Slawomir,

    So for your first question - a) - using a priority system is probably the best solution; which it seems you have already figured out. Since RS-485 is a PHY Layer Specification only (i.e. it only defines electrical layer of transceiver) the devices themselves are essentially protected from damage during collisions and since the THVD1429 has integrated receiver failsafes a collision will results in a "high" output on the "R" pins of the transceiver instead of glitching. However how the system deals with collisions usually is done in a higher layer through firmware - and priority systems are probably the simplest method.

    For your second question b) keeping unneeded signals off the OBC inputs is a bit more challenging.

    From a hardware perspective Clemens suggestion of using two different busses is probably the best method.  Communication just between microcontrollers using something like SPI on I2C with the RS-485 bus dedicated as OBC to microcontroller communication only. 

    If you want everything on the same bus it gets complicated. If you look at a repeater - how we typically suggest doing repeater designs for RS-485 they are two back to back RS-485 transceivers with some logic that essentially ensures the device is always active in either RX or TX mode (using either Schmidt Trigger buffers or One-Shot circuits. https://www.ti.com/lit/ug/tidu590/tidu590.pdf?ts=1685988921498 - design for reference. Please note this uses isolated devices as the biggest reason you'd use a repeater is to extend bus length which comes with the risk of additional ground shifting so if you use isolated devices it helps mitigate the issues of larger ground potential differences. Since this application isn't needing this type of protection you can use any RS-485 transceiver with similar enable schemes - just the values of some of the components may change. This design also expects a constant frame rate - so i.e. the communication is using standardized packet size as the design is tuned to a specific delay time for the control circuitry. 

    It may be possible to use some additional logic and a GPIO signal from the MCU to prevent communication to the OBC - from our reference design included above:

    Essentially the repeater is placed between MCU's and OBC and if you take a GPIO signal from the MCUs and AND it with the output of the control circuitry both sides of the repeater. If the MCU's force the GPIO low when they are communicating internally the repeater will not actively repeat as the repeater will be stuck in RX only mode. When the MCU's are not communicating between each other you force GPIO high and the repeater will work as normal. This will change some of the higher level firmware because the OBC's bus will only be active when the MCU's are directly communicating with it. So if the OBC wants to send a message it won't know if the MCU's are communicating and may need to send a message asking if MCU's are ready and if no response occurs within a timeout period you define then the OBC can wait and try again until the MCU's release the repeater.  Please note once again that the reference design uses isolated devices - but in your use case you don't need the isolation you just want to essentially be able to turn a section of the bus on and off as needed. 

    This solution does have its risks as other problems may be causing no response and it would be hard to detect for that. 

    So it is possible to use a repeater but it may be more complicated than just having an external and internal bus separated. 

    Please let me know if you have any other questions. 

    Best,

    Parker Dodson