micro-ecc .a file not included

[JayLynkz]

Hi, 

The instruction from the 'Getting started with Nordic's Secure DFU bootloader, a step by step guide' page tels us to use minGW and GCC compiler to perform a 'make' command on the micro-ecc file. 

After building it, we found out that the '.a' file generated in the 'nRF5_SDK_16.0.0\external\micro-ecc\nrf52hf_armgcc\armgcc' folder can be used again in other projects without having to use 'make' again. 

My question is why is this file, called 'micro_ecc_lib_nrf52.a', is not already included, such as the micro-ecc library that we have to retrieve on github ? 

Thank you 

Jerome

[Vidar Berg]

Hi,

The reason we don't distribute it with the SDK has to do with licensing, as Bjørn points out here: https://devzone.nordicsemi.com/f/nordic-q-a/18432/why-nordic-do-not-provide-hex-bootloader-with-dfu-sdk12-1. But we now include the option to select proprietary Oberon library (starting from SDK 15) as an alternative, so uECC is no longer a requirement.

Best regards,

Vidar

[JayLynkz]

Thanks for your answer. 

Following the Oberon steps of the Step by step guide mentionned earlier, I do not get the expected result. 

I am using SES on windows and trying to configure a nrf52832.

I make the appropriate changes in SDK config, then comment the '#include micro-ecc'. After a build, I don't get the error message about the memory, although I did the Flash memory changes anyway. I don't see the device advertising in 'DFU Targ' like I do with the micro-ecc way. May be there's something I miss..

Also, is a .lib file the equivalent of a .a file in SES ?

Thank you

Jerome

[Vidar Berg]

Sorry, I should have verified this first. The process of swapping out uECC is slightly more involved than thought. I tried repeating this process here and ended up running into the same issues you described.

Problem 1: The Oberon library is larger in size and requires you to allocate more flash to the bootloader (ie reduce start address) by one or two flash pages.

Problem 2: The original flash_placement.xml file makes it so that the linker won't warn you when the bootloader code starts to grow into the reserved ".mbr_params_page" section, which is exactly what happens when you enable the Oberon library. This results in undefined behavior. A fixed flash_placement.xml file imported from SDK v17.0.0 is included in my project attached below.

Relevant sdk_config.h settings to select oberon backend:

• NRF_CRYPTO_BACKEND_MICRO_ECC_ENABLED to 0
• NRF_CRYPTO_BACKEND_NRF_SW_ENABLED to 0
• NRF_CRYPTO_BACKEND_OBERON_ENABLED to 1
• NRF_CRYPTO_BACKEND_OBERON_ECC_SECP256R1_ENABLED to 1
• NRF_CRYPTO_BACKEND_OBERON_HASH_SHA256_ENABLED to 1

You may also disable this config setting to make RTT logs appear in SES debug terminal:

NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED to 0

Here's the bootloader debug project I used for testing:

pca10040_s132_ble_debug_oberon.zip

Best regards,

Vidar

[JayLynkz]

Thanks for your answer Vidar ! 

I tried with the SDK 16, since this is what I was using for the project, and it doesn't seem to work. 

I tried with SDK 17 and it does work, so I'll be using this one. 

[Vidar Berg]

Glad to hear that you were able to make it work with SDK 17.0.0. The project configuration I uploaded in my previous replay should work with SDK 16.0.0 too. But it's probably better to just use SDK 17.0.0 if that's an option.

JayLynkz said:

Also, is a .lib file the equivalent of a .a file in SES ?

Forgot to comment on this. Yes, it's the equivalent.