• State Verified Answer
  • Replies 1 reply
  • Subscribers 88 subscribers
  • Views 898 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 325029
Options

KCONFIG options for NRF5340

WesC

 I have been having issues with a customer and their custom NRF53 Board configuration.

 They state:  It seems that the required configurations for the application core and network core are ambiguous, and not sure where configurations are supposed to be defined without running into odd behavior in physical testing and going through this slow debugging/troubleshooting process.

 

For example, why does CONFIG_BT_EXT_ADV need to be turned on for both application and network core in configuration overlays while CONFIG_BT_SMP must only be turned on in our application core?

 

Does this mean other features such as CONFIG_BT_SCAN or CONFIG_BT_PER_ADV should be turned on in both application and network core configuration overlays if we want those features to work properly?

 

How do we know that we're not missing any configurations that are also required for these features to work properly?

 

Does Nordic have any tools that help configure multicore SOCs and prevent issues like this?

  • +1

    Hi Wes,

    For the nRF5340, the default configuration is to run the BLE Controller on the network core and the BLE Host on the application core.

    This is the split you should use for configuration: BLE Controller configs go to the network core, while BLE Host configs go to the application core.

    To figure out which goes where have a look at the source code here: https://github.com/nrfconnect/sdk-zephyr/tree/main/subsys/bluetooth.

    For example:

    CONFIG_BT_EXT_ADV

    It is defined in the parent folder, so it goes for both.

    CONFIG_BT_SMP

    Is defined under host, so it is only relevant for the host.

    CONFIG_BT_SCAN

    So this is in the nrf repo instead, but I think the concept should be the same. So for both, since it is in the top folder.

    How do we know that we're not missing any configurations that are also required for these features to work properly?

    There are no catch-all solution here.
    You can always try to find a sample that does the feature you need and do the same.
    In the end, the answer is testing. Try to activate the feature and then actually test that it works. If it does not work, you can search for what went wrong.

    Does Nordic have any tools that help configure multicore SOCs and prevent issues like this?

    No we do not.

    Regards,
    Sigurd Hellesvik

Related