This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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.

Parents
  • 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)

  • 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

Reply
  • 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

Children
  • Thanks for the response.


    Further queries:

    1. 

    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?

    trying to do that but am NOT being able to get through generating the 'micro_ecc_lib_nrf52.a' file by compiling the Makefile on the path "<PROJ_DIR>\external\micro-ecc\nrf52hf_iar\armgcc" . When I run the make command on this path in the cmd, it says this (on a Windows 10 machine)

    I followed steps according to (https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v15.0.0%2Flib_crypto_backend_micro_ecc.html). Can you help me out with how to get the .a file from ecc-micro library that I can then include in the project build? (again, compiler: IAR EWARM 8.32)

    2.

    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 ?

    Regards,

    Manish

  • 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?

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


    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 ?

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

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

Related