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]

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

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