Topics

Dual core configuration of peripheral from other core/DTS file (e.g. nRF5340)


lairdjm
 

Hi,

Does anyone have suggestions for how to configure a peripheral on a dual core chip from the main core so it can be used by the secondary core but in a way that the devices are synchronised in DTS files? The example I have is with the nRF5340, the main core has to configure which pins can be used by the second core, but in order to do that it needs to be made aware of what pins the secondary core is going to use. The secondary core might have pins for a peripheral defined in it’s DTS file but the main core doesn’t have runtime access to that DTS file so is not aware of it. The first idea that comes to mind but I’m not overly happy with the idea would be to have a fake peripheral for the main core and both cores would include a single DTS which defines the pins, the main core would at start-up be able to read the DTS details and configure the pins but wouldn’t enable any driver for it whilst the secondary core would be able to start and use it as required. Or maybe using the real peripheral for both but forcing the driver for the second to be disabled in the Kconfig might be another way.

I do not want to use an overlay file at all for this. This is something that should be enabled by default and remain synchronised by changes only being made to one file.

Thanks,
Jamie


Kumar Gala
 

On Feb 2, 2021, at 4:17 AM, lairdjm <jamie.mccrae@lairdconnect.com> wrote:

Hi,
Does anyone have suggestions for how to configure a peripheral on a dual core chip from the main core so it can be used by the secondary core but in a way that the devices are synchronised in DTS files? The example I have is with the nRF5340, the main core has to configure which pins can be used by the second core, but in order to do that it needs to be made aware of what pins the secondary core is going to use. The secondary core might have pins for a peripheral defined in it’s DTS file but the main core doesn’t have runtime access to that DTS file so is not aware of it. The first idea that comes to mind but I’m not overly happy with the idea would be to have a fake peripheral for the main core and both cores would include a single DTS which defines the pins, the main core would at start-up be able to read the DTS details and configure the pins but wouldn’t enable any driver for it whilst the secondary core would be able to start and use it as required. Or maybe using the real peripheral for both but forcing the driver for the second to be disabled in the Kconfig might be another way.
I do not want to use an overlay file at all for this. This is something that should be enabled by default and remain synchronised by changes only being made to one file.
Maybe a simple example would help.

But why have the main core involved in the pin config at all? Seems like having the driver on the secondary core manage the pins that are needed would be easier. (Especially since on the nordic devices it seems like most of the pin config is done in the peripherals register).

- k


lairdjm
 

Hi,
Does anyone have suggestions for how to configure a peripheral on a dual core chip from the main core so it can be used by the secondary core but in a way that the devices are synchronised in DTS files? The example I have is with the nRF5340, the main core has to configure which pins can be used by the second core, but in order to do that it needs to be made aware of what pins the secondary core is going to use. The secondary core might have pins for a peripheral defined in it’s DTS file but the main core doesn’t have runtime access to that DTS file so is not aware of it. The first idea that comes to mind but I’m not overly happy with the idea would be to have a fake peripheral for the main core and both cores would include a single DTS which defines the pins, the main core would at start-up be able to read the DTS details and configure the pins but wouldn’t enable any driver for it whilst the secondary core would be able to start and use it as required. Or maybe using the real peripheral for both but forcing the driver for the second to be disabled in the Kconfig might be another way.
I do not want to use an overlay file at all for this. This is something that should be enabled by default and remain synchronised by changes only being made to one file.
Maybe a simple example would help.

But why have the main core involved in the pin config at all? Seems like having the driver on the secondary core manage the pins that are needed would be easier. (Especially since on the nordic devices it seems like most of the pin config is done in the peripherals register).
The main core has to set which pins can be accessed/controlled by the secondary core, for example with the nRF5340 there is code which is included and runs on the main core to enable the UART pins to be used by the secondary core - DTS of the main board has no knowledge of it so in the reset .c file it is not getting the details from DTS, it's just using defines: https://github.com/zephyrproject-rtos/zephyr/blob/master/boards/arm/nrf5340dk_nrf5340/nrf5340_cpunet_reset.c
The main core does not get involved with what the secondary core does with them, it's only to setup which are routed to the primary core or the secondary core, all peripheral configuration for the secondary core is performed by that core.