Migrating OPTIGA TRUST I2C PAL from nrf_drv_* to nrfx_twim causes nrf_pwr_mgmt_run to not return

RE: Migrating OPTIGA TRUST I2C PAL from nrf_drv_* to nrfx_twim causes nrf_pwr_mgmt_run to not return

martinspedro — Thu, 15 Oct 2020 10:08:28 GMT

Hi Einar,

Thank you for looking into this and confirming that the approach to uninit all the Optiga related resources is indeed ok.

Also appreciate the explanation on the nrf_crypto. It confirms that I've build a good understand of it after the initial post.

All is clear now, thank you for the time.

Best regards,
Pedro

RE: Migrating OPTIGA TRUST I2C PAL from nrf_drv_* to nrfx_twim causes nrf_pwr_mgmt_run to not return

Einar Thorsrud — Mon, 12 Oct 2020 07:55:45 GMT

Hi,

[quote user="Pedro Martins"]Either way, to release the hardware peripherals being used to communicate with Optiga, this problem can be solved by rewriting this function as:[/quote]

I do not see any problems with your approach. By adding a call to optiga_comms_close() in optiga_backend_uninit() you uninit the TWI manager and driver when calling nrf_crypto_uninit(), and that will be initialized again if you call nrf_crypto_init() at a later stage. I have added an internal feature request for this.

[quote user="Pedro Martins"]Since my knowledge of the nrf_crypto is limited, I am not sure if anything needs to be unitialized. At least, Optiga's backend should be removed from the list of available backends, no? Can you please advice?[/quote]

This is not how nrf_crypto is designed. You select backends in sdk_config.h, and the preprocessor verifies that there is maximum one backend for each specific algorithm. And when you call nrf_crypto_init() all backend are enabled and stay enabled until you call nrf_crypto_uninit().

RE: Migrating OPTIGA TRUST I2C PAL from nrf_drv_* to nrfx_twim causes nrf_pwr_mgmt_run to not return

martinspedro — Fri, 04 Sep 2020 13:21:33 GMT

Of course, Susheel Nuguru!
I am also waiting for the crypto expert answer on the topic.

RE: Migrating OPTIGA TRUST I2C PAL from nrf_drv_* to nrfx_twim causes nrf_pwr_mgmt_run to not return

Susheel Nuguru — Wed, 02 Sep 2020 06:37:13 GMT

Martin,

I understand that you have solved the issue with the solution you proposed. It seems a sensible solution, however, i would like to get the expert to give his blessings to this.

RE: Migrating OPTIGA TRUST I2C PAL from nrf_drv_* to nrfx_twim causes nrf_pwr_mgmt_run to not return

martinspedro — Tue, 01 Sep 2020 17:25:03 GMT

Dear Susheel Nuguru,

Thank you for getting back to this.

To clarify, I solved myTWI module issues using the solution I proposed above.

I was just hoping that someone from your side could clarify if my approach is enough to uninit the nrf_crypto module. Also, I would like to understand why the SDK had a comment saying Function to uninitialize OPTIGA backend - currently no implementation is required.

RE: Migrating OPTIGA TRUST I2C PAL from nrf_drv_* to nrfx_twim causes nrf_pwr_mgmt_run to not return

Susheel Nuguru — Thu, 27 Aug 2020 10:47:27 GMT

Hi Martin,

Thanks for waiting so patiently, unfortunately, the expert of crypto is still unable to look at this at the moment, i will come back to you as soon as i get new info. sorry for the delays.

RE: Migrating OPTIGA TRUST I2C PAL from nrf_drv_* to nrfx_twim causes nrf_pwr_mgmt_run to not return

martinspedro — Mon, 17 Aug 2020 08:35:47 GMT

Hi Susheel Nuguru,

My apologies for the delay in answering you.

Thank you for the update. Looking forward for the crypto expert view on this.

RE: Migrating OPTIGA TRUST I2C PAL from nrf_drv_* to nrfx_twim causes nrf_pwr_mgmt_run to not return

