STM32 Dual Core Init - Private Peripheral Bus considerations

[liarokapisv]

The current dual-core initialization architecture assumes that system initialization is performed fully by the primary core.

Crucially this is not true for Peripherals addressed through the Private Peripheral Bus, which includes the NVIC, MPU and SysTick through the System Control Space.

Accesses to the NVIC (and similarly for the other PPB peripherals), access a different instance depending on the core on which we are running.

As a result, this affects the InterruptExt trait and transively the DMA init which ends up being called only on the primary core. This leaves the secondary core's NVIC with masked DMA interrupts. ~~The solution to this is most likely to duplicate the interrupt enablement on the secondary_init flow as well~~ (see edit). Maybe this is not an issue with non-DMA drivers due to them requiring explicit interrupt binders and late interrupt intialization, but more investigation is needed.

This interrupt masking is just one instance of the PPB issue and we will probably need to think things through about the rest of the PPB peripherals when it comes to dual core usage.

Going through the code it seems the biggest culprits are the enabled-at-initialization dma and exti modules. Most other drivers enable the NVIC lines at driver creation avoiding this issue.

EDIT:

Enabling both NVIC DMA lines at startup is not a good solution because the on_irq functions end up running in both cores racing the peripherals and creating issues with the state bookkeeping.

One approach is to introduce some extra state on each core to determine if it should service each channel interrupt or not. This should also help with dual-core lines that only have a single NVIC line for all DMAs.

An easier approach is to defer NVIC line enabling at init and lazy enable them at configuration time. As long as the two cores do not use the same DMA channels then no collisions should occur. This makes the DMA more similar to the other peripherals as well.