1
\$\begingroup\$

I have an issue when communicating with an ADC over SPI. If I imitate the SPI protocol via bitbanging then I have no issues with communication; however, if I use the SPI hardware (I've tried Arduino and mbedOS) then communication fails and no data is received.

The biggest discernible differences are:

  1. The idle state of the MOSI line. When bitbanging, this line is held low when idle as opposed to high when idle using SPI.
  2. When bitbanging, the MISO line goes high as soon as CS does. When using SPI however, there is a noticeable slew.
  3. Lastly, CS takes a relatively long time to go high after the final clock pulse when using SPI as opposed to nearly immediately when bitbanging.
  4. The time taken to send the messages (visible in the images below). Though I can't imagine that this is an issue.

I am running in SPI mode 0, as according to the ADC datasheet. I've tried an Arduino Uno and a RedBearLabs Blend V2 (running mbedOS).

Below are two scope grabs of the signals.

  1. Trace 1 is SCLK.
  2. Trace 2 is CS.
  3. Trace 3 is MOSI.
  4. Trace 4 is MISO.

I am sending 10000000 on MOSI. The response received is not included in the scope grabs as I believe the issue is with the command sent in the grabs.

BITBANGING Bitbanging

SPI SPI

Thanks.

\$\endgroup\$
6
  • \$\begingroup\$ Can you please elaborate where communication fails exactly? I see you sending start bit and selecting channel, and it is only one part of the communication from MCU to the device. Did you check datasheet's SPI communication diagrams? \$\endgroup\$ – Anonymous Oct 9 '18 at 10:51
  • \$\begingroup\$ Of course. After an arbitrary amount of time after sending the above data a pin (SSTRB) should be driven high by the ADC to indicate that conversion is completed and data is available. When bitbanging this happens as in the datasheet (figure 4). When using SPI to send this command SSTRB is never driven high, indicating that the conversion is never actually initiated in the first place. \$\endgroup\$ – amitchone Oct 9 '18 at 10:53
  • \$\begingroup\$ I suspect "When using the internal clock, SSTRB rising edge transitions indicate that data is ready to be read from the device. When operating in external clock mode, SSTRB is always low." - are you sure device is not in mode 0? You did not mention you set the mode. Can you see any changes in MISO if reading for some time? \$\endgroup\$ – Anonymous Oct 9 '18 at 11:23
  • \$\begingroup\$ I'm absolutely sure that the device is in the correct operating mode, in this case internal clock mode. I'm certain because SSTRB does change when bitbanging and the data obtained is correct. Secondly, I can put the device into external clock mode (mode 0) and it operates as expected over SPI. \$\endgroup\$ – amitchone Oct 9 '18 at 11:28
  • \$\begingroup\$ Mode 0 is default mode (table 8 of the datasheet), and in order to achieve operating the SSTRB you must explicitly put device into mode 2. So far you said nothing about doing it. \$\endgroup\$ – Anonymous Oct 9 '18 at 11:33

Your Answer

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

Browse other questions tagged or ask your own question.