- Board: nRF5340-DK
- Version: NRF5340_xxAA_ENGD
- SDK: 1.5.1, 1.6.1, etc
I have a Bluetooth project that also has quite a high SPI bandwidth requirement, so hence I am using the dedicated high-speed spi pins, and the SPI4 interface.
/* use the high speed spi */
&spi4 {
compatible = "nordic,nrf-spim";
status = "okay";
mosi-pin = <9>;
miso-pin = <10>;
sck-pin = <8>;
};
This has not proved an issue up until now. I have been running with the V1.5.1 SDK, however since moving to the v1.6.1 SDK (and beyond) it no longer works.
Using an analyser for the SPI traffic I could see all the data was being sent on the wire correctly, but the nRF5340 was reading back all zero's instead of the correct MISO data.
I happened to notice that the MISO pin P0.10 seems for some reason to be shared with the network core's UART pins (for CTS), and I can confirm that if I enable a COM port terminal for the network core, MISO data is completely disrupted using either 1.5.1 and 1.6.1 versions.
But I am at a loss to know why, when not used, it is now upsetting my 1.6.1 build.
After delving a bit deeper I noticed some hardcoded use of P0.10 in the nrf5340_cpunet_reset.c file which (I believe) is used by the application core to release the network core from reset at the start of the world.
/* This should come from DTS, possibly an overlay. */
#if defined(CONFIG_BOARD_NRF5340TE_NRF5340_CPUAPP)
#define CPUNET_UARTE_PIN_TX 1
#define CPUNET_UARTE_PIN_RX 0
#define CPUNET_UARTE_PORT_TRX NRF_P1
#define CPUNET_UARTE_PIN_RTS 11
#define CPUNET_UARTE_PIN_CTS 10
#endif
.
.
/* UARTE */
/* Assign specific GPIOs that will be used to get UARTE from
* nRF5340 Network MCU.
*/
CPUNET_UARTE_PORT_TRX->PIN_CNF[CPUNET_UARTE_PIN_TX] =
GPIO_PIN_CNF_MCUSEL_NetworkMCU << GPIO_PIN_CNF_MCUSEL_Pos;
CPUNET_UARTE_PORT_TRX->PIN_CNF[CPUNET_UARTE_PIN_RX] =
GPIO_PIN_CNF_MCUSEL_NetworkMCU << GPIO_PIN_CNF_MCUSEL_Pos;
NRF_P0->PIN_CNF[CPUNET_UARTE_PIN_RTS] =
GPIO_PIN_CNF_MCUSEL_NetworkMCU << GPIO_PIN_CNF_MCUSEL_Pos;
NRF_P0->PIN_CNF[CPUNET_UARTE_PIN_CTS] =
GPIO_PIN_CNF_MCUSEL_NetworkMCU << GPIO_PIN_CNF_MCUSEL_Pos;
If I comment this code out, the MISO data is now sent correctly to my P0.10 pin, and everything works again.
So two questions:
1. For what reason are these pins hardcoded in the source code?
2. What has changed (probably in the network core stack, I am using hci_rpmsg BTW) that the setting of these pins on the application core is now causing an issue?
I am going to use the workaround I mentioned for now, but would really like to get to the bottom of this issue, so any clarity on this would be helpful.
