Skip to main content
Graduate
November 11, 2024
Question

Problem with SPI and ADXL345

  • November 11, 2024
  • 5 replies
  • 3636 views

 

FilipF303RE_0-1731342474048.png

FilipF303RE_1-1731342489083.png

Hi, I’m having trouble reading measurements from the ADXL345 using SPI. I’ve attached a picture from the debugger that shows a view of the variables. The SPI is configured as master full duplex, and I’ve included a screenshot showing the SPI configuration. The SCK is connected to SCL, MISO to SDO, MOSI to SDA, and CS is connected to a configured output. I’m looking for help because I can’t figure out how to solve this issue.

int main(void)

{

void adxl_init(void);

while (1)

{

 

adxl_read(0x32);

 

// x = (data_rec[1]<<8|data_rec[0]);

// y = (data_rec[3]<<8|data_rec[2]);

// z = (data_rec[5]<<8|data_rec[4]);

 

x = ((data_rec[1] << 8) | data_rec[0]);

y = ((data_rec[3] << 8) | data_rec[2]);

z = ((data_rec[5] << 8) | data_rec[4]);

 

 

xg = x*.0078;

yg = x*.0078;

zg = x*.0078;

}

}

void adxl_write (uint8_t address, uint8_t value)

{

uint8_t data[2];

data[0] = address|0x40; // multibyte write

data[1] = value;

HAL_GPIO_WritePin (GPIOB, GPIO_PIN_6, GPIO_PIN_RESET); // pull the cs pin low

HAL_SPI_Transmit (&hspi2, data, 2, 100); // write data to register

HAL_GPIO_WritePin (GPIOB, GPIO_PIN_6, GPIO_PIN_SET); // pull the cs pin high

}

void adxl_read (uint8_t address)

{

address |= 0x80; // read operation

address |= 0x40; // multibyte read

HAL_GPIO_WritePin (GPIOB, GPIO_PIN_6, GPIO_PIN_RESET); // pull the pin low

HAL_SPI_Transmit (&hspi2, &address, 1, 100); // send address

HAL_SPI_Receive (&hspi2, data_rec, 8, 100); // receive 6 bytes data

HAL_GPIO_WritePin (GPIOB, GPIO_PIN_6, GPIO_PIN_SET); // pull the pin high

}

void adxl_init(void)

{

adxl_write (0x31, 0x01);

adxl_write (0x2d, 0x00);

adxl_write (0x2d, 0x08);

}

void tx_com(uint8_t *tx_buffer, uint16_t len)

{

HAL_UART_Transmit(&huart2, tx_buffer, len, 1000);

}

 

 

 

    This topic has been closed for replies.

    5 replies

    Super User
    November 11, 2024

    Show a schematic of your hardware.

    Please see the Posting Tips for how to properly post source code:

    https://community.st.com/t5/community-guidelines/how-to-write-your-question-to-maximize-your-chances-to-find-a/ta-p/575228

     


    @FilipF303RE wrote:

    I’m having trouble reading measurements from the ADXL345 using SPI


    What "trouble", exactly?

    Can you successfully read the Device ID register ?

    Are you sure CPOL and CPHA are correct?

    Have you used an oscilloscope or logic analyser to check what's actually happening on the wires?

     

    Graduate
    November 12, 2024

    I tried this code with breakpoints, but the debugger was not reading the ID variable. Do you have any suggestions on how I could do this?

     

    void adxl_read ()

    {

    uint8_t address = 0x00;

    address |= 0x80;

    uint8_t id;

    HAL_GPIO_WritePin (GPIOB, GPIO_PIN_6, GPIO_PIN_RESET); // pull the pin low

    HAL_SPI_Transmit (&hspi2, &address, 1, 100); // send address

    HAL_SPI_Receive (&hspi2, &id, 1, 100); // receive 6 bytes data

    HAL_GPIO_WritePin (GPIOB, GPIO_PIN_6, GPIO_PIN_SET); // pull the pin high

     

    }

    Super User
    November 12, 2024

    Again, see the Posting Tips for how to properly post source code:

    https://community.st.com/t5/community-guidelines/how-to-write-your-question-to-maximize-your-chances-to-find-a/ta-p/575228

     


    @FilipF303RE wrote:

    the debugger was not reading the ID variable.


    What do you mean by that ?

    Graduate
    November 11, 2024

    FilipF303RE_0-1731351005866.pngFilipF303RE_1-1731351025277.png

    https://www.analog.com/media/en/technical-documentation/data-sheets/adxl345.pdf 

    FilipF303RE_2-1731351273991.png

    As you can see in the attached debugger screenshot, the reading from the accelerometer — specifically, the X, Y, and Z position measurement from the data_rec buffer array — is incorrect. I don’t have an oscilloscope. I’ve shared images from the ADXL345 datasheet PDF; if you could kindly check whether it’s configured correctly, I’d appreciate it. I have attached the schematic of my microcontroller in a PDF, along with a screenshot. The connections are as follows: D13 to SCL, D12 to SDO, D11 to SDA, and D10 to CS.

    Super User
    November 11, 2024

    Again, Can you successfully read the Device ID register ?

    If you can't do that, then there's something fundamentally wrong with the comms - so no point worrying about X,Y,Z values!

    Graduate
    November 15, 2024

    I tried to read the ID using TransmitReceive, but it didn’t work; after the transmission, it shows the address 0x00. Does this mean that I have incorrectly configured the SPI registers? It's strange because I configured them as described in the text documentation. So, the only possible troubleshooting method is using an oscilloscope?

    Explorer
    November 15, 2024

    > It's strange because I configured them as described in the text documentation.

    Or so you think.
    We have all been there.

    > So, the only possible troubleshooting method is using an oscilloscope?

    Rigol has quite good and affordable scopes, two channels are sufficient for most purposes.
    And you can even get away with a simple 8-channel logic analyzer pod (usually Salae Logic clones), and free software. I managed to debug SPI and UART protocol that way lately.
    I'm using PulseView under Linux, AFAIK there is also a Windows version.

    Super User
    November 15, 2024

    An oscilloscope really is a key tool for embedded microcontroller firmware development.

    The key distinction between this kind of microcontroller programming and other types of software development is that you are dealing directly with electronic hardware - so you need tools to see what's happening in the hardware.

    Otherwise you're just "flying blind".

    As @Ozone said, there is quite decent kit available at reasonable prices these days...

    Graduate
    November 15, 2024

    Alright, I’ll try to communicate via I2C instead, and maybe I could get access to an oscilloscope at the university.