Susheel Nuguru — Wed, 12 Aug 2020 08:02:59 GMT

Hi Martin,

Got a response that the crypto expert will most likely look into this next week. We need to wait until then. Thanks for your patience.

RE: Migrating OPTIGA TRUST I2C PAL from nrf_drv_* to nrfx_twim causes nrf_pwr_mgmt_run to not return

martinspedro — Fri, 07 Aug 2020 15:36:38 GMT

Thank you for the help Susheel Nuguru.

I look forward for the details.

RE: Migrating OPTIGA TRUST I2C PAL from nrf_drv_* to nrfx_twim causes nrf_pwr_mgmt_run to not return

Susheel Nuguru — Fri, 07 Aug 2020 06:28:03 GMT

Thanks for sharing your thoughts Martin,

I have asked the crypto expert to share some thoughts on this. The suggestions to uniinit function looks sensible to me. I will come back to you when i have some feedback from the crypto expert.

RE: Migrating OPTIGA TRUST I2C PAL from nrf_drv_* to nrfx_twim causes nrf_pwr_mgmt_run to not return

martinspedro — Wed, 05 Aug 2020 11:00:07 GMT

Hi Susheel Nuguru,

The workaround works fine, but I shouldn't need one. I decided to invest more time and further investigate the problem.

Doing a complete trace of the function calls, one can see that when calling nrf_crypto_init(), the call stack is:

nrf_crypto_init()
- optiga_backend_init()
-- optiga_init()
--- pal_gpio_init();
--- pal_os_event_init();
--- optiga_util_open_application(&optiga_comms);
---- optiga_comms_open()

When calling nrf_crypto_deinit(), the call stack is only:

nrf_crypto_deinit()
- optiga_backend_uninit()

because the contents of optiga_backend_uninit() are:

/** @internal @brief Function to uninitialize OPTIGA backend - currently no implementation is required.
 */
static ret_code_t optiga_backend_uninit(void)
{
    // Empty implementation
    return NRF_SUCCESS;
}

As you can see, nothing is being done and the twi_mngr is never being uninitialized.

Since my knowledge of the nrf_crypto is limited, I am not sure if anything needs to be unitialized. At least, Optiga's backend should be removed from the list of available backends, no? Can you please advice?

Either way, to release the hardware peripherals being used to communicate with Optiga, this problem can be solved by rewriting this function as:

static ret_code_t optiga_backend_uninit(void)
{
    if(optiga_comms_close(&optiga_comms) == PAL_STATUS_SUCCESS) {
      return NRF_SUCCESS;
    }
    else {
      return NRF_ERROR_INTERNAL;
    }
    
}

RE: Migrating OPTIGA TRUST I2C PAL from nrf_drv_* to nrfx_twim causes nrf_pwr_mgmt_run to not return

Susheel Nuguru — Wed, 05 Aug 2020 08:28:06 GMT

[quote user="Pedro Martins"][/quote]

I solved it by adding:

nrfx_twim_disable(&m_twi_master);

nrfx_twim_uninit(&m_twi_master);

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

nrfx_twim_disable(&m_twi_master);
nrfx_twim_uninit(&m_twi_master);

after the nrf_crypto_uninit and before initializing the twim again.

this is very strange, nrf_twi_mngr_uninit should call nrf_drv_twi_uninit -> nrfx_twim_uninit which also should disable the twim (nrfx_twim_disable)

I understand that the preprocessor defines around this glue wrapper between nrx and the legacy driver is making it complicated here. But I am glad that you have a workaround for this. The idea was to create a simple glue layer so that the users using legacy drivers migrate easity to the new changes. But it seems that it can be complicated in some cases to use this.

RE: Migrating OPTIGA TRUST I2C PAL from nrf_drv_* to nrfx_twim causes nrf_pwr_mgmt_run to not return

