TF-M crash with certain UART baud rate settings in nRF9160

[e-va]

Dear Nordic Team!

We are struggling with a fatal error occurring during boot phase before entering the application main. When setting the baud rate of UART2 to 38400 or higher, the SPU detects some kind of violation, leading to SPU fault. This also occurs when we copy the device tree in the attachment and some of our prj.conf contents to the lwm2m_client example project. This occurs in both SDK 2.4.2 and 2.5.99-dev1. When running at a baud rate below 38400, the application works as intended and UART communication is ok on UART2.

*** Booting nRF Connect SDK v2.5.99-dev1 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: none
I: Bootloader chainload address offset: 0x10000
FATAL ERROR: Platform Exceptionlot
Platform Exception: SPU Fault

The prj.conf lines, which we added to cause the error.

# LTE link control
CONFIG_LTE_LINK_CONTROL=y

# Modem info
CONFIG_MODEM_INFO=y

# Enable settings storage
CONFIG_SETTINGS=y
CONFIG_FCB=y
CONFIG_SETTINGS_FCB=y
CONFIG_FLASH_MAP=y
CONFIG_STREAM_FLASH=y

# Allow FOTA downloads using download-client
CONFIG_LWM2M_CLIENT_UTILS=y
CONFIG_LWM2M_CLIENT_UTILS_FIRMWARE_UPDATE_OBJ_SUPPORT=y
CONFIG_DOWNLOAD_CLIENT=y
CONFIG_DOWNLOAD_CLIENT_STACK_SIZE=4096
CONFIG_DOWNLOAD_CLIENT_HTTP_FRAG_SIZE_1024=y
CONFIG_FOTA_DOWNLOAD=y

We cannot find out how the fatal error could be caused by the UART baud rate setting. Does UART in some way interfere with the boot process?

Thank you

pcb_v70_common.dts

[e-va]

Hello,

we have found out that the error occurs on the provided sample always if the uart2 RX pin 23 is tied 'high' (IO supply voltage). It does not occur when setting to 'low' (GND). The same behavior can be observed when swapping the pin control assignments between uart1 and uart2 as follows. In this case, the error is triggered by setting pin 0 to 'high'.

arduino_serial: &uart1 {
	status = "okay";
	current-speed = <115200>;
	pinctrl-0 = <&uart2_default>;
	pinctrl-1 = <&uart2_sleep>;
	pinctrl-names = "default", "sleep";
};

&uart2 {
	status = "okay";
	current-speed = <115200>; /* TODO: change baudrate here 28800 (working) <=> 38400 (not working) */
	pinctrl-0 = <&uart1_default>;
	pinctrl-1 = <&uart1_sleep>;
	pinctrl-names = "default", "sleep";
};

This strange behavior was observed on two devkits with the B1 revision and also on one devkit with the B0 revision nRF9160. The modem firmware was 1.3.5 in all cases. We could not try it on the nRF9161 as we were not able to obtain one yet. A binary is attached at the end.

Kind regards

8228.merged.hex

[Hieu]

Hi e-va,

Could you please try to enable TF-M logging to see if it can give us any clues?

Best regards,

Hieu

[e-va]

Hi,

this is the entire uart1 TFM output.

FATAL ERROR: Platform Exception
Platform Exception: SPU Fault

Best regards

[Hieu]

Hi e-va,

Ok... it is very unfortunate that there is no clear clue there.

We will continue to investigate this and follow-up with you.

Best regards,

Hieu

---

P.s: I actually also think about increasing the log level, but as the default level is already INFO, I don't have high hope for it. If it's not too much, do you mind retrying with increased log level as well? You can use these configs:

CONFIG_TFM_PARTITION_LOG_LEVEL_DEBUG
CONFIG_TFM_SPM_LOG_LEVEL_DEBUG

[Hieu]

Hi e-va,

Could you please explain further how you tie the RX pin to 'high' to produce the issue? I tried your sample code, but when I directly wire the RX pin to VDD, the application couldn't run at all. I am not even sure it left the bootloader. All I got on the log is the boot banner of the bootloader.

Also, does your description mean that the issue only happens when using pin 23 specifically?
Or does it only mean the issue happen when UART RX is tied to logic high?
i.e., if you use a different pin for UART RX, can you reproduce the issue?

Why do you need the UART RX pin tied to logic high? Is this some startup condition of your system?

Best regards,

Hieu