RW612 Nonsecure Flash Setting Breaks Reset Functionality

[jm-streametric]

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!

[RomanVR]

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.

[jm-streametric]

Hi Roman,
I made an error on the post when specifying the board, I am using a custom board with the RW610 but the flash configuration is exactly the same as the FRDM-RW612. I can get the development board to reset even with CONFIG_FLASH=y, but my custom board has the issue described in my post.

Even with the TF-M and Zephyr repos set to FRDM-RW612 defaults, I get the problem of being unable to reset the board when CONFIG_FLASH=y (with and without the custom data regions). Is there a difference between the RW610 and RW612 that could cause flash/flexspi problems? Or do you think it may be another problem with my board?

[RomanVR]

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?

[jm-streametric]

Hi Roman,

I am using the unmodified FRDM-RW612 files to test my board for the flash features since my board uses the same flash IC. I have different peripherals on my board which I have overlays for, but I'm not applying those overlays for this flash test case.

The flash does work, I can access the flash data within my custom region just fine. When I access flash outside of the custom region I get a fault, which is expected. The only thing that doesn't work is that trying to reset the board either physically or with tfm_platform_system_reset() locks the board up as described above.

Thank you

[RomanVR]

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?

[jm-streametric]

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.

[RomanVR]

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?

[jm-streametric · Accepted solution]

Hi Roman,
I found out the schematic for my board was wrong, and the flash chip I was using was really the W25Q01 instead of the W25Q512 like the FRDM-RW612. I soldered a W25Q512 to my board and now it resets with no problem. I apologize for wasting your time before.

Are there any resources for how to reconfigure the flash settings to work with my chip? I see the fc_flexspi_nor_config_t struct in flash_config.c which is set up for the W25Q512, but is there a document or guide that specifies what I would need to change to adapt to my new chip?

[RomanVR]

Hello Jake, don't worry about it, thank you for letting me know the root cause.

Unfortunately, there is no specific guide to reconfigure the flash. However, you could take as reference the structure of the RD-RW612-BGA board directory, or the IRIS-W1-EVK board directory (from u-Blox) which both have different flash ICs from the FRDM board, on what changes are required in case of using a different flash.

In the case of TF-M there is also the directory of the RD-RW612-BGA non-secure version of the board, which also may serve as reference for the required changes.

Hope this helps!