Electronic – Daisy-chaining two ADC with SPI protocol

adcanalogdigital-communicationsraspberry pispi

I'm trying to configure and read two ADCs (MAX11156) with a RaspberryPi. The ADCs are daisy-chained together. For the communication, I'm using python code with the spidev library. The driver is properly installed and SPI0 is enabled. However, the received data doesn't make sense to me at all and I'm trying to figure out, whether it's a software or a hardware issue.

The data I have received, resembles what I measured with an oscilloscope. Having nothing connected to the analog input, I receive following raw bytes for a period of 10 samples:

[63, 255, 0, 0, 0]      decoded: -2.0481V -4.0960V
[192, 1, 63, 255, 255]  decoded: 2.0481V 4.0960V
[192, 1, 63, 255, 255]  decoded: 2.0481V 4.0960V
[192, 0, 31, 255, 255]  decoded: 2.0480V -0.0000V
[63, 255, 32, 0, 0]     decoded: -2.0481V 0.0000V
[63, 253, 224, 0, 0]    decoded: -2.0483V 0.0000V
[63, 254, 0, 0, 0]      decoded: -2.0482V -4.0960V
[192, 3, 223, 255, 255] decoded: 2.0485V -0.0000V
[192, 3, 31, 255, 255]  decoded: 2.0484V -0.0000V
[192, 3, 223, 255, 255] decoded: 2.0485V -0.0000V

For the configuration, I'm sending two times the same configuration byte (1,0,0,0,0,0,0,0).

After configuration I give the ADCs some time to convert. To read the data, I'm transferring 5 bytes of 255 (since the register is expecting a logic high during transmission). I'm expecting 5 bytes, since the ADCs have a 18bit resolution, so 36 bits in total. The last 4 bits are ignored.

This is my code:

import time
import spidev

def configuration(b7,b6,b5,b4,b3,b2,b1,b0):
    msg = (b7 << 1)  + b6   #first  2 bits: 10 - MODE: Daisy-Chain Mode, no busy indicator
    msg = (msg << 1) + b5
    msg = (msg << 1) + b4   #next   2 bits: 01 - REF:  Reference Mode 1
    msg = (msg << 1) + b3
    msg = (msg << 1) + b2   #next bit:       0 - SHDN: Normal Mode
    msg = (msg << 1) + b1   #next 3 bits:  000 - Reserved
    msg = (msg << 1) + b0
    return msg

def decodeDaisyChain(ans):
    #accepting list of 5 bytes for two 18 bit in a range of +-5V chained together
    val1 = ((((ans[0] << 8) + ans[1]) << 8) + ans[2]) >> 6
    val2 = (((((ans[2] & 0b00111111) << 8) + ans[3]) << 8) + ans[4]) >> 4
    val = ([val1,val2])

    # convert to voltage (-5,+5V)
    Vref = 4.096
    step = Vref*2 / 2 ** 18  # in Volts
    zero = 2 ** 18 / 2
    ans = [(x - zero) * step for x in val]
    return ans


spi = spidev.SpiDev()
spi.open(0,0)
spi.mode = 1    #polarity: 0 phase: 1
spi.cshigh = True



# ADC Configuration
msg = configuration(1,0,0,0,0,0,0,0)

try:
    while True:
        spi.writebytes([msg,msg])
        time.sleep(0.0027)
        ans = spi.xfer([255,255,255,255,255])
        #ans = spi.readbytes(5)    # optional method. Didn't work either
        val = decodeDaisyChain(ans)
        print("%6.4fV %6.4fV" % (val[0],val[1]))
        time.sleep(0.1)
finally:
        spi.close()

Best Answer

Thank you for all your help. Unfortunately neither of the suggestions fixed my problem. On point was indeed the timing. I adjusted the SPI clock-rate to cope with the 50MHz of the ADC. With the adjusted clock-rate I got a proper answer from one ADC. Furthermore I checked the timing constraints with the Oscilloscope and they were all good 1. Also, I tried to read the ADCs asynchronously, which confirmed the assumption, that one ADC is not working properly. Since the board was already built, I was limited in testing the ADCs one at the time I ended up building a new board with a different ADC.

