Dear all,
I'm developing an application with the nRF5340 where we need High-Speed SPI (32MHz) with DMA (asynchronous).
For this I developed the (MWE) code attached here.
Setup:
nRF5340 DK (PCA10095, 2.0.0, 2021.40, NRF5340QKAAD0)
nRF Connect SDK, commit ada88401b43d09b4d0b32266340a8aa9ef3d02e4
Build target: nrf5340dk_nrf5340_cpuapp
Goal:
In one transaction (e.g. CS remaining low inbetween TX and RX), transmit first one byte (0xF0) before then receiving 32KiB, using spi_transceive_cb on the nRF5340
Problem:
The SPI does only perform the TX, then stops the transmission (therefore only 1 byte, instead of 32KiB+1 are transceived).
Source Files:
Questions (related to my code):
- Do I need to handle anomaly 135 myself (as in the code), or is it already done in the SDK?
- Is there a way of setting the clock directly using KCONFIG, or only on runtime?
Outputs:
- Logic Analyzer (MISO not shown, D1 is SCK, D2 is MOSI, D4 is CS)
- Logger:00> *** Booting Zephyr OS build v3.2.99-ncs2-34-gf8f113382356 ***
00> [00:00:00.437,591] <inf> main: SPI mock firmware started
00> [00:00:04.437,622] <inf> main: Creating buffer!
00> [00:00:04.439,178] <err> main: length: 32768
00> [00:00:04.439,208] <inf> main: Callback: Got result 0, sending event to main
00> [00:00:04.439,208] <inf> main: Finished Processing test
- GDB, content of xfer in zephyr/drivers/spi/spi_nrfx_spim.c, transfer_next_chunk, just before call to nrfx_spim_xfer:
transfer_next_chunk (dev=dev@entry=0xcddc <__device_dts_ord_136>) at ~/ncs/zephyr/drivers/spi/spi_nrfx_spim.c:290 (gdb) p xfer $1 = {p_tx_buffer = 0x200069c4 <z_main_stack+17084> <incomplete sequence \360>, tx_length = 1, p_rx_buffer = 0x200069c0 <z_main_stack+17080> "", rx_length = 1}
So to me it seems as if there is a bug inside the zephyr library (i.e. interface between zephyr abstraction and nrfx driver).
Best,
Trembel