nRF5340 network core booted twice for bluetooth applications

[andvib]

nRF5340 network core booted twice for bluetooth applications

[github-actions]

Hi @andvib! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[jciupis]

The assumption behind combined changes introduced in #71337 and #72412 was that it is fine to let calls to nrfx that drive the Force-Off signal:

nrf_reset_network_force_off(NRF_RESET, false);

be executed multiple times in a row. The assumption was that only the first call changes the network CPU's state and all the others that follow have no effect. This seemed to have been confirmed by various Bluetooth samples. The issue description confirms that as well.

However, what this bug report shows is that this assumption is only correct if the time between subsequent calls is short enough. Otherwise, the second call causes the network CPU to reboot.

In my opinion, the best way to fix this bug given all the requirements for network CPU management that made it necessary in the first place is to no longer boot the network core in board initialization files. Instead, the network CPU users such as HCI driver or 802.15.4 driver should request it using the network CPU management API. That's a clean solution that I would have already incorporated into #72412 if not for the risk that there are components, which implicitly depend on the board initialization code to boot the network core.

However, since it's no longer a matter of clean division of responsibilities between modules but rather a functional problem that needs to be solved, I think we should remove network CPU control from board initialization file. Instead, we should introduce a requirement for the network CPU users to request and release it explicitly, similarly to how the HCI driver does it now.

[andvib]

@koffes