^{Oscilloscope Screenshot. CNVST: blue, SCLK: yellow, DIN: green, DOUT: red}

Related Solutions

Electronic – SPI slave unreliable on PIC18LF2550

As Sphero Pefhany notes, the list of silicon errata for the PIC18F2455/2550/4455/4550 family is extensive. In particular, erratum 37 (applicable to three revisions, including my revision B5 chips) reads

If configured in SPI Slave mode, the MSSP may not successfully recognize data packets generated by an external master processor. This applies to all SPI Slave modes (CKE/CKP = 1 or 0), whether or not slave select is enabled (SSPM<3:0> = 010x).

Work around: Insert a series resistor between the SPI master Serial Data Out (SDO) and the corresponding SPI slave Serial Data In (SDI) input line of the microcontroller. The required value for the resistor varies with the application system’s characteristics and the process variations between the microcontrollers. Experimentation and thorough testing are encouraged.

I assume the purpose of this resistor is to slow down the data transition, to make sampling at the end of the clock period (more) reliable.

This bug has been fixed in the latest (B7) revision.

Electronic – How to receive multiple bytes on SPI with CS being held low

I did the same thing on a AT32UC3C0512 (yet, I was the master which probably made it a bit easier).

The idea is probably the following (if you're using the ASF framework, it should work in slave mode as well):

Call spi_get(SPI)
Loop until spi_is_rx_ready(SPI) or until you run into a timeout
Call spi_get(SPI) for the next byte (or 10 byte or whatever you set the spi_rx register size to be)
Do this a few times until you received all bytes

Here's some code as a starting point, hope it helps a little:

volatile avr32_spi_t *spi = device->spi;
unsigned int timeout = SPI_TIMEOUT;    

timeout = SPI_TIMEOUT;
while (!spi_is_rx_ready(spi)) {
    if (!timeout--) {
        tmc260_deselect_device(device);
        return ERR_TIMEOUT;
    }
}
// Store the received data
rx_msb = spi_get(spi);

I'm not quite sure what has to be done to reset the flag which is set once a byte was received. I would assume simply reading the rx register should do the trick.

It should also be possible to port this code to using interrupts (call the ISR whenever a byte was received/RX register is full).

From the AT32UC3C0512 datasheet:

The SPI waits for NSS to go active before receiving the serial clock from an external master. When NSS falls, the clock is validated on the serializer, which processes the number of bits defined by the Bits Per Transfer field of the Chip Select Register 0 (CSR0.BITS). These bits are processed following a phase and a polarity defined respectively by the CSR0.NCPHA and CSR0.CPOL bits. Note that the BITS, CPOL, and NCPHA bits of the other Chip Select Registers have no effect when the SPI is configured in Slave Mode. The bits are shifted out on the MISO line and sampled on the MOSI line. When all the bits are processed, the received data is transferred in the Receive Data Register and the SR.RDRF bit rises. If the RDR register has not been read before new data is received, the SR.OVRES bit is set. Data is loaded in RDR even if this flag is set. The user has to read the SR register to clear the SR.OVRES bit.

As far as I understand, a flag will be set after 8 to 10 databits. For a first try, you will need to read the data and see if the flag gets raised a second time, even if CS doesn't get asserted a second time.

An alternative solution

You can also use an interrupt on the SCK line (depending on the mode on the rising or falling edge) and sample the data "manually". Once you discover a condition where SCK rises (or falls) and CS is high, you are outside the "normal" datatransfer and you start a new reception.

Best Answer

Related Solutions

Electronic – SPI slave unreliable on PIC18LF2550

Electronic – How to receive multiple bytes on SPI with CS being held low

Related Topic