0
\$\begingroup\$

I hope this question is not a repeat of others on this stack exchange concerning SPI. I've been searching for at least an hour and have not found the same problem/answer.

SCENARIO

My friends and I are attempting to get an OLED and rotary encoder working together using our own personal board. Right now, we just want the position on the encoder to show up on the OLED.

An absolute position rotary encoder is hooked up with a development board using the ATmega2560 chip. The 2560 is talking to the encoder with these SPI settings:

  • Master Mode (SPI Mode 3)
    • Phase: 1
    • Polarity: 1
  • SPI Prescaler at f_OSC / 128 (current CPU Freq = 16MHz)

OLED: Adafruit SSD1306, 1.3" 128x64

Encoder: iC-MU Absolute Position - iC-MU Position Encoder Datasheet

I have the current program set to read from one of the encoder's internal EEPROM registers every second. Although I'm not yet certain about addressing the EEPROM accurately, the problem I would like to address is different.

PROBLEM

I wasn't getting a response from the encoder, so I hooked up an oscilloscope and checked all four SPI lines, as seen below. For some reason, the MOSI line never drops below ~3.50V. The receiving device would still consider this a HIGH signal.

SPI Oscilloscope Reading

I have tried tapping into the OLED SPI connections since the display itself works with SPI. Nothing new happened. I've double-checked that I still have a working board, constantly reconnecting the OLED and disconnecting the encoder. The board definitely still works.

What might be the problem with the SPI? Is there a specific name for this problem?

