Eval -CN0326-PMD2 multiple communication is not working.

Hi There,

I am using an STM32F103RET6, and the software I am still using is STM32IDE to write the code, When I connect one board on the SPI line it works perfectly, and if I connect 2 board on the same SPI but with different Chip Select than the processor freezes. if I connect 2 boards on 2 different SPI they work fine.
I recently pulled the RC out pin on one board and the other board worked but the temperature was erratic.
My aim is to be able to use more than 1  Board on the same SPI line with differents CS.

Hi Frank22,

I may have spotted the problem - I'm nearly 100% certain that the ADuM5401 outputs are always driven, as in, DOUT (U4 pin 6) does NOT go high-impedance when CS_N (U4 pin 3) is driven high.

One quick test would be to insert a 1k resistor in series with both boards' DOUT pins. Note that if you've got a long trace or long cable, this will affect signal integrity, so place these resistors close to the processor, minimizing capacitance at the processor's pin.

Also note that the ADUM5401 symbol in the CN0326 is very confusing, the VOD/VID are arranged such that the input / output direction matches the other pins, NOT the ground domains.

-Mark

Dear Mark,

Thank you for your reply, I really appreciate it.
While looking for potential solutions, I read a little more on the  ADuM5401, So I came up with a solution that worked but erratically.
I was pulling down all RCs out of the board that were supposed to be inactive and leaving high the one that the board was supposed to be communicating I was getting some reading but the values were sometimes erratics, I tried your solution but still freezing the processor however while combining the 2 solutions, I get the best results it is reading and give the correct value. my concern is while pulling down the RC out I limit the inactive boards to the lower power consumption in other words I am shouting down the board in the long run I am wondering if this will not bring other issues.

Hi Frank22,

First - I apologize I realized that simply adding 1k resistors won't work. That creates a divider between the two DOUT pins, and the logic level won't be valid most of the time, hence erratic behavior. The more complicated, but robust solution is to use a tristate buffer like the 74HC125. This has active low enable inputs that you can connect to your CS pins, connect the buffer intputs to their respective DOUTs, and the buffer outputs can be tied together and connected to your processor's data input.

(For reference - the resistor technique does work if you've only got one "misbehaving" SPI device whos SDO does NOT go tristate, and all others on the bus do go tristate. But in this case we've got two.)

Regarding RCOUT:

Pulling down the RCOUT pins does not look correct - the only function described in the datasheet is for it to drive the RCIN of another device. If this is counted as a digital output, it is spec'd at 4 mA, so shorting it low will draw at least that from the supply. Also, if the intent is to shut off the secondary side power, that may not actually work if the RCOUT is buffered after the internal PWM signal that's driving the regulator. Have you verified that this works as expected? If you want more details, better to ask in the  Interface and Isolation forum.

Regardless, powering down one of the isolators will likely not work either - see text on page 22 of the datasheet under DC correctness: " If the decoder receives no internal pulses for more than approximately 5 μs, the input side is assumed to be unpowered or nonfunctional, and the isolator output is forced to a default low state by the watchdog timer circuit."

What this means is if the secondary side of the device is powered down, the corresponding outputs (DOUT in particular) will be driven low (not high-Z) I suppose this shouldn't matter if you've got the recommended resistors, but it's still not a reliable way to disable DOUT.

As you get further into this, photographs and scope shots can help tremendously in debugging.

-Mark