SPI issue keep getting 0 values from accelerometer

[NicRoberts]

NUCLEO-WB55RG communicating via SPI1 to an ADXL362 eval board
I set up the project (attched below) using CubeIDE, generated the code & placed my own callbacks for the SPI in main.

When I look at the value for the Z direction I should be getting a value that indicates roughly 1g but all I get is 0. The same for all the other axis, no change in any value no matter how I orient the sensor.

To check that the acceleromter was working I hooked it up to an Arduino using a 3rd party library especially for the ADXL362. That all worked as expected, so I know the accelerometer is working.

When I go through the code with the debugger it doesn't hang anywhere so I'm guessing my callbacks are working, its just I dont get any data back, all values remain at 0

Anyone see anything obvious that I'm doing wrong?

[Tesla DeLorean]

Check if Arduino Library is doing something to initialize/start the accelerometer. I remember the Bosch devices needing a quick magic sequence and scale selection. 

Get a scope or logic analyzer on the pins and review working and non-working signals.

Link to github library for working driver you're using / attempting to port

[NicRoberts]

The Arduino library I used Winkelict ADXL362 Arduino library 

The only thing I've spotted is that they do is a soft reset first, which I've now added to ADXL362_Init()

 

SPI_WriteRegister(ADXL362_SOFT_RESET, 0x52);
HAL_Delay(500);

Which doesn't change the behaviour, I still get 0 readings.

I changed the power control register to disable auto-sleep and remain in measurement mode

SPI_WriteRegister(ADXL362_POWER_CTL, 0x02);

Still no readings. So I decided to check if I could even read the chip ID, I cant I just get a value of 0.

[Andrew Neil]

To prove basic SPI comms, can you successfully read the Device ID register ?

As @Tesla DeLorean said, use a scope and/or logic analyser to verify comms - compare & contrast with the Arduino.

 

Have you checked the AD Product Page:

https://www.analog.com/en/products/adxl362.html#:~:text=Sheet%20(Rev.%20G)-,Software%20Resources,-All

[NicRoberts]

Not even getting the device ID. 

Yes I have the device datasheet with the register map & the SPI settings.

As soon as I get a working scope I'll check the comms.

[NicRoberts]

From the scope, top row is from the STM32WB55, bottom row from the Arduino.

Channel 1 - top trace is the CS line. I couldn't get a reading of the clock & the CS line one the Arduino, as soon as I probed SCLK then the chip errored out and just returned 0s & the clock & CS traces interfered with each other..

 

The STM MISO line is always 0 no matter what command I send, so no ID, no axis data, always 0. 

I notice the CS line has that blip which I assume is the gap between bytes being sent?

SCLK is bang on 4MHz

[Andrew Neil]

Does your scope not have a trace capture or screenshot facility?

 

---

@NicRoberts wrote:

I notice the CS line has that blip which I assume is the gap between bytes being sent?

---

Looks like it.

That'll be (at least one reason) why it's not working - CS should stay low for the entire transaction:

 

[NicRoberts]

---

@Andrew Neil wrote:

Does your scope not have a trace capture or screenshot facility?

---

It doesnt even have a USB port :D just an old school parallel port.

 

---

That'll be (at least one reason) why it's not working - CS should stay low for the entire transaction:

 

---

 Yeah that's what I was expecting.  I cant see it in the code unless the CS is being taken care of in the HAL & I shouldn't be setting & resetting it in my ADXL362 driver?

[NicRoberts]

Frustratingly the SPI call backs dont work in the debugger so they just hang which doesn't happen when its just running.

Anyway, it looks like I have no control over the CS line (PA4). When I clock through the code in the debugger & get to the line,

HAL_GPIO_WritePin(ADXL_GPIO_Port, ADXLCS_Pin, GPIO_PIN_RESET);

 The trace on that pin stays HI only when,

HAL_SPI_Transmit_DMA(adxlParams.hspi, command_address, 2);

is called does the CS line get pulled LO & then it exhibits the behaviour above, i.e. the CS line goes HI between each byte sent. I cant find anywhere in the HAL_SPI_Transmit_DMA() function that is acting on PA4, so that's puzzling.

So I've tried to just toggle PA4 in main() in the while() loop

HAL_GPIO_WritePin(ADXLCS_GPIO_Port, ADXLCS_Pin, GPIO_PIN_RESET);
HAL_Delay(500);
HAL_GPIO_WritePin(ADXLCS_GPIO_Port, ADXLCS_Pin, GPIO_PIN_SET);

It just stays HI

// Pin & GPIO port defines in ADXL362.h
#define ADXLCS_Pin PIN_4
#define ADXLCS_GPIO_Port GPIOA

 

[NicRoberts]

Found it!!
I had configured PA4 as SPI1_NSS as soon as I reconfigured it as a GPIO output it all worked fine.

Thanks fellas for walking me through the debugging of this.