ADS131M08: SPI communication using IOCTL

Hello nkumar,

I'm not familiar with IOCTL as a concept but my quick research makes it seems like an abstraction or the act of trying to communicate with a device or peripheral. Now, this doesn't help me much because I can't figure out what exactly you need help with yet: the SPI protocol, or getting an abnormal status.

SPI Protocol:

To start, I'm looking at your code and it looks like you're relying on ioctl(...) to organize a correct SPI frame to communicate to your device. The example code you referenced had the 6 steps of this code's purpose:

void spiSendReceiveArrays(const uint8_t dataTx[], uint8_t dataRx[], const uint8_t byteLength)
{
    /*  --- INSERT YOUR CODE HERE ---
     *
     *  This function should send and receive multiple bytes over the SPI.
     *
     *  A typical SPI send/receive sequence may look like the following:
     *  1) Make sure SPI receive buffer is empty
     *  2) Set the /CS pin low (if controlled by GPIO)
     *  3) Send command bytes to SPI transmit buffer
     *  4) Wait for SPI receive interrupt
     *  5) Retrieve data from SPI receive buffer
     *  6) Set the /CS pin high (if controlled by GPIO)
     */

    // Require that dataTx and dataRx are not NULL pointers
    assert(dataTx && dataRx);

    // Set the nCS pin LOW
    setCS(LOW);

    // Send all dataTx[] bytes on MOSI, and capture all MISO bytes in dataRx[]
    int i;
    for (i = 0; i < byteLength; i++)
    {
        dataRx[i] = spiSendReceiveByte(dataTx[i]);
    }

    // Set the nCS pin HIGH
    setCS(HIGH);
}

So, if your ioctl(..) does not do these 6 things, then I'm not surprised you're getting incorrect data from the device as you're expected to configure this. 

Incorrect STATUS value:

So it sounds like you're sending a NULL command to get STATUS. What do you get back? If you get 0b0 back, then you can be confident that your SPI frame is set up incorrectly and you might need to use a logic analyzer to probe and monitor the SPI waveforms (eg. TX, RX, CS, SCLK) to see what is happening.

If you get something nonzero, then you can use the STATUS word as information. The default might be 0x0500 but seeing if the SPI interface lock indicator (LOCK or bit [15]) could help give you some information what is going wrong.

Hope this helps.

Best,

-Cole

Thank you Cole!

When I send null (ie. 4 bytes of zeros), I am getting 0x00, 0x28, 0xFF, 0x00,  which looks like it is content of reg 0x00. Then, turns out not matter what register read, I always get 0x00, 0x28, 0xFF, 0x00, for example Reg read at address 0x1: (0xA000 | (0x1 << 7).  Please see attached screen shot of logic analyzer.

Sending zeros

Reading reg 0x1

Regarding the spiSendReceiveArrays() example, I am still investigating how to mimic steps#1-6 using ioctl(). The CS pin is tied to GND for now. Also, not clear how step#4, is shown in that example.

Thanks!

Hello nkumar,

This is pretty strange. You haven't configured the mode register right?

If I translate 0x28FF, the most confusing part is the Data Word length. It looks like you're clocking for 24 bits, but it expects 16 bits. I might be wrong, feel free to correct me.

The only way this is changed is from the MODE register (addr:0x2) is changed. It would explain the reg map CRC indicator. 

Can you initiate a RESET command using the pin (or in software if you feel confident) and then repeat the read command?

As a sanity check, you should check that there's no issues with your read command by reading the ID register to make sure you're reading the correct value? It does look like your protocol is good though, the timing is what I expect. But its always good to do a sanity check.

Best,

-Cole

Thank you, Cole!

I have not configured mode register - the values should be default on reset. What is confusing, is that sending NULL should respond STATUS reg values, not 0x28FF. I can't figure out why it is stuck on that value.

I reset SYNC/RESET via gpio pin which I toggle in the beginning. I checked DRDY on logic analyzer, it is about 250usec apart.

Hello nkumar,

What is confusing, is that sending NULL should respond STATUS reg values, not 0x28FF. I can't figure out why it is stuck on that value.

In my previous post, I assumed that 0x28FF is the register value. The values are irregular but not so incorrect that I can pinpoint the issue. In other words, I can't prove your SPI frame formatting is an issue from the previous post.

If we want to prove that you can successfully communicate with the device, please read ID register.

0x28FF:

With that being said, I just realized you are receiving 0xFF2800, not 0x28FF00, according to your logic analyzer shots. From the datasheet:

The MSB is clearly 0xF from the logic analyzer. This makes me think that something is very wrong in the construction of your SPI frame.

For a very basic question. Are there any other devices sharing the SPI lines? As in, are the MSIO and MOSI lines only connected to the ADS131M0x and your microcontroller? I noticed the nCS line (assuming it is labeled SS in the logic analyzer shots) is tied to GND.

Best,

-Cole