STEVAL-MKI109D — GPIO pin mapping between STM32H563ZI and DIL24 socket (SPI + power supply) for custom bare-metal firmware

[pooja_g]

Hi,

Hardware: STEVAL-MKI109D (STM32H563ZI), ISM330DHCX on DIL24

I'm developing custom bare-metal firmware for the STEVAL-MKI109D motherboard (STM32H563ZI), flashed via DFU, to communicate directly with an ISM330DHCX sensor on a STEVAL-MKI207V1 DIL24 adapter — not going through MEMS Studio.

Problem:
I can't get a valid SPI response from the sensor — WHO_AM_I consistently reads back as 0xFF. I've verified the following are correct against the ISM330DHCX datasheet:

• GPIO alternate function mapping (AF5, SPI1) confirmed via register dump
• SPI1 configuration matches Mode 3 (CPOL=1, CPHA=1), master mode, 8-bit frames, software NSS
• Read command format (0x80 | reg + dummy byte) and HAL_SPI_TransmitReceive sequence match the datasheet's read protocol

The sensor and DIL24 socket are confirmed good — sending the stock firmware's power-on/voltage-set commands over the same UART interface correctly reads WHO_AM_I = 0x6B.

I'm currently using PA4/PA5/PA6/PA7 for SPI1 CS/SCK/MISO/MOSI in my firmware, but I suspect these may not be the correct pins for the DIL24 socket's SPI bus on this specific board — possibly conflicting with the pins used for the software-adjustable VDD/VDDIO supply.

Question:
Could someone confirm the correct GPIO pin assignments between the STM32H563ZI and the DIL24 socket's SPI signals (SCK/MOSI/MISO/CS)? I'm only looking for the pin mapping/schematic reference — so I can write my own bare-metal driver without conflicting with the board's power supply circuitry.

Thanks in advance. 

USB CDC - Working - Previous issue for continuity (Resolved)

[Andrew Neil]

As always, schematics will be found on the board’s Product Page - see the ‘CAD Resources’ tab:

https://www.st.com/en/evaluation-tools/steval-mki109d.html#cad-resources

 

In this case, they are also in the User Manual:

https://www.st.com/resource/en/user_manual/um3420-stevalmki109d-professional-mems-tool-motherboard-for-mems-adapter-boards-stmicroelectronics.pdf#page=49

via: https://www.st.com/en/evaluation-tools/steval-mki109d.html#documentation

[pooja_g]

Thanks, this confirms SPI1_SCK/MISO/MOSI/NSS feed the DIL24 socket via level shifters (T14/T15), separate from the Vdd_set/VddIO_set nets — that resolves my main confusion. One remaining question: can you confirm the exact GPIO pin for SPI1_NSS? I can see SCK/MISO/MOSI clearly correspond to PB3/PB4/PB5 based on the NTRST/PB4 pin-share convention, but the NSS routing isn't clear from the schematic text extraction.

[pooja_g]

Update: went with PA15 for SPI1_NSS (AF5 candidates were PA4/PA15/PG10; PA4 was already ruled out as DAC1_OUT1/Vdd_set, so PA15 was the remaining option). Confirmed correct in silicon via GPIOA MODER/ODR register dumps — happy to share if useful for anyone else hitting this.

That got me past the pin-mapping question, but I've since run into a new issue I'd appreciate a sanity check on: WHO_AM_I consistently reads 0xFF, even though every layer I can verify checks out correctly:

• CS on PA15 (GPIO output, software NSS) — confirmed via register dump
• SPI1 Mode 3 (CPOL=1, CPHA=1) — confirmed via CFG2 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 (JP1/JP2 on the MKI207V1 adapter), in spec
• HAL_SPI_TransmitReceive returns HAL_OK, ErrorCode=0x0, every call — no timeout, no fault
• Tested at both SPI_BAUDRATEPRESCALER_32 and _256 — identical 0xFF at both extremes, which rules out clock-speed/level-shifter-timing as the cause
• Swept 9 additional candidate CS pins as a sanity check — all 0xFF too
• Sensor confirmed alive: same physical board, ProfiMEMS factory firmware reads WHO_AM_I=0x6B correctly via *dbreset→*setdb207v1→*r0F

Given a clean, fault-free transaction that's constant 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 the T14/T15 (NTA4151PT1G) level-shifter outputs.

Specific questions:

1. Does the T14/T15 level-shifter circuit need anything beyond VDD/VDDIO — e.g. is VddIO2 (referenced near T15 in the schematic) an independent supply that needs separate handling?
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 MCU-side signal specific to this adapter (chip-select gating, ready/busy line) that ProfiMEMS handles internally but a from-scratch implementation would miss?

Happy to share register dumps / relevant code if useful. Appreciate any pointers — this is the one piece I can't verify without a scope.

[Andrew Neil]

That got me past the pin-mapping question, .

So please mark this thread as solved.

 

 I've since run into a new issue

Please start a new thread for a new issue.

You can always give a link back to this thread, if you feel it helps.

Please give a link here to the new thread - so that people can find it