SPI4 (High-Speed SPI) Bring Up on nRF5340

[Wesley Groom]

Hello!

We have a new board design we are working on that uses the new nRF5340 chip, revision Engineering A.

However, we are having difficulty getting the SPIM4 (High-Speed SPI) peripheral working. We are using NCS v1.2.0.

I've tested everything out using SPIM1, but when I change our device tree to use SPIM4... everything stops working and we no longer get any output.

We are using TWI/SPI/UART0 and trying to free up TWI/SPI/UART1 for another peripheral since TWI/SPI/UART2 and TWI/SPI/UART3 are not functional on this version of silicon and we have to switch these around to test various components/functionality.

We are using the same settings/code, just moving &spi1 to &spi4.

This works:

&spi1 {
    compatible = "nordic,nrf-spim";
    status = "okay";
    sck-pin = <8>;
    mosi-pin = <9>;
    miso-pin = <10>;
};

This does not work:

&spi4 {
    compatible = "nordic,nrf-spim";
    status = "okay";
    sck-pin = <8>;
    mosi-pin = <9>;
    miso-pin = <10>;
};

Everything compiles correctly in both cases and we have an alias set-up that we swapped as well so that there were no changes to the code ran.

Our SPIM configuration is using 1MHz.

Are there problems with the SPIM4 peripheral that we are unaware of, or is there something else we have to do specifically for this peripheral?

[Wesley Groom]

Following up here as I've found a temporary workaround, but this is far from ideal...

Not sure yet why this is happening, but SPIM4 works correctly after executing a soft-reset using:

nrfjprog -r

Note that a pin reset or power cycle of the board alone is not sufficient, only a soft-reset seems to work to enable SPIM4 on the next boot. Other peripherals function correctly without the soft-reset, just not SPIM4.

Edit: Correction it looks like it was starting the program using west debug (GDB) specifically and continuing from there that allows SPIM4 to function correctly.

[haakonsh]

Could be Errata [45] SPIM: Receive is not functional at 32 Mbps.

[Wesley Groom]

I apologize that I didn't follow up on this sooner. We gave up on trying to use the nRF5340 because this wasn't the only weird issue we ran into at the time and we decided to move away from using the silicon that was not yet ready for production at the time.

I can say that the issue was not likely due to the Errata as I was running the peripheral at a much lower speed to start.

We did not end up solving this issue but are no longer using this device and are not putting effort into it right now.