Trouble integrating the micro-ecc library

[David Andresky]

Hi,

I am developing a central and peripheral device with secure LESC connections using SDK v11.

• My peripheral device is an already developed product. I am simply adding BLE capability.
• My central device is a new product and I have created a derivative of the ble_app_multirole_lesc "experimental" project for my code base.

I successfully fixed compiler and linker errors in the ble_app_multirole_lesc project and I have built the micro-ecc library and compiled it with the main project. 

I have added BLE client functionality to my peripheral device, without the micro-ecc library LESC connections, and I can successfully connect to the peripheral and write and read attributes. In this scenario, I have configured the central device for  Bonding, MITM, and LESC. However, because my peripheral device does not yet integrate the micro-ecc module or LESC configuration, the connection security is lv1 or lv2, not lv4.

Now I am trying to integrate the micro-ecc module into my peripheral project so I can go to lv4 and I am running into a problem. The file ecc.c makes a call to the nrf_drv_rng_block_rand function in the nrf_drv_rng.c file. This function makes a call to 

ASSERT(m_rng_cb.state == NRF_DRV_STATE_INITIALIZED);

This fails and stops execution of my code. The only place m_rng_cb.state is set to NRF_DRV_STATE_INITIALIZED is in the nrf_drv_rng_init function. However, this init function is never called. The thing that stumps me is that the call to this init function is not made in my central code either, and yet the assert does not fail. 

I can see no differences in the two projects related to the micro-ecc functionality and yet one gets an assert error and the other does not.

[Vidar Berg]

Hi,

The example code happens to work because DEBUG_NRF/DEBUG_NRF_USER are undefined, had to debug the code to figure it out. I guess you have one or both of these symbols in your project? I would suggest to just remove the assert, alternatively, call rng init on startup. rng init seems to be redundant as long as the sd_* api is used. 

Best regards,

Vidar

[David Andresky]

Thanks, I do have DEBUG_NRF_USER defined in my peripheral project. I am calling the init function now so I could progress but it would be helpful to understand when this init function is actually required. I assume the random number generator is needed for key generation. Why do I not need to initialize for the LESC project to work?

For anyone reading this encountering the same issue, I had to call the nrf_drv_rng_init  function after ble_stack_init but before peer_manager_init for this to work.

[Vidar Berg]

Yes, the RNG is needed for key generation. The softdevice uses the RNG HW module internally, which is why it doesn't have to be initialized by the application code. Once the softdevice is enabled, the application can request random bytes through the sd_rand_* APIs.

[David Andresky]

Got it, so as long as I am defining NRF_DEBUG_USER I have two choices. 

1. delete or comment out the ASSERT in nrf_drv_rng_block_rand 
2. call nrf_drv_rng_init so the ASSERT doesn't fail

Off to the next problem :-)