• State Verified Answer
  • Replies 2 replies
  • Subscribers 75 subscribers
  • Views 619 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 319543
Options

Persistent Bug Issue with CONFIG_I2C and ECDSA Combination

SimonDar

I am reaching out to report a persistent bug I've encountered in a larger project. The issue specifically arises when combining the CONFIG_I2C setting with ECDSA, in a non-secure build, resulting in the board failing to post on the nRF5340.

Detailed Steps to Reproduce the Bug:

  1. Download the ECDSA example from the following path: /nrf/samples/crypto/ecdsa, located within ncs/v2.5.0.
  2. Modify the configuration by adding “CONFIG_I2C=y”.
  3. Build using non_secure and flash the modified setup onto the board.

After completing these steps, the system exhibits no output on any VCOM(n) channels. Interestingly, this problem does not occur when not using the non-secure build.

I am seeking assistance to understand why this conflict occurs and how to resolve it. Specifically, I need guidance on how to successfully run the system with the CONFIG_I2C configuration enabled alongside ECDSA in a non-secure building environment.

Edit: 

After further investigation and testing, I have identified that the conflict arises specifically between the following two configurations:

CONFIG_I2C=y

CONFIG_TFM_PROFILE_TYPE_NOT_SET=y

These two configurations appear to be incompatible with each other, leading to the aforementioned issue. Any insights or solutions regarding this specific conflict would be greatly appreciated.

Parents
  • +1

    Hi,

    I think the issue here is that the default I2C instance on nRF5340 DK is I2C1, which collides with TF-M's use of UART1 for logging. That results in a busfault when the I2C driver tries to initialize the I2C instance on the non-secure side, as it is reserved for TF-M on the secure side.

    There are (at least) two options for fixing the issue:

    1. Let TF-M use UART0 for logging and share it with the application. To do that, set these to Kconfig options:


    CONFIG_TFM_SECURE_UART_SHARE_INSTANCE=y
    CONFIG_TFM_SECURE_UART0=y

    2. Reconfigure I2C to use a different instance. In the application, create a DT overlay file called `nrf5340dk_nrf5340_cpuapp_ns.overlay` in the `boards` folder with this content:

    &i2c1 {
    status = "disabled";
};



    That's the first step to get the app running. Then you will have to configure I2C for some other instance.
    Regards,
    Jan Tore
Reply
  • +1

    Hi,

    I think the issue here is that the default I2C instance on nRF5340 DK is I2C1, which collides with TF-M's use of UART1 for logging. That results in a busfault when the I2C driver tries to initialize the I2C instance on the non-secure side, as it is reserved for TF-M on the secure side.

    There are (at least) two options for fixing the issue:

    1. Let TF-M use UART0 for logging and share it with the application. To do that, set these to Kconfig options:


    CONFIG_TFM_SECURE_UART_SHARE_INSTANCE=y
    CONFIG_TFM_SECURE_UART0=y

    2. Reconfigure I2C to use a different instance. In the application, create a DT overlay file called `nrf5340dk_nrf5340_cpuapp_ns.overlay` in the `boards` folder with this content:

    &i2c1 {
    status = "disabled";
};



    That's the first step to get the app running. Then you will have to configure I2C for some other instance.
    Regards,
    Jan Tore
Children
Related
Terms of service