Can I implement pairing with LESC enabled in nRF52810; SDK 15.2.0 v6.1.0 S112 ?

[Manish Kaul]

I’m using nRF52810 on a custom board (for our own application) using SDK 15.2.0 v6.1.0 S112. Given the amount of memory this chip has (192/24 KB) is it possible to implement pairing using LESC ?
The SoftDevice occupies 100KB of flash(0x00000-0x19000) and around 15KB of RAM(0x2000 0000 - 0x2000 3D00). Out of 92KB of remaining flash memory, my current application uses around 42.4KB and RAM uses ~6.6 KB out of the remaining ~9 KB of RAM. (picture attached-i)
I want to implement pairing in the current firmware and hence include all relevant files and modify the code.
My question is, is it possible to implement pairing (with LESC enabled) in this chip given the memory constraints and the amount of memory our application takes up ? Right now after including all the relevant files I'm getting linker errors for running out of memory (picture attached-ii, here I've stretched the Flash to it's maximum limits hence no memory error there).
Can you please help me out to either optimize memory or let me know where I can improve to achieve pairing using LESC ? ( IDE: IAR EWARM 8.32)

           i            ii.

[Manish Kaul]

In continuation to the above question,

i. For flash out of 92KB , 24KB of flash is assigned to the bootloader firmware leaving essentially just 68KB of flash (right now I've left just 0.5KB of flash space for bootloader). Can the chip nRF52810 really allow for pairing using LESC ?

ii. currently for pairing I've used Oberon library and nRF_hw_backend_rng and nRF_hw_backend_rng_mbedtls. What I observed was that the main space has been taken up the the encryption library file (liboberon_2.0.5.a) and currently we're using 'Normal' runtime C library but I had to increase it to 'Full' runtime library to include file descriptor operations (as they were used in one of the files for encryption)

[Jørgen Holmefjord]

Hi,

Manish Kaul said:

i. For flash out of 92KB , 24KB of flash is assigned to the bootloader firmware leaving essentially just 68KB of flash (right now I've left just 0.5KB of flash space for bootloader). Can the chip nRF52810 really allow for pairing using LESC ?

The nRF52810 is a very small chip. You cannot expect to fit everything into this (DFU, LESC, etc). If you do not require DFU, you do not need to reserve any space for the bootloader.

Manish Kaul said:

ii. currently for pairing I've used Oberon library and nRF_hw_backend_rng and nRF_hw_backend_rng_mbedtls. What I observed was that the main space has been taken up the the encryption library file (liboberon_2.0.5.a) and currently we're using 'Normal' runtime C library but I had to increase it to 'Full' runtime library to include file descriptor operations (as they were used in one of the files for encryption)

I have not double-checked, but I would assume that the micro-ecc backend may be much smaller than the nRF_Oberon libraries (which support many additional crypto algorithms). Have you tested that with LESC?

Can you please help me out to either optimize memory or let me know where I can improve to achieve pairing using LESC ? ( IDE: IAR EWARM 8.32)

If you can post your full project, we can try to help you optimize the flash and RAM usage.

Best regards,
Jørgen

[Jørgen Holmefjord]

Do you have GCC installed in the location where the Makefile is looking for it? If not, you have to modify the file in components\toolchain\gcc\Makefile.windows to point to the correct locations for GCC.

Manish Kaul said:

Can you please explain the linker errors? It says RAM is being over used however you can see in the other picture above that RAM is just using 6794 bytes where as the available is ~8KB ?

The errors from the section placement look a bit strange, this was one of the things I wanted to look at if you provided your project. Which example project are you based on? Did you modify the section placement/linker files for the project?

[Manish Kaul]

Thanks for the reply.
I was able to create the 'micro_ecc_lib_nrf52.a'.

Jørgen Holmefjord said:

The errors from the section placement look a bit strange, this was one of the things I wanted to look at if you provided your project. Which example project are you based on? Did you modify the section placement/linker files for the project?

The application is not based on any particular example, it's our own product with the hardware and the software built from scratch. However the current firmware does not take care of the encryption and to include encryption I referred to the hrs example, incorporated it on the app_uart example (worked well on testing with nRF Connect) and now porting the framework of encryption to our product firmware. 
Yes I did modify the FLASH end region (start is fixed at  0x19000) to accommodate for the additional size upon inclusion of encryption modules and files (as I said before he flash was divided into bootloader and application).
I'm afraid I am not in a position to share the source code/project as per the company policies.
Can you please help me out without the project ?
Attached are pictures of memory usage step by step (What's weird is when the RAM size is 8784 byte it gives no such error but when it reduces to 4096 bytes it gives placement error during linking):


After compiling the code now:

Also, can you please explain what is this warning of wchar_t size being 16bits in library file ?

[Manish Kaul]

One more thing, can we not implement link encryption using LESC on nRF52832 (PCA10040 S132) in SDK 14.0.0 ?

[Manish Kaul]

I verified by mistake. Please respond to the queries pending. Regards.

[Manish Kaul]

Jørgen Holmefjord said:

If you can post your full project, we can try to help you optimize the flash and RAM usage

Can you suggest some resources to learn from or suggest methods to do so ?

[Jørgen Holmefjord]

I'm not that familiar with IAR. Maybe you can ask their support if they can explain why you get these compilation errors?

Manish Kaul said:

Can you suggest some resources to learn from or suggest methods to do so ?

You would just need to remove unused modules and features. NRF_LOG is typically the first thing that needs to go if flash/RAM size is an issue.

Manish Kaul said:

Also, can you please explain what is this warning of wchar_t size being 16bits in library file ?

This is from the SDK release notes:

Note for IAR 8 users:
(Libraries for IAR 8 require wchar_t to be of size 32 bits while IAR 7 requires 16 bits).

Manish Kaul said:

One more thing, can we not implement link encryption using LESC on nRF52832 (PCA10040 S132) in SDK 14.0.0 ?

There is a LESC example in SDK 14.0.0 as well.

[Manish Kaul]

Jørgen Holmefjord said:

This is from the SDK release notes:

So how do I resolve this? I obviously can't edit the library file so how do I change wchar_t to 32 bits ?

[Jørgen Holmefjord]

It is explained in the release notes:

Note for IAR 8 users:
(Libraries for IAR 8 require wchar_t to be of size 32 bits while IAR 7 requires 16 bits).
 
To run a project using IAR 8, follow these intructions:
 - Open the IAR project in IAR 8. The IAR workbench will automatically generate an IAR 8 compatible project file.
 - If the project contains one of the precompiled libraries listed below, replace it
   with the IAR 8 compatible alternative (there are no projects targeting nRF51 in this SDK).
 - Save the project.
 - When building the project, you might get the warning: "The header file 'cmsis_iar.h' is obsolete and should not be used. [...]".
    - The problem is described in DevZone post: devzone.nordicsemi.com/.../iar-ewarm-8-22-1-complains-about-cmsis_iar-h
      The solution is to remove all occurrences of #include <cmsis_iar.h>.
    
The affected libraries are:
 - micro-ecc crypto:
    - IAR7: Includes library located in the folder named “…_iar\…”.
    - IAR8: Switch to using the library from the folder named “…_armgcc\…”.
 - nrf_cc310, nrf_cc310_bl, and nrf_oberon:
    - IAR7: Link to a library where “short_wchar” is part of the folder name.
    - IAR8: Link to a library without “short_wchar” in part of the folder name.
 - Gazell, NFC Tag, and 802.15.4:
    - IAR7: Includes the library where the file name ends with “_iar”.
    - IAR8: Switch to using the library with similar file name that ends with “_gcc”.