Hello,
I'm experiencing a weird bug with ARM TF-M and Zephyr (NXP downstream v4.3.0) on the FRDM-RW612. I want to use a region of my flash chip for a nonsecure LittleFS filesystem. I followed the NXP guide for adding a NS region (link) and I can successfully use the region for my filesystem, no problems with the Zephyr/FS API or access issues.
My problem is that when I have the CONFIG_FLASH KConfig option enabled, I can no longer reset my board. Calling tfm_platform_system_reset(), NVIC_SystemReset(), or even pressing the physical reset button all lock up the processor and do not actually reset the board anymore.
I stepped through with a debugger and the last line executed before the debugger is detached/broken away from is core_cm33.h:2683 (within __NVIC_SystemReset):
SCB->AIRCR = (uint32_t)((0x5FAUL << SCB_AIRCR_VECTKEY_Pos) |
(SCB->AIRCR & SCB_AIRCR_PRIGROUP_Msk) |
SCB_AIRCR_SYSRESETREQ_Msk );
If I attach a debugger after the reset occurs, GDB says the program at address 0x20005840 forever.
I've tried the same thing on a very basic program, even adding CONFIG_FLASH to the zephyr hello world program causes resets to fail in the same way.
Any help is appreciated, thank you!
Hi @jm-streametric, hope you are doing well.
In order to help me better analyze this behavior, would you please confirm if in the tests that you have done with the hello world example, the only setting that you add is the CONFIG_FLASH? Or are you also enabling your added NS region with the setting created from the guide (CONFIG_TFM_CUSTOM_DATA_IMPORT_REGION=y)?
I have tried to run the hello world example from Zephyr (v4.3.0 downstream) only adding the CONFIG_FLASH setting and I am able to reset the board.
Hello Jake, thank you for the clarification.
The difference between RW610 and RW612 is that RW610 does not support 802.15.4 protocol, therefore there is no difference with the flexspi peripheral.
Would you please confirm if you are using the FRDM-RW612 files to test these features? Or have you done your own directory for your board in Zephyr?
Also, are you able to run the examples properly without the reset functionality? Or is the MCU going to hardfault at a certain point?
Hi Jake, thank you for the information.
So, when you add the "CONFIG_FLASH=y" setting to any project, you are able to run the application normally, except when you try to do any type of reset, which leads your program to be in an infinite loop at address 0x20005840, is my understanding correct?
Would you please check the Reset status Register (SYS_RST_STATUS) to check if the reset cause is being registered? Additionally, have you done all your tests with the non-secure version of the board?
If you have a FRDM-RW612 board, could you please perform some tests on it and let me know whether this behavior is present or not, with the same configs you are adding to test with your custom board?
Hi Roman,
So, when you add the "CONFIG_FLASH=y" setting to any project, you are able to run the application normally, except when you try to do any type of reset, which leads your program to be in an infinite loop at address 0x20005840, is my understanding correct?
Yes, this is correct. I'm only able to restart the program by powering the board off and back on.
Would you please check the Reset status Register (SYS_RST_STATUS) to check if the reset cause is being registered?
I'm currently trying these tests with the zephyr sample hello_world. With or without CONFIG_FLASH=y, and with my custom board or the actual FRDM-RW612, I wasn't able to get a value on SYS_RST_STATUS. I tried pressing the physical reset button (connected to PDn on the SOC), calling tfm_platform_system_reset() after the printf statement, and triggering a hardfault by accessing a NULL pointer, but none of these produced values on the reset status register.
I tried sampling it before reset, after reset in the loop at address 0x20005840, and after reset in the BL2 stage and no matter what SYS_RST_STATUS was 0. I'm not sure if I'm checking it wrong, I use GDB (through west attach) to debug and got the value within the PMU block by printing p *((PMU_Type*)0x40031000u). If it helps to know, the SYS_RST_EN register was always 0x39 when I sampled.
Additionally, have you done all your tests with the non-secure version of the board?
Yes, I build all of these tests clean by removing the build folder then running west build -b frdm_rw612/rw612/ns.
let me know whether this behavior is present or not, with the same configs you are adding to test with your custom board?
Most of my configs are related to peripherals on the flexcomm ports. For my testing on this issue, I've only left changes I made to the TF-M profile. I am using the TF-M medium arotless profile instead of large so I can perform over-the-air firmware updates with the TF-M FWU partition. For this I have 3 extra zephyr KConfig options:
CONFIG_TFM_PROFILE_TYPE_AROTLESS=y
CONFIG_TFM_SFN=y
CONFIG_TFM_ISOLATION_LEVEL=1
And the only thing I've edited in the TF-M module folder is the following profile setting in modules/tee/tf-m/trusted-firmware-m/platform/ext/target/nxp/frdmrw612/config.cmake:
set(TFM_PROFILE "profile_medium_arotless" CACHE STRING "The TF-M profile")
Which was modified from "profile_large"
Thank you for your help, please let me know if I can provide any more information.
Hi Jake, thank you for answering my questions.
Since you mentioned that you tested with the FRDM-RW612, are you able to replicate the reset behavior in this board? I have tried by adding your configs and TF-M build changes (TF-M profile), but I am still unable to reproduce your behavior.
If you are able to replicate this, would you please share the detailed steps that you are following to reproduce the behavior on the FRDM-RW612?