Quantcast

SPI (MISO only) problem driving the input

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

SPI (MISO only) problem driving the input

Chris G
Good morning,

I'm having some SPI bus issues I'm hoping you can help me with. Basically, the MISO signal looks good when disconnected from the gumstix (Chestnut) board, but as soon as I connect the wire from the slave device to the 40-pin header, the signal is crushed down to about 0.6 volts (as measured via o-scope).

The only significant difference we've noted about that pin is that (when powered) it shows about 18 ohms to ground versus about 200K for other pins configured as inputs.

Running "devmem2 0x480021CC" shows that the lower 16 bits are configured as 0x0100, which, if my understanding is correct, is input enabled, pulls disabled, mode 0 (SOMI).

I can communicate with the slave device, and it responds correctly (reading device ID registers, for example) and I can verify the communications are correct using an o-scope on all lines. As soon as MISO is connected to the 40-pin header however, the 1.8V signal drops to about 0.6V.

Thanks for any help or ideas,
Chris
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SPI (MISO only) problem driving the input

Chris G
I gathered some more information today. Using devmem2, I can set the MOSI pin to mode 4, making it GPIO172. Then I export the GPIO, set the direction to output, and am able to toggle between 0V and 1.8V just fine.

But when I try the same with the MISO pin (setting it to GPIO173, export, set direction to out), it only toggles between 0 and 0.4V.

I have verified this behavior on 3 EarthSTORM and Chestnut43 board pairs, one of which was right out of the box, with both custom and factory linux images, with the 40-pin header connected and disconnected.

The only conclusion I can draw right now is that something on either the Chestnut or the EarthSTORM is somehow bogging down that MISO/GPIO173 pin. In the input state, it doesn't seem to be going into high-impedance mode. It's either a design problem, or some subtle configuration register I'm missing.

It would be great if someone could verify this independently for me with some combination of EarthSTORM or Chestnut since I'm not even sure how to proceed now. Here's a log of what I did from boot-up, verifying that the MISO pin (pin 7 on the 40-pin header) only goes to 0.4V instead of 1.8V when high. Thanks for anything.

root@overo:~# devmem2 0x480021CC
/dev/mem opened.
Memory mapped at address 0x40145000.
Read at address  0x480021CC (0x401451cc): 0x01080100
root@overo:~# devmem2 0x480021CC w 0x01080004
/dev/mem opened.
Memory mapped at address 0x40191000.
Read at address  0x480021CC (0x401911cc): 0x01080100
Write at address 0x480021CC (0x401911cc): 0x01080004, readback 0x01080004
root@overo:~# echo 173 > /sys/class/gpio/export
root@overo:~# echo out > /sys/class/gpio/gpio173/direction
root@overo:~# echo 1 > /sys/class/gpio/gpio173/value    
root@overo:~# echo 0 > /sys/class/gpio/gpio173/value    
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SPI (MISO only) problem driving the input

Scott Ellis
I verified what you see with a Chestnut43.

It looks to me like the DOUT (MOSI) pin on the ADS7846 touchscreen
controller is not  high impedance when /CS is high as the ADS7846 TRM
says. (I'm a software type though so don't rely on my hardware theories.)

The ADS7846 controller does drive the MISO pin the full 0-1.8v
watching with a scope. But with CS0 high (touchscreen CS not selected),
I can't drive the MISO pin to 1.8v when I apply 1.8v to it from one of
the other exansion pins.

On a Tobi with the same COM, MISO has the full range 0-1.8v.

I'll also tried with the MISO pin configured as GPIO as you did and
got the same results. Can't drive MISO to 1.8v on the Chestnut, but
can on the Tobi.

I've never tried to run a second SPI device when using a Chestnut
board. I assume this is what you are trying to do.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SPI (MISO only) problem driving the input

Scott Ellis
I meant to say "DOUT (MISO)"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SPI (MISO only) problem driving the input

Chris G
Thanks very much for the verification. That led me to find a "fix," hopefully it helps someone out in the future.

The problem is that while the ADS7846 lines are probably tristated correctly, they're run through 1.8V-3V level translators/buffers (U8, U9, U10 on the Chestnut schematic), and so the buffers themselves seem to be loading those lines. That's why explicitly setting /CS0 high didn't help the situation.

The "fix" is to lift U10 pin 11 to isolate the 1.8V side of the miso line. You lose ADS7846 functionality by doing so, but with the buffer disconnected the inputs from the header work as expected. Experiments showed that lifting U10 pin 38 or cutting the trace to U7 pin 16 isn't sufficient, you need to remove miso from U10 at the 1.8V side.

The output enable (/OE) on the buffer chips is tied to ground, making them active. A better design would have either connected /OE to a GPIO for software control or just directly connected it to /CS, since making the /OE high tristates all the pins (according to the datasheet, haven't tried it). You could do that yourself with some careful soldering if you wanted to also.
Loading...