Race condition for GPIO sharing between net core and app core

[darshan.patel]

Hello,

How race conditions are handled for GPIO forwarding  when done dynamically like this empty code sample , instead of using DTS entry  ?

Listed some scenarios, please clarify expected behavior.

1. Net core configures GPIO as output, then App core forwards that GPIO, expected behavior ?

2. App core sets as input, Net core sets as output, then App core forwards that GPIO, expected behavior ?

3. Net core configures GPIO as input, Tries to read value, then App core forwards that GPIO, expected behavior ?

4. Net core configure two GPIOs as UART, then App core forwards those GPIOs, expected behavior, can other side exchange UART TX and RX now ?

Is there a documentation regarding this race condition handling / best practices ?

Thanks,

Darshan

[Einar Thorsrud]

Hi,

There should not be any risk of such race conditions. The reason is that the network core is halted by default, and is started by the application core (after GPIO pin forwarding etc has been set up).

[darshan.patel]

We use MCUBoot on app core and b0n on net core. So there is a possibility if I guess it right.

1. MCUBoot runs
2. mcuboot zephyr starts net core
3. mcuboot verifies signature of app core images
4. b0n run loads net core image
5. net core image tries to read GPIO and does some actions
6. mcuboot loads app core image
7. app core image forwards GPIO

[Einar Thorsrud]

Hi,

If you were to start the network core in the application core bootloader, I agree this could be an issue. But that should not be the case. As mentionned, the network core is forced off by default, and started by the application core (by writing to NETWORK.FORCEOFF), and this is not normally done in the bootloader. For instance, in a Bluetooth application, the host implementation running on the applicatino core will start the network core when initializing Bluetooth.