NRF52840 SPIM3 SCK not Pluse

[wsl]

SCK:P014

MOSI:P016

MISO:P015

CS:P017(SOFT)

nrf_gpio_cfg(SCK, NRF_GPIO_PIN_DIR_OUTPUT, NRF_GPIO_PIN_INPUT_DISCONNECT, NRF_GPIO_PIN_NOPULL, NRF_GPIO_PIN_H0H1, NRF_GPIO_PIN_NOSENSE);
nrf_gpio_cfg(MOSI, NRF_GPIO_PIN_DIR_OUTPUT, NRF_GPIO_PIN_INPUT_DISCONNECT, NRF_GPIO_PIN_NOPULL, NRF_GPIO_PIN_H0H1, NRF_GPIO_PIN_NOSENSE);
nrf_gpio_cfg(CS, NRF_GPIO_PIN_DIR_OUTPUT, NRF_GPIO_PIN_INPUT_DISCONNECT, NRF_GPIO_PIN_NOPULL, NRF_GPIO_PIN_H0H1, NRF_GPIO_PIN_NOSENSE);

The SCK pin cannot generate the correct pulse, and it is necessary to use JLINK for soft reset。

Power on reset and software reset are invalid。

The MCU must be connected with JLINK (it will send a reset automatically) to output pulse normally, no matter whether the frequency of SCK is 125k or 32m。

May I ask why there is such a problem? Is there a bug in spim3 itself?

[Maksym Galemin]

I've got the same issue on my custom HW board. Tested on both SPI2 and SPI3 with exactly the same GPIO and SPI configuration (SCK=P0.19, MOSI=P0.06, MISO=P0.07, CS=P0.08) @ 1MHz with soft CS. NRFX_SPIM2_ENABLED and NRFX_SPIM3_ENABLED are both set to 1 in the sdk_config.h file. SCK and MOSI are both H0H1.

No issues with the SPI2 bus but after I switch to the SPI3 literally by just replacing NRFX_SPIM_INSTANCE(2) with NRFX_SPIM_INSTANCE(3) the uC stops generating signals on the SCK/MOSI lines.

• Logic Analyser SPI2
• Logic Analyser SPI3

Strangely enough, if the CLI via UART0 is enabled the SPIM3 works fine.

[Brian Shankland]

Has there been any progress on this issue as I also think that our board is suffering the same problem.

We had been using SPIM3 for the past 2 months, but once we disabled the Logger (to save power) it looks as if SPIM3 is no longer working.

Strangely if we have a ULINK2 debugger connected, even when not having any breakpoints the SPI works again so it appears to be something very strange within the CPU core itself.

[Brian Shankland]

Yes can confirm wsl's observation.

When I change to using SPIM2 on 8MHz with no hardware handshaking I can read the registers from the device, but on switching back to SPIM3 it fails.

We need to use SPIM3 for the faster baud rates and hardware chip selects so a resolution to this is now critical.

I don't see anything relating to this in the errata document for this specific issue with SPIM3 but with the other internal problems it has, maybe it needs some other peripheral to be powered up for it to function?

[Maksym Galemin]

Just an update, apparently my issue was related to a misconfiguration in my sdk_config.h file. After checking my configuration against the one from the "examples\peripheral\nrfx_spim\pca10056\blank\config\sdk_config.h" file and removing some unnecessary stuff like SPI3 etc. it finally worked as expected.

[Brian Shankland]

I had noticed that many of the examples SDK_Configs did not have the SPIM3 supported but found one that did as a template. Could you share yours here for comparison.

I don't think this is my problem since it works when other peripherals are connected, just not in low power  / sleep situations.

[LBM@DEMCON]

I am having the exact same problem. Thank you very much for the suggestion of UART0 being related, that allowed me to solve the problem. After some digging, I now call nrf_drv_uart_init for UART0 with the default config, which magically makes SPIM3 work.

Note that I also have a BL654 module lying around, which is based on the nRF52840. The BL654 does not have this issue. Either that, or it has to do with the nRF bootloader (I don't have a bootloader on the BL654).