High Speed (32MHz) Async SPI on nRF5340 not working

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:

spi_minimal.zip

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

Parents
  • Hello Trembel,

    I built and ran your project with SDK v2.3.0, but it seems to be working here:

    Do you have the pins connected to a SPI slave? If so, can you try to disconnect them and measure the output without anything connected? 

    Do I need to handle anomaly 135 myself (as in the code), or is it already done in the SDK?

    Wokraround for errata #135 does not appear to be implemented in the driver, unfortunately. I will report it internally.

    Is there a way of setting the clock directly using KCONFIG, or only on runtime?

    It is currently only possible to change it at runtime.

    Best regards,

    Vidar

Reply
  • Hello Trembel,

    I built and ran your project with SDK v2.3.0, but it seems to be working here:

    Do you have the pins connected to a SPI slave? If so, can you try to disconnect them and measure the output without anything connected? 

    Do I need to handle anomaly 135 myself (as in the code), or is it already done in the SDK?

    Wokraround for errata #135 does not appear to be implemented in the driver, unfortunately. I will report it internally.

    Is there a way of setting the clock directly using KCONFIG, or only on runtime?

    It is currently only possible to change it at runtime.

    Best regards,

    Vidar

Children
No Data
Related