nrf5340 network core default peripherals from dk board devicetree

I feel like I have missed something obvious here, so sorry if I have not read the documentation carefully enough! I have two specific related questions at the very end, but there is quite a lot of preamble...

When building samples (both nrf and Zephyr) for the nrf5340-DK, I have noticed that the devicetree for the app core has the expected uart pins forwarded to the net core (for net core debug information), and the four buttons and leds on the DK are also declared as expected for app core use. All of this is happening in ncs/v2.5.1/zephyr/boards/arm/nrf5340dk_nrf5340/nrf5340_cpuapp_common.dts.

I am confused by the devicetree for the net core, I see the four uart pins as expected, but I also see the four dk buttons and four dk leds which I do not expect to see. These are declared in ncs/v2.5.1/zephyr/boards/arm/nrf5340dk_nrf5340/nrf5340dk_nrf5340_cpunet.dts.

I am surprised this does not cause a problem with zephyr trying to give two cores ownership of the same pins. I am also surprised that it does not throw an error during building.

Documentation here states that "In nRF53 family of SoCs, GPIO pins must be explicitly forwarded by the application core to the network core if the latter should drive them."

When debugging the app core for the 'peripheral_lbs' sample, it appears the uart tx/rx pins that are supposed to be forwarded to the net core are still assigned to the app core.

  

And the net core debug session also shows the uart tx/rx pins have not been forwarded (and neither have any of the dk button/leds).

Questions:

1) Can you clarify why I cannot see the net core uart pins correctly set up in the registers when debugging?

2) Why does the net core default devicetree file (ncs/v2.5.1/zephyr/boards/arm/nrf5340dk_nrf5340/nrf5340dk_nrf5340_cpunet.dts) include the dk buttons and leds?

Many thanks,

Rich

Parents
  • Things in devicetree can be disabled or enabled.  They are only actually enabled when they include 

    status = "okay"

     

    The okay might be in a different place than the definition, e.g. they are defined in one file and in another file there is something like:

    &uart0 {
    status = "okay";
    };

    As long as buttons are only enabled in 1 cpu, there is no conflict.

  • Thanks that's helpful to keep an eye out for! Still in the compiled devicetree output the uart is show as status = "okay"

    Re UART on net core: When debugging the pins are shown as 'AppMCU' in both the app and net debug sessions. I would expect them to be "Peripheral" as per the datasheet. Perhaps the debugger does not count as secure code access?

    Re GPIO (DK leds and buttons) on net core: On the compiled devicetree output, both gpio0 and gpio1 have status = "okay" in the same way as the app core. As far as I can see, the app core does not include status = "okay" for buttons or leds, only for the gpio peripherals. 

Reply
  • Thanks that's helpful to keep an eye out for! Still in the compiled devicetree output the uart is show as status = "okay"

    Re UART on net core: When debugging the pins are shown as 'AppMCU' in both the app and net debug sessions. I would expect them to be "Peripheral" as per the datasheet. Perhaps the debugger does not count as secure code access?

    Re GPIO (DK leds and buttons) on net core: On the compiled devicetree output, both gpio0 and gpio1 have status = "okay" in the same way as the app core. As far as I can see, the app core does not include status = "okay" for buttons or leds, only for the gpio peripherals. 

Children
No Data
Related