Post Go back to editing

Two ADXL372 Slaves on one SPI Interface. One Works, one doesn't

Hello everyone,

I'm using two ADXL372 Evaluation boards on one USB-to-SPI device by FTDI (UM232H-B-W, to be exact). The ADXL372's are being powered with 2.5V and the UM232H has logic levels that accept 2.5V amplitudes.

I'll provide Oscilloscope graphs shortly, als soon as I'm back at Uni. My best guess would be the Logic levels, but I'ce seen erratic behaviour on the MISO-Line aswell.

Both ADXL372 are cofigured exactly the same because I'm using the following function to do so, just with a different Chip Select:

DATA = [ADXL.WriteTo(ADXL.RESET) ADXL.INIT_RESET];

DATA = [ADXL.WriteTo(ADXL.INT1_MAP) ADXL.FIFO_FULL_INT1];

DATA = [ADXL.WriteTo(ADXL.FIFO_SAMPLES) 0x5E];

DATA = [ADXL.WriteTo(ADXL.HPF) ADXL.HPF_CORNER_3];

DATA = [ADXL.WriteTo(ADXL.FIFO_CTL) (ADXL.FIFO_FORMAT_Z | ADXL.FIFO_MODE_STREAM | ADXL.FIFO_SMPLS_8)];

DATA = [ADXL.WriteTo(ADXL.TIMING) ADXL.ODR_6400];

DATA = [ADXL.WriteTo(ADXL.MEASURE) ADXL.OR([ADXL.LOW_NOISE ADXL.BANDWIDTH_3200])];

DATA = [ADXL.WriteTo(ADXL.POWER_CTL) ADXL.MODE_FULL];

DATA = [ADXL.ReadFrom(ADXL.DEVID_AD) 0 0 0 0 0];

DATA = [ADXL.ReadFrom(ADXL.POWER_CTL) 0];

After Configuring each channel I'm reading out the first four registers and STATUS register (0x00 - 0x04) as well as the POWER_CTL register. 

The first one (Channel A) reads the first five registers and data perfectly fine. The second one (Channel B) returns only 0xFF for every byte read.

Do the SPI-Lines need special termination on shielded cables <1.5m ?

Top Replies

