0
\$\begingroup\$

Is there a proper word that describes what the MISO line does in English language ?

And secondly how would I debug this hardware issue? I should say that the SPI device that I am trying to communicate with has already been replaced with a new one. Same behaviour.

logic analyser screenshot

Update in response to comments: no analog oscilloscope available, circuit's clock is set to 2 MHz, logic analyzer samples at 16 MHz, the (one and only) SPI slave is a RFM43 ISM TRANSMITTER Module, no schematic - just wired an arduino to the SPI slave.

\$\endgroup\$
  • 1
    \$\begingroup\$ First off, what device? be specific. Secondly are you sure your sampling at the correct frequency? What is your clock? how fast is your logic analyzer sampling? \$\endgroup\$ – Voltage Spike Jan 10 '17 at 16:56
  • 1
    \$\begingroup\$ Got a schematic? List every device on your SPI bus and how you are managing chip selects. Could be bus contention. \$\endgroup\$ – vicatcu Jan 10 '17 at 17:05
  • 2
    \$\begingroup\$ In addition to readers needing the information already requested (device information & schematic), do you have access to an oscilloscope? If so, then using that to view the shape of the MISO waveform may reveal useful information, which the logic analyser output cannot show (and could therefore potentially be misleading you). Those apparent glitches may actually be very different (with a more obvious cause) when viewed in an analog voltage domain on a 'scope. \$\endgroup\$ – SamGibson Jan 10 '17 at 17:21
1
\$\begingroup\$

If you think that MISO may be picking up interference or energy from the RFM43, you could try adding a small capacitor (try 50pF, 100pf, 470pF, 1nF) to ground and test again. If the glitches go away then you probably are experiencing EMI or Electro-Magnetic Interference.

To verify this, remove the capacitor and construct an aluminum-foil "dome" around everything except the RFM43, careful not to touch any bare metal. Put an alligator clip on the dome and connect it to ground. Power it on and check MISO - if it's clean, then the dome is blocking RF interference from coupling into the MISO line. At this point you need to work more on how your unit is designed and shield these lines more from the RFM43.

If it does nothing, then your issue is elsewhere. Reduce the SPI clock rate; high-speed-anything always complicates things. Also, long connections between Arduino and RFM43 would also make interference more likely - make sure all wires are very short. Also try adding extra bypass capacitors near each device and see if that helps. Also read the datasheets carefully to ensure you have the correct lines going to the correct pins. The RFM series are notorious for having tiny little details buried in the datasheets.

\$\endgroup\$
  • \$\begingroup\$ Here is a helpful answer, many thanks! The wires are kind of long yeah... like10 - 50 cm. RFM43 is an emitter, not a receiver, and it has no antenna snapped to it. Clock and MOSI are fine as you can see, and MISO behaves identically if the wire is unplugged and I just connect my logic analyzer to the MISO pin on RFM43. And those are not just glitches, even if no glitches, the MISO oputput is still plain wrong (I think). \$\endgroup\$ – kellogs Jan 10 '17 at 18:36
0
\$\begingroup\$

The SPI bus progressed to the names MOSI and MISO, by Motorola I think, from the original SPI bus names DIN and DOUT or such like, meaning 'Data In' and 'Data Out'.

It is very often (frankly, call it always) very confusing to use the words IN/INPUT and OUT/OUTPUT in signal names. Directions depend upon where you're looking at a circuit.

Consider an SPI bus between a microcontroller (MCU) bus master and an EEPROM bus slave. Serial data is received by the MCU on a pin formerly known as DIN. The EEPROM manufacturer could either (a) call the EEPROM's serial data output DOUT and rely on the designer to make a cross-over, connecting MCU-DIN to EEPROM-DOUT, or (b) call the EEPROM's serial data output DIN so the designer can connect MCU-DIN to EEPROM-DIN and have no cross-over but pin names that say the opposite of what they mean.

Neither of these would be clear and unambiguous on a schematic without additional information (notes/arrows on schematic, referring to data sheets).

The names Master-Out/Slave-In (MOSI) and Master-In/Slave-Out (MISO) are clear and definitive, solving this problem. They still contain the forbidden-ish 'In' and 'Out' but they state directions for both ends of the wire so the function remains clear.

Incidentally, there are plenty of SPI slave devices with DIN(output)/DOUT(input) pin names kicking about. And every time I see one, I have to reach for its data sheet to check very carefully! :-) I've never had to with the MOSI/MISO scheme.

\$\endgroup\$
0
\$\begingroup\$

The MISO line is an acronym for "Master In Slave Out" - notably it is the way that a slave device on an SPI bus feeds data back to the Master (which incidentally also provides the clock for that synchronous transfer).

In many hardware systems there are multiple slave devices on a SPI bus, and they are granted access to the bus, explicitly by the master, through the use of active low chip select signals. SPI devices that are not selected are expected to tri-state their driver on the MISO line so that they don't interfere with other devices' data transfers. It is the responsibility of the bus master to ensure that the chip select signals themselves respect mutual exclusivity (only one device selected).

If there is only one slave device in your system, check your datasheet to make sure your timing diagram matches what is in the datasheet (including SCK, MOSI, and CS signals). SPI also has "modes" so be careful to check that edges are happening when and where they should. The modes are about whether data changes on the rising or falling edge of clock (CPHA), and whether the clock is high or low when idle (CPOL). See Wikipedia entry on SPI.

Random Thought / Update: In software, make sure that your MISO pin on the microcontroller is configured as an INPUT.

\$\endgroup\$
0
\$\begingroup\$

My problem was with the logic analyzer's clock. Once I disconnected that from the Arduino's SPI SCK pin all went fine.

\$\endgroup\$
  • \$\begingroup\$ Hmm, I wonder whether that's to be expected or the logic analyzer is just broken. \$\endgroup\$ – kellogs Jan 11 '17 at 16:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.