martinspedro — Mon, 03 Aug 2020 16:26:21 GMT

[quote userid="90247" url="~/f/nordic-q-a/64403/migrating-optiga-trust-i2c-pal-from-nrf_drv_-to-nrfx_twim-causes-nrf_pwr_mgmt_run-to-not-return/262843"][/quote]

However, since they require different communication speeds, I am alternatively disabling one and enabling the other to communicate. When I try to enable the second device, I am getting a NRF_ERROR_INVALID_STATE on the TWIM driver initialization.

In the meantime, I was able to fix this problem. Somehow, the nrf_twi_mngr_uninit() was leaving the TWIM peripheral on a INITIALIZED STATE. This function is called byNordics implementation of Optiga Trust X I2C pal_i2c_deinit, which on the code above is called by nrf_crypto_uninit().

I solved it by adding:

nrfx_twim_disable(&m_twi_master);
nrfx_twim_uninit(&m_twi_master);

after the nrf_crypto_uninit and before initializing the twim again.

RE: Migrating OPTIGA TRUST I2C PAL from nrf_drv_* to nrfx_twim causes nrf_pwr_mgmt_run to not return

martinspedro — Mon, 03 Aug 2020 15:21:07 GMT

Hi Susheel Nuguru,

Thank you for the quick response!

I apologize for my long answer, but I am trying to be as detailed as possible here to reduce the number of messages exchanged.

[quote userid="6207" url="~/f/nordic-q-a/64403/migrating-optiga-trust-i2c-pal-from-nrf_drv_-to-nrfx_twim-causes-nrf_pwr_mgmt_run-to-not-return/262811"]As far as i can see nrf_twi_mngr uses nrf_drv_twi which in turn uses nrfx_twim (if NRF_DRV_TWI_USE_TWIM is defined) [/quote]

Yes, this is true depending on the macros you set.

But the issue is that you cannot manually set NRF_DRV_TWI_USE_TWIM, as you said above, since the file integration/nrfx/legacy/nrf_drv_twi.h does not check if it has been previously defined elsewhere. Also, the macro expansion performed by the full chain of #includes that allows the integration of legacy nrf_drv_* with nrfx_* is complex, poorly documented and difficult to follow, since macros are defined and undefined across multiple files.

[quote userid="6207" url="~/f/nordic-q-a/64403/migrating-optiga-trust-i2c-pal-from-nrf_drv_-to-nrfx_twim-causes-nrf_pwr_mgmt_run-to-not-return/262811"]What errors do you get when you have this. I believe we need to convince the glue layer to use TWOM and make NRF_DRV_TWI_USE_TWIM set to true by satisfying its dependencies.[/quote]

I was getting linking errors on the twi_mngr. I manage it to fix it by trial and error of defining NRFX_TWI_*, TWI_* and NRFX_TWIM_* macros. It is currently building correctly with the macros:

#define TWI_ENABLED 1
#define TWI0_ENABLED 1
#define TWI0_USE_EASY_DMA 1
#define NRFX_TWI_ENABLED 1
#define NRFX_TWI0_ENABLED 1
#define NRF_TWI_MNGR_ENABLED 1
#define NRFX_TWIM_ENABLED 1

[quote userid="6207" url="~/f/nordic-q-a/64403/migrating-optiga-trust-i2c-pal-from-nrf_drv_-to-nrfx_twim-causes-nrf_pwr_mgmt_run-to-not-return/262811"]Can you please attach the project, so that i can give it a quick try.[/quote]

I cannot do this for the whole project do to privacy concerns, since the project is already in an advanced development state. I can, however, work on providing a minimal working example with only the TWI counterpart. Also, please note that to able to reproduce the error you will need an Optiga Trust X. Please advise if you want me to do this

Regarding my initial questions:

