cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with SPI and ADXL345

FilipF303RE
Associate II

 

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);

}

 

 

 

12 REPLIES 12

> 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.

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...

FilipF303RE
Associate II

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