0
\$\begingroup\$

The device defaults to an inactive state (no auto conversions) unless reconfigured.

So I write to the MAX31856 config register 0x80 to setup the device to automatically read the default K type thermocouple using an 8-bit transfer 0X80 address followed by 0x80 data. CS line goes low and immediately before and after the transfer. The timing of CS low to the first clock rising edge is 200 nsec (I have tried 400nsec)enter image description here

It appears to not accept the config data sent as the DRDY line never changes state after sending this data.

To verify the config data was correctly loaded I attempt a read of the config register by de-asserting CS and reasserting and then send address (0x00) followed by 0x00 to read the data, but the SDO line of the IC remains in a high impedance state (no pull-up used and the pin voltage not driven high or low).

Can't seem to figure out what I am not understanding - this is not my first time with SPI.

Anyone sees my error?

\$\endgroup\$
3
  • \$\begingroup\$ Your clock doesn't look very healthy. Why are the clock periods changing, is that by design? \$\endgroup\$
    – Lundin
    Apr 13, 2021 at 14:33
  • \$\begingroup\$ thanks for pointing that out - not by my design and not sure why the master SPI is doing that - I will check it out. \$\endgroup\$
    – ACD
    Apr 13, 2021 at 14:37
  • \$\begingroup\$ What is the SPI clock frequency? It looks very close to 5MHz, and depending on analyzer sampling rate it might just look irregular. The pins are named wrong, MISO is master input but it is clearly output from MCU, so check the pins. SDI is input to chip from MCU output MOSI, SDO output from chip to MCU input MISO. Check that all chip power supply pins (grounds and supplies) are properly connected. \$\endgroup\$
    – Justme
    Apr 13, 2021 at 15:26

2 Answers 2

Reset to default
1
\$\begingroup\$

I finally tracked down the problem to a single 600 nsec pulse on the CS line at power up.

This pulse, unintentionally generated, was due to the DSP output registers being initialized.

This pulse long enough for the Max chip to determine clock polarity which appears to be a one time setup. I assume that as Max chip appears not to respond what the SPI clock polarity as configured in the DSP controlling the SPI bus on subsequent CS transitions that are part of a real message.

Once I eliminated the startup pulse everything worked.

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

I would slow things WAY down. When debugging problems like this, put the clocks and signals in the KHz range so your tools give you good information. You can speed things up later when you know they're working.

You are almost certainly violating tCWH (CS inactive time) of 400ns.

Don't bother with the write. After power-on, just read a couple bytes starting from 0 until you can see the 0x03, 0xFF, 0x7F, 0xC0, 0x7F factory default sequence from the memory map.

Good luck.

\$\endgroup\$
7
  • \$\begingroup\$ I appreciate the support. \$\endgroup\$
    – ACD
    Apr 14, 2021 at 17:12
  • \$\begingroup\$ I relabeled the IO to clarify, I slowed way down the CLK is now 100kHz (it was 4.1MHz- spec is 5 MHz) - but excellent idea. tCWH is now 5.5usec just reading address 0-9 . Still no activity on Max SDO line \$\endgroup\$
    – ACD
    Apr 14, 2021 at 17:38
  • \$\begingroup\$ Don't do a write so the whole tCWH isn't even an issue. You don't need to. Just start reading from 0x00--you can just put 0 on the MOSI pin and leave it there. Then you can ignore CPOL/CPHA/etc. I would also start looking at your signals with an oscilloscope instead of a logic analyzer--a logic analyzer only "sees" a signal if it crosses the threshold. If you have a short or a pullup or a pin reversed, a scope will see the "weirdness" (partial voltages, glitches, etc.) while a signal analyzer won't. At this point you need to check even the simple stuff. Good luck. \$\endgroup\$
    – Andrew Lentvorski
    Apr 15, 2021 at 2:32
  • \$\begingroup\$ Hi Andrew, Thanks for the ideas. I am not operating in Framed mode so the clock is not free running. That is why I send the dummy data to generate the clock. I will try operating in Frame mode but I see problems doing so in distributed network without additional logic to multiplex. I have used the scope - MOSI, Clock, CS look perfect at any frequency. The MISO changes state slightly from 3.3V to 3.25V - very subtle but visible. There is nothing else on the line. \$\endgroup\$
    – ACD
    Apr 16, 2021 at 9:54
  • \$\begingroup\$ You don't need framed mode. Just send 0x00 over and over. That initiates a Figure 6 SPI Multibyte Read Transfer. However, at this point you need to check all the simple stuff: Is the chip powered? Are my grounds ALL attached (check continuity)? Is the chip rotated 180 degrees? Did I set the MISO pin for input and not output at the MCU? Did I really attach SDO to MISO and SDI to MOSI?--check with a DMM in continuity. Lift Pin 11 on the chip and see if it wiggles when not soldered down. Is the chip bad--try another board or solder a new chip. Debugging is not easy. Good luck. \$\endgroup\$
    – Andrew Lentvorski
    Apr 16, 2021 at 10:25

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.