Raspberry Pi SPI fault – returning incorrect bits

Ask QuestionAsked todayActive todayViewed 53 times1

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. 

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. 

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.

Cheersadcraspberry-pispiShareCiteEditFollowFlagedited 9 hours agoasked 11 hours agoJake Wansink111 bronze badge New contributor

• 2I 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. – Kartman 9 hours ago
• 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. – tlfong01 8 hours ago    
• (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. – tlfong01 8 hours ago   
• (3) Anyway, I skimmed the datasheet: CS5530 24-bit ADC with Ultra-low noise Amplifier Datasheet – Cirrus Logic, statics.cirrus.com/pubs/proDatasheet/CS5530_F3.pdf. I read the following sections more carefully: 2.2.4 Reading and writing On-chip Registers, 2.3.2 System Reset Sequence, 2.3.3 Input Short, 2.3.7 Word Rate Select, 2.5.1 Single Conversion Mode. I will later suggest how to troubleshoot this Cirrus Logic 24-bit ΔΣ ADC with reference to the above sections. – tlfong01 8 hours ago   
• 2Read 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); – Jack Creasey 7 hours ago
• (4) Now let me point out a couple of setup/config stuff you need to pay attention: First SPI modes: SPI Wikipedia specifies 4 modes, 00, 01, 10, 11. Almost always manufacturer/vendors’ default is 0,0. Some very old devices do use modes other than mode 00, I read the C5530 datasheet Fig 1 on SPI timing which shows the following sequence: (a) CS first goes Low, to select the device and everybody wakes up and starts working, (b) On the next SCLK going High (rising edge), (c) SDI reads first byte (never mind MSB or whatever). / to continue, … – tlfong01 7 hours ago   
• This timing sequence is defined as 0, 0 mode. (5) Rpi4B OS’s build in SPI by default is also mode 0,0. So do not mess with this SPI operation mode in your Python program. – tlfong01 7 hours ago    
• (5) Single shot or continuous mode: I would recommend to test the ADC using single shot mode. The reason is that continuous mode is usually more difficult to get the timing right. You might like to skim my answer of the following Rpi SE Q&A to see how I setup Rpi SPI, why and how I use single mode read/write a config register as a first troubleshooting step on testing another TI24 bit ΔΣ ADC．How can Rpi read TI ΔΣ 24-bit ADS1256 ADC Data， raspberrypi.stackexchange.com/questions/99353/… – tlfong01 6 hours ago    
• 1Thanks 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. – Jake Wansink 5 hours ago
• (5) OK. Let us stick to SPI (0, 0) mode. (6) Yes, configuring single conversion mode is for later testing stages, not for now. We can deal with that later. (7) What you are doing: 　＂2.2.4 Reading and writing On-chip Registers, 2.3.2 System Reset Sequence, 2.3.3 Input Short – tlfong01 4 hours ago   
• (5) OK. Let us stick to SPI (0, 0) mode. (6) Yes, configuring single conversion mode is for later testing stages, not for now. We can deal with that later. (7) What you are doing: “sending 0xfe and oxff etc and hope to get something back is still “over ambitious”. A more humble goal is to write “something” to a write/read register and immediately read that “something” back (sort of “pinging”). (8) The register to try should be awake without any initiation and/or reset. I usually try out the “config” register first. /. to continue, …, – tlfong01 4 hours ago   
• @Jake Wansink, I would suggest to first try what is described in 2.2.4 Reading and writing On-chip Register. That is, send 0x02, then 0x80000000 (or some random test data, like 0x5a, 0xa5 bytes etc) to write to the register and then read it back. It is only after you have confirmed that you can write/read a register successfully, then you try the (more complicated) reset thing. – tlfong01 4 hours ago    
• One more thing, you need to stare at Fig 7, its first two parts, for at least 3 minutes, to get a rough idea of what is going on there. You can read the last more complicated bottom part later. – tlfong01 3 hours ago    
• Last thing before I go, you might like to confirm my guess that, to write to the gain register, you start with 0x02, and to read back, you start with 0xa2. Good luck and have a nice weekend. Cheers. – tlfong01 3 hours ago   

Add a comment

1 Answer

ActiveOldestVotes1

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.ShareCiteEditFollowFlaganswered 5 hours agoMarko Buršič20.6k22 gold badges1515 silver badges3030 bronze badges

• 1Thanks 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. – Jake Wansink 4 hours ago
• 1I’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 – Jake Wansink 4 hours ago
• 1@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. – Marko Buršič 4 hours ago

Add a comment