Application image unable to control some GPIOs when mcuboot enabled

[Redrield]

I'm working on the firmware for a custom board built around the nRF9151 SiP. The firmware is built against the nrf9151dk/nrf9151/ns board target included in zephyr, with an app.overlay file included to adjust peripherals to fit the function of the board. Mcuboot is also enabled to provide FOTA functionality, with the FOTA downloader being used directly (Custom solution, not using AWS/Azure/nrfcloud FOTA).

The specific issue I'm running into is that pins P0.16/P0.17 are required for use as generic GPIOs in the application image, but the firmware appears unable to correctly drive them or apply GPIO bias resistors. In testing, I determined that the pins behave as expected once mcuboot is disabled. After digging further I found the following

1. The default board definition uses P0.16/P0.17 for uart1 flow control. The aforementioned `app.overlay` file overrides this behaviour, as uart1 is used by the firmware without flow control and on different TX/RX pins. In the final merged application device tree (build/app/zephyr/zephyr.dts), the only reference to pins 16/17 are in a definition to expose them as gpios through dt.
2. In the final merged mcuboot device tree (build/mcuboot/zephyr/zephyr.dts), the uart1 definition from `app.overlay` is not applied, and the pins appear as uart flow control pins again
3. Enabling the device tree significantly changes the read result from the NS GPIO OUT memory mapped register (`0x40842500 + 0x004`, pg 167 of the v1.1 datasheet for this chip). Without mcuboot, the pinouts are read as `0x00540000`. When mcuboot is enabled the pinouts are read as `0x28554000`. Nothing in the application changes besides commenting out FOTA and bootloader feature from `prj.conf` and `sysbuild.conf`.

Finally, in trying to find existing problems in this vein, I found this thread Image booted by custom child image cannot control GPIOs, where the given solution is to update the custom overlay, and to set `CONFIG_TFM_LOG_LEVEL_SILENCE=y` in `prj.conf`. I've already taken both of these steps, and the problem persists.

I would appreciate any guidance for whether my analysis of the root cause here is correct, and help in making configuration changes to fix it.

[Simonr]

Hi

I think what you're seeing is that MCUBoot is printing out the pinouts it has gotten from the build here. The app.overlay file will only overwrite the UART pins for the application, while any sub images (like MCUBoot for example) would still have the default board settings.

The recommended way to go about this I think would be to create a custom board file rather than using an overlay for the DK board file. If not you will need to make .overlay files for each of your sub images in your project. We have a lesson on DevAcademy explaining how you shouuld go about creating a board file suiting your custom board available here: 

https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-3-adding-custom-board-support/ 

Alternatively, the Bootloaders and DFU/FOTA lesson explains how you can create an .overlay file specifically for MCUBoot as well. https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-9-bootloaders-and-dfu-fota/topic/exercise-1-dfu-over-uart/ 

Best regards,

Simon

[Redrield]

Thank you! The documentation about adding overlays to mcuboot was exactly what I needed. While I agree that a custom board definition would be preferable, I wasn't able to get it working properly when I tried to make a custom board in the initial revision of our custom hardware. 

[Simonr]

Glad to hear that. Closing this ticket then. Don't hesitate to reopen it if there are any follow-ups, or create a new ticket if the subject isn't directly related to this.

Best regards,

Simon