Failures with GPIO and RTC after Zephyr project enabled TF-M with PROFILE_MEDIUM

[ClarkS]

Attached is a zip of a simple VSCode / NXP MCUXpresso Zephyr project which demonstrates GPIO and RTC failures after enabling TF-M with PROFILE_MEDIUM at ISOLATION_LEVEL=2.

The project contains a simple overlay MCXN947 overlay file, a simple prj.conf file, and a couple simple c files. When the project reaches boot, zephyr has already configured TF-M. At boot the project attempts to toggle a couple GPIO. The code appears to work, no errors are thrown, but a logic analyzer shows the pins are not toggling. After that it prints some console messages with the time from the RTC. The time properly advances as it should however if the board is reset, the time is lost and starts at zero again. The RTC did not survive a reset.

If the TF-M configuration is removed and the project is changed to a simple zephyr non TF-M project, the GPIO and RTC will work as expected. The flash and debug process also work as expected. 

It is my hypothesis that the AHBSC controller is not configured properly and does not allow GPIO or the RTC to operate with non-secure code. 

Another problem of lesser severity is that I have been unable to configure launch.json to properly flash and then debug main.c or other non-secure code. 

I am using Zephyr 4.3.99...the latest zephyr version. VSCode and MCUXpresso are both up to date.

[ClarkS]

I am still unable to get GPIO to work after configuring zephyr to implement TF-M. I have attempted to modify the blinky app  by adding TF-M and when I do, the LED no longer flashes.

Please provide a modification of the blinky sample app which simply enables TF-M. Ideally it should implement the best method of adjusting the AHBSC, SYSCON, and GPIO registers so as to enable GPIO. 

Is modifying target_cfg.c the only way to adjust these registers before main is executed? I hope there is a better method because I don’t like modifying my zephyr repo. 

[ClarkS]

I have been continuing to work on this with no success. I am preparing a reply to you with more information and a request for further help. I'll post it tomorrow. 

[Harry_Zhang]

Hi @ClarkS 

Can you share your code?

BR

Harry

[ClarkS]

I had a zip of my project attached to the original post but it seems to have been deleted. I'll try again.

Nope zip is not supported. I'll try to attach the raw source files. You can take them and make your own project. Since there is a 5 file limit, I'll try to send them in two replies. 

THANK YOU for looking at this. This problem is a show stopper for me and I also think it might be a big problem for others also. 

[ClarkS]

Additional files below. If there is a way to send the project, let me know.

[Harry_Zhang]

Hi @ClarkS 

Thank you for your detailed description.

"

## Known Findings

1. **BusFault when reading AHBSC**: Non-secure code triggers immediate BusFault (BFAR: 0x400AC1D0) when attempting to read AHBSC controller registers
- This proves: At ISOLATION_LEVEL=2, NS is completely locked out from peripheral access verification
- AHBSC controller itself is in secure-protected memory space

2. **GPIO still doesn't work**: Even if AHBSC configuration is happening in secure world (which we can't v_erify), NS GPIO remains non-functional

"

According to the MCX Nx4x Reference Manual 73.1.2
Security considerations

Each GPIO module is also instantiated to use two module slots (for example, GPIO0 and GPIO0_alias).

At the Secure AHB controller, one slot can be configured for secure access while the other is configured for non-secure access.

The GPIO module implements Access protection that can be used to configure secure/non-secure and privileged/non-privileged access on a per pin basis

I think the following links are helpful to you.

NXP MCXN947 CPU1 cannot control GPIO · Issue #88521 · zephyrproject-rtos/zephyr

NXP MCXN947 CPU1 cannot control GPIO · Issue #88521 · zephyrproject-rtos/zephyr

MCXN947 failed to control GPIO in slave core (CPU1)

BR

Harry