Parents
  • I've been tinkering for a day more now. Things I have learned:

    1) With Channel A's CLK-Line disconnected,

         I'm able to read Channel B no problem.

    2) With all connections proper

         I've tried to code everything in Visual Studio. Basiacally the same thing but everything I write is being read instantly afterwards. This is the result:

    Read Device ID's and STATUS register:
    DEVICE_AD : AD | AD
    DEVICE_MST: 1D | 1D
    PARTID : FA | FA
    REVID : 02 | 02
    STATUS : 41 | 40
    ----- ----- ----- -----

    Configure Device and read configuration Values back:
    INT1_MAP : 00 | 02
    FIFO_SAMPLES : FE | 90
    HPF : FF | 03
    FIFO_CTL : B4 | 23
    TIMING : 01 | 80
    MEASURE : FF | 0C
    POWER_CTL : BF | 03
    STATUS : FF | 40
    ----- ----- ----- -----

    [Register : read value | desired value]

    Note: I can read the device IDs and STATUS register clearly. Writing/Reading from any of the configuration registers yields... that.

    I'm at a loss... Do the ADXL372's have some undocumented behaviour when used in a multi-slave configuration?

    CODE Snippet:

    data_out[0] = 0x01;
    ftStatus = SPI_Write(ftHandle, data_out, uint8(1), &data_written, 0b010);
    ftStatus = SPI_Read(ftHandle, data_in, uint8(5), &data_written, 0b100);
    printf("Read Device ID's and STATUS register:\n");
    printf("DEVICE_AD : %02X | AD\n", data_in[0]);
    printf("DEVICE_MST: %02X | 1D\n", data_in[1]);
    printf("PARTID : %02X | FA\n", data_in[2]);
    printf("REVID : %02X | 02\n", data_in[3]);
    printf("STATUS : %02X | 40\n", data_in[4]);
    printf("----- ----- ----- -----\n\n");


    printf("Configure Device and read configuration Values back:\n");

    // WRITE to INT1_MAP
    data_out[0] = 0x3B << 1;
    data_out[1] = 0b00000010;
    ftStatus = SPI_Write(ftHandle, data_out, w_data_len, &data_written,0b110);

    // READ from INT1_MAP
    data_out[0] = (0x3B << 1) +1;
    ftStatus = SPI_Write(ftHandle, data_out, uint8(1), &data_written, 0b010);
    ftStatus = SPI_Read(ftHandle, data_in, uint8(1), &data_written, 0b100);
    printf("INT1_MAP : %02X | %02X\n", data_in[0],data_out[1]);

    SCOPES:

    Yellow MOSI
    Green MISO
    Blue CLK
    Orange CS

     This picture shows a write to the 0x38 register. What is happening on the MISO-Line? It seems there is Data being pushed out, but why? CS was released and reasserted before this byte started. No other slave-line was asserted.

  • Hi  , 

    Thanks for all the details provided. 

    I think you either took an image of the [0x3A, 0x23] write command sequence or there is an issue in the data transmitted. From the scope image, I see the first MOSI command data_out[0] is not 0x76 (0x3B<<1), and the second is not 0x02, which should be the value you are writing to the register 0x3B based of your code (data_out[1] = 0b00000010;). I would start from there. Also below the table you say :  This picture shows a write to the 0x38 register. Just want to make sure you meant 0x3B... Too many number :) ! 

    Regarding to your question: What is happening on the MISO-Line? The datasheet says in page 26: "Ignore data transmitted from the ADXL372 to the master device during writes to the ADXL372." I would make sure to pull up/down all communication pins, if the MCU does not take care of this. 

    I hope it helps, 

    Pablo.  

  • Ah, yes that one's on me. The picture is unrelated to the code above (will fix that in post) and the actual register is 0x3A (which makes 0x74 for a write) and the value is 0x23. Should've mentioned that.

    I'll try some pull down resistors tomorrow and report back.

    Thank you already! The line from the datasheet completely went over my head and clears many things up!

  • Hi Quintus, 

    No problem glad to help, let me know how it goes tomorrow. 

    I am curious, what is the last 4bit binary value at the end of each read/write? For example: SPI_Write(ftHandle, data_out, uint8(1), &data_written, 0b010);

    I was not able to follow that, and it changes from line to line. 

    Pablo. 

  • Hello Again,

    So i've tried the following: 

    1) Pull Down Resistor 1k: Can't read IDs anymore

    2) Pull Down Resistor 22k: same as 1)

    3) Pull Up Resistor 1k: IDs are 0xFF

    4) Pull Up Resistor 22k: same as 3)

    And with all those modifications, Slave A still works normally and by removing Slave A's CLK line Slave B works normally. 

    The Communication Functions are from the library for the UM232H. The last three Bits configure the Chip Slec behaviour. 

    0b1xx - Releases the Configured CS after the Communication is over

    0bx1x - Asserts the Configured CS before the Communication starts

    0bxx1 - Transmitted Data length is in Bits (0 = Length is in Bytes)

  • Hi Quintus, 

    let me double check with our digital design team, if they have any recommendation. 

    Pablo. 

  • Hi Quintus, 

    Our design team said they have found a similar issue on the ADXL312, luckily there is a way to prevent this to happen. See the bellow: 

    The design team recommended applying this solution for the ADXL372 as well. 

    I hope it helps, 

    Pablo. 

Reply Children
  • Hey Pablo!

    sorry, that it's been a few days, but I've ordered and tested your solution.

    ...and it worked, in a way! 

    I've built up the adjustment as suggested with the OR-Inputs on the /CS and MOSI lines. That didn't solve my problem, BUT I remembered, that I can get proper communication with the CLK-Line disconnected. So instead of the MOSI-Line I used the CLK-Lines for both Slaves AND IT WORKED!

    Thank you so very much!

    The next issue I'm having is no longer related to the Serial-Communication itself, so I'll consider your answer as solution for this thread.

    Now I'll have to find out, why my sensor data bahaves as weird as it does.

    Spoilers: Channel A has weird spikes, where Channel B doesn't

  • Hi Quintus, 

    sorry for the delay as well and I am glad it works! 

    the spikes I think are due to a tone issue present on this part at high sampling rates. If you do a noise spectrum analysis, this tone should appear at 1/5 ODR (output data rate). The typical RMS noise on the datasheet (3LSB rms) already covers this issue. 3LSB rms= 0.3g rms. Converting to peak to peak: 0.3g rms * 6.6 = ~2g peak to peak. 

    I hope this helps , 

    Pablo. 

  • Hi,

    I am happy that your solution works but it is different of figure 39 of the datasheet...which specifies to let SCLK low when not used.

    I am facing a nearly similar issue: sometimes the ADXL372 does not answer at the power up. It seems that sometimes the ADXL372 goes to the I2C mode instead of the SPI mode despite there is no falling edge on pin MOSI/SDA while CS/SCL is high.

    Is there a specific state order during the ADXL372 power up sequence to be sure that the component always selects the SPI mode?

    Best regards

    Mich