• State Verified Answer
  • Replies 3 replies
  • Subscribers 86 subscribers
  • Views 849 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 299283
Options

Image booted by custom child image cannot control GPIOs

devincmurphy7

I have developed an image based on the AWS IoT example which runs on a custom board. The custom overlay exposes some additional UARTs, LEDs, buttons, etc. in custom pin locations and removes things we don't need. Everything in our application image works fine if I either build with the stock MCUboot child image (without handing MCUboot a custom overlay or config or even trying to use MCUboot), or if I build without any child image at all. If I build with my custom child image, which I pass the same overlay I use for our application, when the child image boots into the application image the UARTs and ADC work but the GPIOs do not. The initialization code runs without errors, but any attempt to change which LEDs are on or off doesn't actually do anything.

  • Windows 11 Pro
  • VSCode 1.73.1
  • nRF Connect for VSCode v2022.11.140
  • nRF Device Tree v2022.11.153
  • nRF Kconfig v2022.11.50
  • nRF Connect SDK / Toolchain version 2.1.2
  • All builds of the application image are with TFM
  • The specified board for the child image is nrf9160dk_nrf9160
  • The specified board for the application image is nrf9160dk_nrf9160_ns
  • The CONFIG_NRF_GPIO0_PIN_MASK_SECURE is set to 0 in the generated .config for the application (same as when building with mcuboot)
  • UARTE1 is the only peripheral configured as secure (For TFM) in the generated .config for the application
  • The generated .config for the child image doesn't mention any *_SECURE peripheral or pin settings (neither does the generated mcuboot .config)

I do not know if my issues are from incorrect configuration, or if the child image is not booting into the application image correctly. I noticed that if I try to boot to where the application actually exists a reset occurs and execution starts over in the child image (over and over), but if I boot to where TFM starts execution does actually make it to my application image.

Please let me know if there is additional information I can provide to help figure this out, and thanks very much for any assistance.

Parents
  • +1

    I was finally able to dig into this some more. It turns out that I was incorrect in stating that my application image could not control GPIOs, truly my application image could not control 4 specific GPIOs where two of those happen to be on LEDs on my custom board. The issue was actually with UART1 being a secure peripheral used by TF-M and the default pinctrl settings using two of my LED GPIOs for RTS and CTS. My application cannot use those GPIOs because they have been assigned to a secure peripheral.... even though it seems like TF-M doesn't even use flow control since there is not a corresponding CONFIG_TFM_UART1_CTS_PIN or CONFIG_TFM_UART1_RTS_PIN...

    Anyways, the solutions to my problem appear to include:

    • Custom overlay changes
      • Add new pinctrl definitions for uart1 and uart1_sleep which do not define RTS and CTS pins or defines them as pins I am not using
      • Add uart1 configuration which re-defines pinctrl-0 and pinctrl-1 with the definitions from above
    • Simply building with CONFIG_TFM_LOG_LEVEL_SILENCE=y in the prj.conf or config fragment seems to release all GPIOs that would otherwise be assigned to UART1
Reply
  • +1

    I was finally able to dig into this some more. It turns out that I was incorrect in stating that my application image could not control GPIOs, truly my application image could not control 4 specific GPIOs where two of those happen to be on LEDs on my custom board. The issue was actually with UART1 being a secure peripheral used by TF-M and the default pinctrl settings using two of my LED GPIOs for RTS and CTS. My application cannot use those GPIOs because they have been assigned to a secure peripheral.... even though it seems like TF-M doesn't even use flow control since there is not a corresponding CONFIG_TFM_UART1_CTS_PIN or CONFIG_TFM_UART1_RTS_PIN...

    Anyways, the solutions to my problem appear to include:

    • Custom overlay changes
      • Add new pinctrl definitions for uart1 and uart1_sleep which do not define RTS and CTS pins or defines them as pins I am not using
      • Add uart1 configuration which re-defines pinctrl-0 and pinctrl-1 with the definitions from above
    • Simply building with CONFIG_TFM_LOG_LEVEL_SILENCE=y in the prj.conf or config fragment seems to release all GPIOs that would otherwise be assigned to UART1
Children
Related
Terms of service