Issue with SPI4 RX buffer - always 0xFF data

RE: Issue with SPI4 RX buffer - always 0xFF data

Michal Mrowiec — Mon, 22 Sep 2025 12:01:47 GMT

I checked dts in build/zephyr and in build/hci_ipc/zephyr also and there is no assignment for P0.10 except of SPI4.

RE: Issue with SPI4 RX buffer - always 0xFF data

Michal Mrowiec — Mon, 22 Sep 2025 11:31:43 GMT

So how to change these, if I have already written an overlay for network core UART?

RE: Issue with SPI4 RX buffer - always 0xFF data

Turbo J — Mon, 22 Sep 2025 11:03:51 GMT

Triple check the finished dts in build/zephyr, a few GPIOs are assigned to the network core by default.

RE: Issue with SPI4 RX buffer - always 0xFF data

Michal Mrowiec — Mon, 22 Sep 2025 10:55:28 GMT

I had a few approaches to MEMS with DT, but nothing work as expected, full of bugs and no intuitive. I prefer to use nrfx drivers.

This code was working without issue on logic analyzer, one byte transferred and one received.

I wrote clearly, that I checked it with IRQs and nothing changed for better.

RE: Issue with SPI4 RX buffer - always 0xFF data

Turbo J — Mon, 22 Sep 2025 09:50:51 GMT

The NCS SDK ships quite a few drivers for MEMS devices already, I strongly recommend using those if available. Requires you to learn how DT works.

Your code does not look functional to me at all. Look into the datasheet of the MEMS device how an SPI read transaction is supposed to look like.

No idea why this is supposed to look "correct" in the LA output, there should be only one byte transferred.

The Zephyr SPI drivers do use interrupt mode and may cause problems with your code that tries to work around them for some reason. Note that your DT overlay turns them ON for SPIM4.

EDIT: Disregard, the small code window and the line similarity was hiding the fact that you called nrfx_spim_xfer() twice.