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?

[haakonsh]

The SCK pin cannot generate the correct pulse

Can you share a logic scope of the SPI transfer?

Are you using a DK or a custom board?

If a DK, what version do you have?

[wsl]

Is custom,and There is no clock generation on SCK。

[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?