[quote userid="90247" url="~/f/nordic-q-a/64403/migrating-optiga-trust-i2c-pal-from-nrf_drv_-to-nrfx_twim-causes-nrf_pwr_mgmt_run-to-not-return"]1. Is not possible to use, on the same application, nrf_drv_ + nrf_twi_mgnr and a nrfx_twim drivers, even if the former controls the TWI0 and the latter the TWIM1, correct?[/quote]

From your answer I conclude that due to the "magic" of the nrfx integration layer, I am, in all cases, using the nrfx_twim, because the nrf_twi_mngr, which uses nrf_drv_twi, is in fact using the nrfx_twim drivers, due to macros defined on the sdk_config.h

Is my interpretation correct?

[quote userid="90247" url="~/f/nordic-q-a/64403/migrating-optiga-trust-i2c-pal-from-nrf_drv_-to-nrfx_twim-causes-nrf_pwr_mgmt_run-to-not-return"]2. Why am I getting stuck on the pwr_mgmt_run routine and what can be done to fix it?[/quote]

Regarding this bug, using the macros above I can compile and run the my code with one device using the twim drivers explicitly and another implicit (through nrf_twi_mngr).

A code snapshot is provided below. The error is happening on the line err_code = nrfx_twim_init(m_twi_master, &twim_config, twim_handler, NULL). Am I missing something? Please note that both initialization routines work well independently.

ret_code_t err_code;

// Optiga Trust X Initialization
err_code = nrfx_clock_init(clock_event_handler);
APP_ERROR_CHECK(err_code);
nrfx_clock_lfclk_start();

// Init nrf_crypto, which initializes the OPTIGA backend, and the OPTIGA host library/stack
err_code = nrf_crypto_init();
DEMO_ERROR_CHECK(err_code);
NRF_LOG_INFO("Optiga Trust X Init succesfull\r\n");

optiga_trust_x_test();

err_code = nrf_crypto_uninit();
DEMO_ERROR_CHECK(err_code);
NRF_LOG_INFO("Optiga Trust X Uninit succesfull\r\n");


// Intialize second I2C device
#define MASTER_TWI_INST_ID     0       //!< TWI interface used as a master

static const nrfx_twim_t m_twi_master = NRFX_TWIM_INSTANCE(MASTER_TWI_INST_ID);


const nrfx_twim_config_t twim_config = {
   .scl                 = ARDUINO_SCL_PIN,
   .sda                 = ARDUINO_SDA_PIN,
   .frequency           = NRF_TWIM_FREQ_100K*8/10,  // Set to 80 kHz
   .interrupt_priority  = NRFX_TWIM_DEFAULT_CONFIG_IRQ_PRIORITY,
   .hold_bus_uninit     = NRFX_TWIM_DEFAULT_CONFIG_HOLD_BUS_UNINIT
};

err_code = nrfx_twim_init(m_twi_master, &twim_config, twim_handler, NULL);
APP_ERROR_CHECK(err_code);

nrfx_twim_enable(m_twi_master);

Thank you for your help

RE: Migrating OPTIGA TRUST I2C PAL from nrf_drv_* to nrfx_twim causes nrf_pwr_mgmt_run to not return

Susheel Nuguru — Mon, 03 Aug 2020 13:18:11 GMT

Hi Martin,

[quote user=""]As far as I am aware, nrfx_twim cannot coexist with nrf_drv or nrf_twi_mngr, so I started porting the I2C NRF PAL to use only the nrfx_twim[/quote]

As far as i can see nrf_twi_mngr uses nrf_drv_twi which in turn uses nrfx_twim (if NRF_DRV_TWI_USE_TWIM is defined)

[quote user=""] I needed to remove my code that uses the nrfx_twim driver. Otherwise the application of the nrfx_glue and legacy porting layer messes up compilation by defining the legacy drivers and undefining the nrfx so much that I cannot get an executable.[/quote]

What errors do you get when you have this. I believe we need to convince the glue layer to use TWOM and make NRF_DRV_TWI_USE_TWIM set to true by satisfying its dependencies.

Can you please attach the project, so that i can give it a quick try.