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

[Øyvind]

Hello, 

Are you using a custom board? Do you see the same behavior on the nRF9160DK or Thingy:91? What are you using UART2 for? 

Please provide more details for me to reproduce.

Kind regards,
Øyvind

[e-va]

Yes we are using a custom board, and it also happens when we flash the binary to the Nordic nRF9160 Devkit. We created a custom Devicetree, which is attached in the initial post. UART2 is intended to be used for inter-processor communication with a Silicon Labs Bluetooth device.

[Michal]

Hello,

I took over the case temporary from my colleague, Hieu.

I got a recomendation to check which code is being run when RAMACCERR gets triggered.

Could you check in your .map file the following address?

        PC:   0x00012B8A
Best regards,

Michal

[basvkesteren]

Hi all,

Sorry to awake an old thread, but... I'm running into the same problem here, also on a custom board. Didn't check the pin high/low trick yet, but otherwise all is pretty much identical. Did this ever get resolved?

I'm using ncs 2.7, my exception report has PC:   0x00013000. If i read the .map file correct (build\zephyr\zephyr_final.map), code starts at 0x18000, so not sure what's happening there..

[e-va]

Hello basvkesteren,

we did not find time to further investigate the problem after checking the map file and also being unsure about the interpretation. For now, we settled with keeping the baud rate below the problem triggering threshold. We did not see the problem again at this baud rate.

BR

[basvkesteren]

Thanks!

Guess I'll have to do the same, for now.

Anyone from Nordic with an explanation for this? Hieu ?

[Michal]

We don't have any concrete explanation unfortunately. I will discuss it with my colleague if there is anything more that can be done here.

Best regards,

Michal