Due has easily corrupted SPI SCLK pin

Using Arduino Networking, Protocols, and Devices
1

Hi All,

I have an Arduino Due that's trying to communicate to two devices over SPI: a Flash chip and a TFT Display.

I started running into problems when I had both devices connected to the due. I have a test program for the flash chip, and was getting either corrupted values or constant 255 values being read from the chip. When I remove the SCLK pin from the TFT Display, however, I get the expected values being written/read from the chip... Weird. Even when I hooked up my oscilloscope to the SCLK pin, it caused incorrect values to be read to the chip, which I was pretty surprised by.. I was only able to get oscilloscope readings without corrupting the SCLK signal by switching the probe from reading 1X to 10X. But I guess all this means is the issue isn't caused by a bad display. Also, throughout all of this, I'm getting the proper activity from the display, so the clock must be working well enough for the tft to pick it up...

And FYI, I have multiples of the same flash chip, due, and LCD (actually even have two separate circuits on different breadboards too), and am finding this issue with any combination of the parts... So its not due to faulty parts, from what I can tell.

I've attached two screenshots of my oscilloscope, one with the display connected to the SCLK, and one without it connected. The one with it connected looks like it has less of a sharp "attack" on the rise and fall, but would this really be enough to affect the chip? It still rises up to 3.3v... But if this is the reason, does anyone have a suggestion of what can be done to make the rise and fall sharper?

Any help is appreciated! Thanks,

Pat

WithoutDisplay.jpg

WithDisplay.jpg

2

Seems like it could be this problem.

3

pattobrien:
Hi All,

I have an Arduino Due that's trying to communicate to two devices over SPI: a Flash chip and a TFT Display.

I started running into problems when I had both devices connected to the due. I have a test program for the flash chip, and was getting either corrupted values or constant 255 values being read from the chip. When I remove the SCLK pin from the TFT Display, however, I get the expected values being written/read from the chip... Weird. Even when I hooked up my oscilloscope to the SCLK pin, it caused incorrect values to be read to the chip, which I was pretty surprised by.. I was only able to get oscilloscope readings without corrupting the SCLK signal by switching the probe from reading 1X to 10X. But I guess all this means is the issue isn't caused by a bad display. Also, throughout all of this, I'm getting the proper activity from the display, so the clock must be working well enough for the tft to pick it up...

And FYI, I have multiples of the same flash chip, due, and LCD (actually even have two separate circuits on different breadboards too), and am finding this issue with any combination of the parts... So its not due to faulty parts, from what I can tell.

I've attached two screenshots of my oscilloscope, one with the display connected to the SCLK, and one without it connected. The one with it connected looks like it has less of a sharp "attack" on the rise and fall, but would this really be enough to affect the chip? It still rises up to 3.3v... But if this is the reason, does anyone have a suggestion of what can be done to make the rise and fall sharper?

Any help is appreciated! Thanks,

Pat

The DUE has weak drivers on it's pins. The spec's say some pins can only Source 3mA, Other 15mA.

To me it looks like you have long wires on your SPI bus. How is your SPI bus lain out? multiple stubs or one bus?

The second image show the added capacitance, but you are still getting overshoot and ringing.

I would look at adding some type of bus driver between the DUE and your SPI bus. Look at TI's 74LVC244. It is a dual 4bit tristate driver with active low enable. I use it for 5V to 3.3v translation on SPI. With 3.3V Vcc, it can drive the bus with 24mA. And you can design it to isolate bad acting SPI slaves.

Just connect your !CS pin for the slave to the !OE, and put weak pullups/pulldowns on the slave side of the tristate drivers to hold SCK, MOSI at the 'rest' state, Low for Mode0, Mode 1, High for Mode2 or Mode3. Feed MISO in to the '244 and connect that bit's output to the DUE's MISO pin.

Chuck.

4

chucktodd:
The DUE has weak drivers on it's pins. The spec's say some pins can only Source 3mA, Other 15mA.

To me it looks like you have long wires on your SPI bus. How is your SPI bus lain out? multiple stubs or one bus?

What exactly do you mean by multiple stubs vs one bus? And my wires are about 6 inches from the due to the flash chip, and another 6 inches to the LCD from there... doesn't seem too unreasonable.

chucktodd:
I would look at adding some type of bus driver between the DUE and your SPI bus. Look at TI's 74LVC244. It is a dual 4bit tristate driver with active low enable. I use it for 5V to 3.3v translation on SPI. With 3.3V Vcc, it can drive the bus with 24mA. And you can design it to isolate bad acting SPI slaves.

I'll look into it, but wow.. Is this needed for any kind of multiple SPI device usage with the due? Seems like a big design flaw... I've moved this exact circuit from an Arduino Mega, which it worked perfectly on, so I think your assumption of it being the due's weak drivers is what's causing it.

Thanks a lot for the help!

Pat

5

I use a w5100 ethernet IC and a SD card on my Due SPI bus with no problem.

edit: That is if I don't set D10 or D4 as OUTPUT.