Why does the ECC module require the softdevice to be initialised?

[jm_laird]

I spent some time trying to work out why generating a private/public keypair in my application with the ECC module was failing due to an 'internal error' and had to eventually reference my code against the experimental example source code in the nRF5x SDK only to eventually work out that the cause of the problem was that the softdevice needs to be initialised before the function can be used - what is the reason behind this? My understanding of the softdevice is that it is for controlling the radio and the ECC can be used for BLE functionality but that is optional - therefore I was expecting that the module would have the ability to be enabled and used without the softdevice being initialised. Also why it not listed in the documentation that the softdevice has to be initialised before using it?

Also there is a stray #include "app_timer.h" in the ecc.c file, I say stray as the module doesn't use the application timer module at all and can be commented out without issue.

[bjorn-spockeli]

So ecc_p256_keypair_gen() returns NRF_SUCCESS if you call it after SOFTDEVICE_HANDLER_INIT(), before calling softdevice_enable(), which in turn calls sd_ble_enable?

I looked through the code in uECC.c and calling ecc_p256_keypair_gen will result in the following call stack.

ecc_p256_keypair_gen --> uECC_make_key -->uECC_generate_random_int-->g_rng_function 

The g_rng_function is set to nrf_drv_rng_block_rand in ecc_init() in ecc.c

I assume that you have called ecc_init before calling ecc_p256_keypair_gen, but If g_rng_function in uECC_generate_random_int does not return then you will get NRF_ERROR_INTERNAL since the return value 0 is propagated up to ecc_p256_keypair_gen. It could be that you need to request the LFCLK and/or HFCLK before calling ecc_p256_keypair_gen if you have not called SOFTDEVICE_HANDLER_INIT() which configures the clock source for the SD.