SLM fault on startup with UART2

[Mike12345]

Hello,

I'm working on a project that uses the Serial LTE Modem (SLM) application on a custom board. The main processor sends data to the nRF9160 over UART. The project is build using NCS v2.9.1 with TF-M, and UART2 is configured as the SLM UART.

I ran into an issue where the nRF9160 would hit an SPU fault caused by a RAM access violation right after switching to the non-secure firmware. The fault is triggered whenever the main processor TX line is high, which it is when it's idle.

The problem came from MCUBOOT. In the nrf_cleanup_peripheral() function in nrf_cleanup.c,file UARTs 0, 1, 20, and 30 are deinitialized before do_boot() jumps to the non-secure reset vector, but UART2 wasn’t included in that list.  Adding UART2 to the deinitialization list solved the issue for me.

I'm not sure, but I think it might also be related to this ticket.

#if defined(NRF_UARTE_CLEANUP)
static NRF_UARTE_Type *nrf_uarte_to_clean[] = {
#if defined(NRF_UARTE0)
NRF_UARTE0,
#endif
#if defined(NRF_UARTE1)
NRF_UARTE1,
#endif
// Add UART2 to the list of UARTS to cleanup so so it won't cause an SPU fault if enabled by MCUboot in
// firmware that builds with TF-M
#if defined(NRF_UARTE2)
NRF_UARTE2,
#endif
#if defined(NRF_UARTE20)
NRF_UARTE20,
#endif
#if defined(NRF_UARTE30)
NRF_UARTE30,
#endif
};

Regards,

Mike

[Vidar Berg]

Hello Mike,

Thank you for reporting this! These kinds of issues can be tricky to track down. Hope you didn't have to spend too much time on it. Assuming you're not using the UARTE2 instance in your bootloader, a solution that doesn't require patching the SDK is to disable the uart2 node in the devicetree for MCUboot. I have reported this as a bug internally.

<project source directory>/sysbuild/mcuboot.overlay

&uart2 {
    status = "disabled";
}

Best regards,

Vidar