1
\$\begingroup\$

I'm currently trying to interface a CS5530 ADC to a raspberry pi 4b 8g using SPI. When I attempt to communicate with the ADC I repeatly get return bits that make no sense and am running out of ideas to trouble shoot. When using the Spidev-test script I'm recieving the following response:

spi mode: 0x4 bits per word: 8 max speed: 2000000 Hz (2000 KHz)

TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D
RX | FF FF FF FF FF FF FF F8 00 00 00 27 F8 00 00 00 27 F8 00 00 00 27 FF FF FF FF FF FF FF FF FF FF

As you can see there's something causing the MISO line to be recieving incorrect bits. If I use a jumper from MOSI to MISO to the bits return as should be expected. I've tried different clk speeds while staying under 2MHz as that is specified as the make clk speed in the cs5530 data sheet. I'm also recieving similar junk back using the spidev libary in python.

I'm thinking the most likely problem I have is for some reason the clk on the rpi isn't producing a proper signal. I don't own logic analyser (thinking I'll properlly have to order one) so I've mapped the signal the best I can using piscope.

this image shows what looks like to me the clk line not functioning as you should expect. line in

I'm a novice at this sort of thing but it looks to me that the clk line is all over the show instead of regular sine wave you'd expect to see there. I'm not sure if this is what's casuing me issues or if it's due to the limitations of piscope.

this imagine also shows similar behaviour happening when I'm shorting MOSI and MISO to test the lines. enter image description here

So while I think I've found the cause of my issues I'm about out of ideas of what could be causing this issue and how to fix it. So far all the things I've tried when trying to troubleshoot this is:

  • Swapping out Raspberry Pi's - Problem presists exactly the same.
  • Swapping out cs5530
  • checked all my solders on the prototyping board and continuity between all points, test resistor values and cap's are all at correct values. Swapped crystals due to not having a scope to test it.
  • Tested the cs5530 at both 3v and 5v modes (using an external power supply)
  • Grounded rpi to external power supply
  • Tried running a cs5530 off rpi 3.3v supply
  • set core_freq=250 on rpi
  • set dvfs=2 to rpi to prevent any issues caused by core being under voltaged
  • tested on spi0 (CE 0 and 1) and spi1

temp was 53 degrees when the tests in the pictures where done so I think I can rule out thermal throttling as well. At this point I'm completely out of ideas what else to try. Might be worth noting that I am booting off a high quality 16gb USB flash drive, I haven't bothered coping the img to a sd card just yet as I wouldn't have thought that this would be causing any problems but I might try it just to fully rule that possiblity out.

Thanks in advance for any help, hoping that there's someone much smarter than me out there that can shine some light on this for me.

Cheers

\$\endgroup\$
14
  • 2
    \$\begingroup\$ I think your scope is lying to you - it looks like the sample rate is too slow. A sine wave is not what is expected! At a quick guess, I'd suggest you try changing the CPHA option. Along with CPHA you have 4 combinations. Only 1 will work. \$\endgroup\$
    – Kartman
    Sep 12, 2021 at 3:28
  • \$\begingroup\$ Ah, let me see. (1) You said the following: "If I use a jumper from MOSI to MISO to the bits return as should be expected, ..." Your SPI loop back test shows that Rpi4B SPI software and hardware are "more or less" working OK. \$\endgroup\$
    – tlfong01
    Sep 12, 2021 at 4:24
  • \$\begingroup\$ (2) I skimmed the datasheet :Low-Cost, Low-Noise 24-bit ADC - Cirrus Logic cirrus.com/products/cs5530, and found the following features need to be looked at very closely: (a) Simple three-wire serial interface, SPI and Microwire compatible, (b) Schmitt-trigger on serial clock (SCLK), ... (d) Selectable word rates: 6.25 to 3,840 sps. Both comments "Schmitt triggered SCLK" and "Word rates 6.25 to 3,840 sps" are spec comments not usually found in ADC data sheets. \$\endgroup\$
    – tlfong01
    Sep 12, 2021 at 4:37
  • 2
    \$\begingroup\$ Read this: raspberry-projects.com/pi/programming-in-c/spi/… Pay particular attention to the SPI_Data_Mode, you are probably clocking on the wrong edge of the clock. This requirement depends on the slave device, and it looks like you need - bcm2835_spi_setDataMode(BCM2835_SPI_MODE1); \$\endgroup\$
    – Jack Creasey
    Sep 12, 2021 at 5:23
  • 1
    \$\begingroup\$ Thanks tlfong01, I'm running in 00 mode. If my understanding is correct single conversion and continuous conversion are selected in the config register. I can't even get that far to choose which mood to operate in (single conversion is default I think). When I try and send 15 0xff bytes and 1 0xfe byte to initiate the chip I'm just get junk back still. \$\endgroup\$
    – Jake Wansink
    Sep 12, 2021 at 7:45

2 Answers 2

Reset to default
1
\$\begingroup\$

When you plug the jumper shorting MOSI/MISO you get the same sequence back. It is so called loopback test.

As you can see there's something causing the MISO line to be recieving incorrect bits.

I don't see anything wrong, the SPI device has responded. If it wasn't, you would get all bytes FF or 00.

I'm a novice at this sort of thing but it looks to me that the clk line is all over the show instead of regular sine wave you'd expect to see there.

For sure, no sine wave is expected on SPI signals, rather square pulses as you get it.

To solve the mistery you should study the device driver, the initialization sequence. You do trace this on SPI and you compare the response from the device according to the datasheet.

In my opinion the hardware connection of SPI is not an issue here.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ Thanks Marko. Sorry I mixed up my wave forms in my description, clearly it should be a square wave in expecting to see however it's my understanding that on the clk line the timings of this wave should be show an equal spaced high low pattern which if the pi scope is too be believed isn't the case here. I agree all other lines of the spi are working fine. \$\endgroup\$
    – Jake Wansink
    Sep 12, 2021 at 8:26
  • 1
    \$\begingroup\$ I've sent 15 0xff bytes and 1 0xfe bytes which are used to reset the chip however the return results from this are still junk and doesn't help at all. This is why I'm thinking it's an issue with the clk line and the timing being out of sync \$\endgroup\$
    – Jake Wansink
    Sep 12, 2021 at 8:29
  • 1
    \$\begingroup\$ @JakeWansink You should link some document, driver code,..etc. Where it is stated that 15 0xff bytes and 1 0xfe bytes are the reset sequence, and what the response should be. \$\endgroup\$
    – Marko Buršič
    Sep 12, 2021 at 8:41
0
\$\begingroup\$

So finally figured out what my problem was with this. Once I started to get some bits from the ADC I thought I was on the wright track and stuck with my circuit layout thinking it was the SCLK that was out of sync.

I brough an analyser and realised this wasn't the case and that it was actually working fine piscope was just too slow to map it properly.

The fault I ended up having is that I was driving the VD+ at 3.3v instead of a flat 3v as .3v was stated as max tolerance for VD+. Obviously I was riding it a little too close to the line with this and and was getting bad bits back from this. I redesigned how I was powered everything in the circuit and it's all behaving as expected now.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.