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?

[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?

[Tesla DeLorean]

On STM32's most SPI requires you drive the CS from a GPIO. It's automatic operation is not good, and needs SPI enabled/disable across the transaction.

[NicRoberts]

hmmm... my SPI_Init() has CS as software driven. I'll clock through with the scope & debugger tomorrow. I must be setting it somewhere between byte Tx's.

[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 · Accepted solution]

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.