STEVAL-MKI109D + STEVAL-MKI207V1: SPI transaction completes cleanly (HAL_OK) but MISO always reads 0xFF — CS/mode/clock all verified correct

[pooja_g]

Board: STEVAL-MKI109D (STM32H563ZI) + STEVAL-MKI207V1 adapter (ISM330DHCX)
Goal: Bare-metal custom firmware reading WHO_AM_I over SPI1

Following up on my earlier thread about GPIO pin mapping [link to old thread] — pin mapping is now resolved (SPI1_NSS on PA15, confirmed via community input; PA4/PA5 are DAC1 Vdd_set/VddIO_set as discussed). Thanks for the help getting there.

I'm now stuck on a different issue and would appreciate a sanity check. WHO_AM_I consistently reads 0xFF, but every layer I can verify from firmware/multimeter checks out correctly:

• CS on PA15 (GPIO output, confirmed via MODER/ODR register dump)
• SPI1 Mode 3 (CPOL=1, CPHA=1) — confirmed via CFG2 register decode
• SCK/MISO/MOSI on PB3/PB4/PB5, AF5 — confirmed via GPIOB MODER/AFRL dump
• VDD/VDDIO measured 3.3V at the DIL24 breakout header (J13/J14 area on JP1/JP2), in spec
• HAL_SPI_TransmitReceive returns HAL_OK, ErrorCode=0x0, every call — no timeout, no fault
• Tested at both SPI_BAUDRATEPRESCALER_32 and _256 (extremes) — identical 0xFF result at both, ruling out clock-speed/level-shifter-timing issues
• Swept 9 additional candidate CS pins as a sanity check — all 0xFF

Given a clean, fault-free SPI transaction that consistently returns 0xFF regardless of clock speed, this looks like MISO simply isn't being driven — but I don't have a scope/logic analyzer to confirm signal activity directly at the DIL24 socket or on the T14/T15 level shifter outputs.

Specific questions:

1. Is there anything specific about the T14/T15 (NTA4151PT1G) level-shifter circuit that requires a particular power-up sequence or reference voltage beyond VDD/VDDIO themselves — e.g. does VddIO2 (referenced near T15 in the schematic) need to be independently supplied, and if so, from where?
2. Is there a minimum CS-to-first-clock-edge setup time the ISM330DHCX needs that HAL_SPI_TransmitReceive might not guarantee back-to-back?
3. Any other MCU-side signal (chip select gating, ready/busy line) specific to this adapter board that a from-scratch bare-metal implementation might be missing, that ProfiMEMS handles internally?

Happy to share full register dumps / relevant code snippets if useful. Appreciate any pointers — been systematically ruling things out for a while now and this is the one piece I can't verify without a scope.

[Federica Bossi]

Hi ​@pooja_g ,

To narrow this down cleanly, I’d suggest first validating the setup with the official ST PID example on Github.

• If WHO_AM_I reads correctly with the official code, then the issue is most likely in your bare-metal implementation.
• If it still reads 0xFF, then the problem is much more likely on the hardware side — for example the adapter board, level-shifter path, power domain, or the MISO signal not being driven properly.

If possible, the next best step would be to check the SPI waveforms with an oscilloscope or logic analyzer, especially:

• CS
• SCK
• MOSI
• MISO

That would confirm whether the sensor is actually driving MISO during the read transaction, which would help determine whether this is a firmware-side or hardware-side issue.