Can I back-port the latest version of ocrypto to nRF5 SDK?

[Elias]

I have a product that uses the nRF5 SDK that I do not plan to migrate to the nRF Connect SDK. My product uses ocrypto 3.0.8, which shipped with the latest version of the nRF5 SDK. I would like to use the most up-to-date version, v3.0.15.

What I've tried doing is to simply pull "oberon_3.0.15.lib" from sdk-nrfxlib/crypto/nrf_oberon/lib/cortex-m4/hard-float/short-wchar at main · nrfconnect/sdk-nrfxlib (github.com) and have it replace "oberon_3.0.8.lib" in my Keil project. However, I get the following linker error:

.\_build\nrf52832_xxaa.axf: error: L6007U: Could not recognize the format of file ..\..\..\..\..\..\external\nrf_oberon\lib\cortex-m4\hard-float\short-wchar\oberon_3.0.15.lib.

Why is this? I would have guessed that "3.0.15.lib" is the same format as "3.0.8.lib". What is the correct way to incorporate the latest version of the library to my Keil project?

[Hieu]

Hi Elias,

I don't think it's safe to change the Oberon library version. But a colleague mentioned that the error is about file format, so could you please check if the downloaded file is corrupted or not? The simplest way is to download another one and compare the files; or you could also use nm -a oberon_3.0.15.lib to check if the file is good.

Hieu

[Elias]

Ah, it appears I don't know how to use Github. After trying to diff a copy of the file for the same version of the library, I realized the ".lib"s I was downloading were XML files. The solution was to download the "raw" file instead of "Save link as".

However, now that I'm using the correct file, I'm getting a different linker error:

.\_build\nrf52832_xxaa.axf: Error: L6238E: ocrypto_bigint256.s.obj(.text) contains invalid call from '~PRES8 (The user did not require code to preserve 8-byte aligment of 8-byte data objects)' function to 'REQ8 (Code was permitted to depend on the 8-byte aligment of 8-byte data items)' function ocrypto_mul256_noframe.

I'm digging into this linker error now, but haven't found a solution. Surely, support for uVision was not completely dropped in the nRF Connect SDK.

[Hieu]

Hi Elias,

Unfortunately, support for uVision is completely dropped in the nRF Connect SDK (NCS).

The nRF5 SDK versions were also not test with these newer versions of the Oberon library in NCS, so there is no guarantee that it will work.

And to be honest, the Oberon library is licensed in a way that we can only provide in .lib form. Even if we tried to dig into this, and I learned any details, it would be unlikely that I can reveal it to you. 

Considering those facts, I recommend staying with the Oberon library version integrated in your nRF5 SDK version.

If you need any newer functionality, please consider moving to NCS. The nRF5 SDK is in maintenance mode, and we don't recommend any new project to use it.

Hieu

[Elias]

I'm not using the "nrf_crypto" module, just using the ocrypto functions directly from application, so there shouldn't be any issues with SDK compatibility.

To correct myself, I'm not actually concerned with "uVision" support. I am concerned with ARM Compiler support. If NCS projects can be compiled with the ARM Compiler, they should work with uVision. Is ARM Compiler 5 supported?

[Hieu]

We are unfortunately not certain whether or not the Oberon lib file in NCS supports ARM Compiler 5.

If you want to pursue this approach, is it possible for you to try with SEGGER Embedded Studio or GCC and make instead?

If you use SEGGER Embedded Studio, please remember to use the same version that the SDK was released and tested with. For nRF5 SDK v17.1.0, it's v5.42a. Newer versions are known to have incompatibilities issues.