2025-12-17 3:10 PM
I’m running into a confusing SPI issue and would appreciate a second set of eyes.
I have an ADXL345 accelerometer over SPI working perfectly on an STM32F446RE Nucleo board. I can reliably read the DEVID register (0x00 → 0xE5) and stream XYZ data.
I moved the exact same code (verbatim) to an STM32H723ZG board and swapped the SPI handle / GPIO definitions accordingly. The SPI peripheral initializes correctly, but the ADXL345 no longer returns 0xE5. Reads either return 0x00 / 0xFF or garbage depending on settings.
Things I’ve already checked / changed:
Same ADXL345 breakout (verified working on F446)
SPI mode (CPOL/CPHA) set to Mode 3 per datasheet
MSB + READ bit set correctly
Chip select manually controlled
SPI clock slowed way down
Correct SPI instance & pins
NSS handled in software
Power and ground verified at the sensor
What’s odd:
Works 100% on F446RE
Fails consistently on H723ZG with the same transaction sequence
Can’t even read the DEVID register (0xE5)
I’m starting to suspect something H7-specific (SPI FIFO behavior, NSS timing, GPIO speed, SPI prescaler differences, or cache/DMA side effects), but I’m not sure where to focus next.
Has anyone seen ADXL345 (or SPI sensors in general) behave differently on STM32H7 vs F4?
Any common gotchas with H7 SPI that would break an otherwise valid SPI driver?
Happy to share code snippets or logic analyzer traces if needed.
2025-12-17 3:54 PM - edited 2025-12-17 3:55 PM
Code looks fine.
> Happy to share code snippets or logic analyzer traces if needed.
What happens on the line? Use that to guide troubleshooting.
If SCK and MOSI and CS are as expected, the STM32 is doing its job. If MISO is not, then sensor is not hooked up properly. Receiving 00 or FF certainly suggests this. Ensure wiring is correct.
2025-12-17 4:36 PM - edited 2025-12-17 4:40 PM
Have you looked at the wires with a scope?
SPI of STM32H7 differs from STM32F4, so exactly same initialization code likely won't work. Examples in the STM32_Cube_FW_H7 package can help.