\$\endgroup\$
  • 1
    \$\begingroup\$ Need to know what the driving source is for MOSI, is it an MCU? what are the output characteristics of the source? Do you also have more than one thing connected to MOSI? What are the Vcc's on both the LED and the chip that is driving MOSI? Are the digital pins compatible with the digital levels that your driving them? Do you have the MOSI port configured wrong? Have you tried driving MOSI with nothing attached? Are you shorting a wire out you shouldn't? \$\endgroup\$ – Voltage Spike Jul 20 '17 at 20:03
  • 2
    \$\begingroup\$ It is not clear how your system is wired without a schematic \$\endgroup\$ – sstobbe Jul 20 '17 at 20:20
  • \$\begingroup\$ The driving source is the ATmega2560 MCU. My SPI connections are only on the encoder (for modularization). On a different note, I tried hooking the SPI connections without anything attached (which I'd done before, but hadn't taken note. ._.' ). The MOSI came out perfect from 0 to ~5V, what I was expecting. It may be that something got shorted on the iC-MU board, which is bad news. \$\endgroup\$ – S. Chang Jul 20 '17 at 20:30
  • 1
    \$\begingroup\$ @S.Chang you must include the connections in the question. At this point its about equally likely that you have the quasi-SPI device misconfigured, or that you swapped MISO and MOSI on it. \$\endgroup\$ – Chris Stratton Jul 20 '17 at 22:48
  • \$\begingroup\$ @Chris - Agreed. Swapped MISO & MOSI would fit my analysis and also explain that odd green MISO signal trace. It seems to just be noise, and not what it should be i.e. a driven output from the SPI slave - even if it were to remain driven to 0V, I wouldn't expect to see that noise on an actively driven 0V, compared to how clean the other signals are. Perhaps that green trace is really two inputs connected to each other (MISO from the MCU and MOSI from the encoder), and is not actively driven at all! So despite the focus on the MOSI signal, the scope trace labelled MISO also seems abnormal. \$\endgroup\$ – SamGibson Jul 20 '17 at 23:12
3
\$\begingroup\$

What might be the problem with the SPI?

That scope trace suggests that there is another driver on the MOSI signal, in addition to the MCU.

That is bad, since MOSI typically uses a push-pull driver and multiple push-pull drivers will conflict, if they attempt to drive to different logic levels at the same time. As a result, you tend to see a "stepped" voltage like you see on your MOSI scope trace, when the different conflicting drivers change the logic levels that each is driving. (In the worst case, multiple drivers of the same signal can become permanently damaged, if they exceed their allowed maximum sink/source current through the opposing driver.)

It isn't as simple as MOSI being shorted to Gnd as we wouldn't then see it reach ~5V, nor is it shorted to ~5V since the signal is 0V at the start of the trace. There appears to be a low resistance (e.g. another device's output driver? a low value resistor?) pulling it up. (See below.)

Is there a specific name for this problem?

Conflict between multiple drivers on the same signal. Your next step is to find out what else is driving that signal and why.

I browsed the encoder's datasheet. It is worth noting that it doesn't have a fixed SPI interface. It has a programmable serial interface, which can be SPI but can also be in other modes. I would check your programming of (and connections to) the encoder, to see if that is in a mode where it is driving the pin, which you believe is MOSI in SPI mode.

Notice how the MOSI signal starts at 0V, and goes to that ~3.5V level when -CS becomes active (low). Below, I have added a vertical white line onto your scope trace, to show that MOSI rises to ~3.5V at the same time as -CS is driven low, before the first clock pulse on SCK:

MOSI at 3.5V at the same time as -CS is driven active (low)

That correlation is a big hint that you are enabling the conflicting driver on the MOSI signal, when you drive -CS low. Assuming that the -CS signal goes only to the encoder, then that again makes the encoder the primary suspect.

|improve this answer|||||
\$\endgroup\$
  • \$\begingroup\$ Hey Sam, thanks for the tips. I've been working on accessing the EEPROM through I2C today, which has been a little bit of a pain, but I think I am finally able to read the data within the memory. For some reason, I'm unable to write values to the EEPROM at the moment. The encoder data sheet claims to be using the 24C02B EEPROM (atmel.com/Images/doc5126.pdf ?). I've double-checked my I2C from a personal Arduino MEGA board to check out the memory. The values haven't been random, so I believe what I'm reading via I2C is correct... \$\endgroup\$ – S. Chang Jul 21 '17 at 22:15
  • \$\begingroup\$ @S.Chang - Hi, thanks for the update. However I don't see anything related to SPI in your update, so you're not expecting any analysis from me, are you? As mentioned in comments on the question, a schematic diagram (which definitely matches the actual hardware connections!) is needed to help confirm or eliminate some hypotheses. Also, I hope you saw my comment to Chris Stratton that the green trace labelled "MISO" also looks abnormal, and my suggestion about what might cause that. Good luck! \$\endgroup\$ – SamGibson Jul 21 '17 at 23:40
  • \$\begingroup\$ Here are my updates. I tried disconnecting certain lines from the encoder, like the CS. Curiously, the channel 1 line cleans up, but the disconnected CS line looks as though it's trying to be the SCLK, with little blips along with the actual SCLK. I'm still not sure what the problem is with the SPI though. I went out and got an Arduino Mega and programmed it using Atmel Studio 7. Got that working, so I transferred the code back over to working on the custom board. Besides that, I'm still looking through the hardware. Thanks for all the help. I don't know when I'll update past this point. \$\endgroup\$ – S. Chang Jul 25 '17 at 23:08
2
\$\begingroup\$

sigh. I found the problem. When we hooked the custom board up, the MOSI and MISO lines were swapped. Case closed. >.< The encoder is now working as it should, as is the custom board. I think the tip-off was definitely that the MOSI line was trying to remain HI when I tried placing it LOW.

Hope that clears up a lot of questions.

|improve this answer|||||
\$\endgroup\$
  • \$\begingroup\$ Well done on finding the cause and thanks for reporting back with the conclusion :-) Because of that swapping of signals, when -CS went active, it enabled the output from the encoder (MISO) and actually started the conflict between the two drivers (MCU and encoder) on that one signal (called "MOSI" on the oscilloscope, but it was really both MOSI and MISO at the same time!). \$\endgroup\$ – SamGibson Jul 26 '17 at 0:16

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.