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.

[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).

[Brian Shankland]

More information:

I found that SPIM3 would work within the first 5 seconds from power-up which I assume is because lots of activity was happening and it had not entered any low-power mode.

If I waited 15 seconds when the power had dropped to under 3uA the SPIM would run the transfers but no signals were on the IO lines. SPIM2 would work under similar timing conditions.

I later thought about that I was using TWIM0 for a temperature reading so changed the code to stop this, and suddenly SPIM3 would work.

When I was reading temperatured the order of Init / Unint was:

SPIM3 Init - TWIM0 Init - TWIM0 UnInit - SPIM3 Uninit

I changed this so that SPIM3 would only Init after the temperature reading thus:

TWIM0 Init - TWIM0 UnInit - SPIM3 Init - SPIM3 Uninit

And now it works okay.

Looks like there may be some internals messing the SPIM3 Pin assignments during TWIM0 Init or Uninit - very strange but its what the current evidence currently suggests.