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.

Triple Modular Redundancy (TMR) with RM46/48 MCUs

Other Parts Discussed in Thread: TPS653850-Q1, RM46L852

Hi to all!

I'm planning to design a new Triple Modular Redundancy (TMR) flight controller and autopilot for unmanned systems/drones. One project already exists for a simple autopilot based on the RM46:

So I have few questions about the ports to be used for intra-MCU communication and synchronizing. I found a interesting paper about a DSP TMR: () go to page 23.

My primary questions are:

1) Is better to use MibSPI or SPI for Intracommunication between the MCUs?

2) Is better to use MibSPI or SPI to read IMU sensors (e.g. MPU9250)?

3) Is better to use eTPWM or HET?

Thanks in advance for your feedback. 

-Jarno

  • Hello Jarno,

    To begin, it is really difficult to provide relevant advice on these matters since we don't really know anything about the requirements of your system so please take this under advisement that our suggestions may not be optimal for your system.

    Jarno Puff said:
    1) Is better to use MibSPI or SPI for Intracommunication between the MCUs?

    Certainly SPI is the protocol that is most often used for device to device communications and with baud rates up to 25MBits/sec it is very fast as well. Alot of inforamtion can be transmitted very quickly. For sure, if functional safety is desired/required, you should consider use of the built in error notifications such as bit errors, in message parity, data overrun errors, etc. In addition you should also consider using some additional safety related concepts to the protocol such as packet CRC (information redundancy as defined by ISO26262 and IEC61508) and transmission redundancy such as redundant transmission of packets/data to insure no transient faults during transmissions. 

    Jarno Puff said:
    2) Is better to use MibSPI or SPI to read IMU sensors (e.g. MPU9250)?

    This depends on the bandwidth needs. Certainly MibSPI would be best suited if you are sending packets with multiple data bytes or data longer than the standard SPI message type. i.e., multiple bytes transmitted to achieve a 64bit data word. MibSPI lets you combine data into transfer groups and then process them together. If the data can be sent as individual 16-bit data and managed by the applications on each end of the datastream, then perhaps SPI would work as well. This is really up to you and should be evaluated based on bandwidth needs. I would, strongly recommend use of the DMA to lessen CPU loading and time within the SPI/MibSPI ISRs.

    Jarno Puff said:
    3) Is better to use eTPWM or HET?

    This is again up to you based on your reqirements/needs. For sure the ePWM and NHET should each meet your needs. The NHET is by far more advanced in terms of its flexibility and is autonomously operated withoun CPU intervention. The NHET, though, can be challenging to learn and to program so perhaps a start with the ePWM for basic operations then as you get more advanced needs or need more channels than the ePWM can provide, have a look at NHET.

  • Hello Chuck,

    thanks for your quick response.
    1) If I understood correctly, all MibSPI can be used as standard SPI too, I'm correct? So at the end if I have a 4 wire SPI MCU-to-MCU connection I can test and choose the best one for my application. Correct? At the end I would like to get the same architecture as described in the DSP-TMR project I linked above. But instead of sending PWMs to a majority voter I will use the CAN bus.

    2) I will use around 1.000 Hz for the IMU

    3) ok, I could use 4 ePWM and 4 NHET ports, so I have both on the board. Would this make sense?

    4) For the power supply I was thinking to use the TPS653850-Q1 (www.ti.com/.../description). Will this the right one for the RM46L852 or is there a better alternative? The TPS have a SPI bus for MCU communication, but I was not able to figure out if this have to be a dedicated SPI bus or it can be share with other devices such as EEPROM, SD-Card and FRAM.

    5) I need to use the Futaba S.BUS protocol, but I never used it on a Hercules, so I have no idea what kind of MCU port I should use. For there PPM I will use a eCAP, but for the S.BUS? Here the protocol specs, may be you could advice me on which MCU port (GIO, eCAP, HET, etc): developer.mbed.org/.../

    Thanks and Regards,

    -Jarno
  • Hello Jarno,

    Jarno Puff said:
    1) If I understood correctly, all MibSPI can be used as standard SPI too, I'm correct? So at the end if I have a 4 wire SPI MCU-to-MCU connection I can test and choose the best one for my application. Correct? At the end I would like to get the same architecture as described in the DSP-TMR project I linked above. But instead of sending PWMs to a majority voter I will use the CAN bus.

    Yes. As long as you select a set of MibSPI pins, you can use either the buffered functionality or use it in compatibility mode (either in 4 pin mode).

    Jarno Puff said:
    3) ok, I could use 4 ePWM and 4 NHET ports, so I have both on the board. Would this make sense?

    Either should be OK but I would suggest you see which will better suite your needs. If ePWM works for you, I think these are much easier to get going; but, if you need more functionality/flexibility than they can provide, NHET has a lot of flexibility to offer even if it is more complicated to program and use.

    Jarno Puff said:
    4) For the power supply I was thinking to use the TPS653850-Q1 (www.ti.com/

    .../description). Will this the right one for the RM46L852 or is there a better alternative? The TPS have a SPI bus for MCU communication, but I was not able to figure out if this have to be a dedicated SPI bus or it can be share with other devices such as EEPROM, SD-Card and FRAM.

    I am not familiar with that PMIC. We often recommend to the users of our devices to consider the TPS65381 lthough it has had limited availability lately due to some issue requiring a revision change. This device has features such as the Q&A Watchdog and nERROR monitoring that are specifically designed for use with Hercules devices. We have an application note available that outlines integration of the TPS65381 and hercules devices. I would recommend a dedicated SPI for if the SPI is also a Q&A watchdog as in the TPS65381.

    Jarno Puff said:
    5) I need to use the Futaba S.BUS protocol, but I never used it on a Hercules, so I have no idea what kind of MCU port I should use. For there PPM I will use a eCAP, but for the S.BUS? Here the protocol specs, may be you could advice me on which MCU port (GIO, eCAP, HET, etc): developer.mbed.org/.../

    Unfortunately, I have no familiarity with this interface at all. However, NHET is wildly versatile and capable for serial protocol "bit banging." We have successfully been able to emulate I2C, SCI, SPI, and SENT using the NHET module so I suspect it might be possible to do the same for the Futaba S.BUS protocol.

  • Hello Chuck,

    many thanks for the advices. I had considered to use the TPS65381, but it has been tagged as "NRND", so I selected the other one. But if you say it will still be available I will use it. Unfortunately I have no dedicated available SPI and would like to share it with the FRAM and pressure sensor:

    MIBSPI3
    MIBSPI3CLK -> V9
    MIBSPI3SIMO -> W8
    MIBSPI3SOMI -> V8
    MibSPI3 CS0 – MS5211 -> V10
    MibSPI3 CS1 -> V5 -> MDCLK
    MibSPI3 CS2 – MS5525 -> B2
    MibSPI3 CS3 – FRAM -> C3
    MibSPI3 CS4 – TPS65381 -> E3


    About the SPI stuff I have a last (may be last) question. The MibSPI5 pins are multiplexed with the RMII and the ePWM4A. If I choose to use the SPI/MibSPI function, can I select to not use CS0, or are these hardwired to the SPI5 function? I need the ePWM4A for PWM output to drive one of the 8 motors.

    MIBSPI5
    MIBSPI5CLK -> H19 -> RMII_TXEN
    MIBSPI5SIMO -> J19 -> RMII_TXD1
    MIBSPI5SOMI -> J18 -> RMII_TXD0
    MibSPI5 CS0 -> E19 -> EPWM4A
    MibSPI5 CS1 -> B6
    MibSPI5 CS2 -> W6
    MibSPI5 CS3 -> T12

    Thanks for the NHET advice, will consider it. Can it be selected to be an inverted serial format? SBUS is an interesting thing. It uses a 100000 baud inverted UART with a 25 byte transmission.


    Best,

    -Jarno
  • Hello Jarno,

    I am aware that the TPS65381 is labeled NRND but I think this is due  to the revision change that they are currently working through. For a definite answer on that, I would suggest posting to their forum to get the product support specific advice.

    Jarno Puff said:
    Unfortunately I have no dedicated available SPI and would like to share it with the FRAM and pressure sensor:

    MIBSPI3
    MIBSPI3CLK -> V9
    MIBSPI3SIMO -> W8
    MIBSPI3SOMI -> V8
    MibSPI3 CS0 – MS5211 -> V10
    MibSPI3 CS1 -> V5 -> MDCLK
    MibSPI3 CS2 – MS5525 -> B2
    MibSPI3 CS3 – FRAM -> C3
    MibSPI3 CS4 – TPS65381 -> E3

    This should work fine. Keep in mind that one of the functions of the TPS SPI input is a Q&A watchdog so just be aware and make sure you can service the WD bandwidth needed.

    Jarno Puff said:
    About the SPI stuff I have a last (may be last) question. The MibSPI5 pins are multiplexed with the RMII and the ePWM4A. If I choose to use the SPI/MibSPI function, can I select to not use CS0, or are these hardwired to the SPI5 function? I need the ePWM4A for PWM output to drive one of the 8 motors.

    MIBSPI5
    MIBSPI5CLK -> H19 -> RMII_TXEN
    MIBSPI5SIMO -> J19 -> RMII_TXD1
    MIBSPI5SOMI -> J18 -> RMII_TXD0
    MibSPI5 CS0 -> E19 -> EPWM4A
    MibSPI5 CS1 -> B6
    MibSPI5 CS2 -> W6
    MibSPI5 CS3 -> T12

    This should be fine as well. Each TG could be assigned the appropriate CS.

    Finally in regard to your question on the NHET. You could use the existing SCI/UART reference designs to help implement the new protocol. I think the only trick would be to change the edge on which you are capturing the input bits that are being shifted in, right? Once a full byte is received, you would use the HTU to transfer the value out to a buffer. 

  • Thanks Chuck, very appreciated! Now I have some basic inputs to go ahead with the HW design.

    Best,

    Jarno