psa_generate_key fails with Error -134 on Thingy:91X using ECDSA sample in NCS v2.9

[JoseQS]

Dear Nordic team,

I am currently working with the Thingy:91X (nRF9151) and nRF Connect SDK v2.9.0, and I am attempting to run the official ECDSA sample from your documentation:

 ECDSA sample documentation

However, when executing the unmodified example, I encounter this runtime error:

I understand that error code -134 corresponds to PSA_ERROR_NOT_SUPPORTED, which typically indicates that the backend does not support ECC key generation. However, despite reviewing the configuration and ensuring that all required PSA and Mbed TLS options are enabled, I have not been able to determine the root cause of the issue. Could you please assist me in identifying what might be missing or misconfigured?

Update:

I decided to test the same project on an nRF9161 DK and noticed that it worked correctly after including the additional Kconfig fragment that is provided in the example for this board. After adding the proper fragment, psa_generate_key() no longer failed with error -134.

Encouraged by this, I tried to do the same with the Thingy:91X, but it doesn't seem to include a corresponding extra Kconfig fragment by default. So, I copied the nrf9151dk_nrf9151_ns.conf file and renamed it to thingy91x_nrf9151_ns.conf, with the following content:

#
# Copyright (c) 2024 Nordic Semiconductor ASA
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#
CONFIG_TFM_PROFILE_TYPE_NOT_SET=y

# Using hardware crypto accelerator
CONFIG_PSA_CRYPTO_DRIVER_CC3XX=y

Unfortunately, after doing this, I ran into a new issue: the application no longer fits within the available memory on the Thingy:91X.

However this is weird because with the same configs when compiling for the 9161SDK this is the result in terms of space:

My new Question:

Is there a way to configure the ECDSA sample so that it both compiles successfully and passes key generation at runtime on the Thingy:91X?
And importantly: Will such a configuration still support GNSS reception and FOTA updates?

Any guidance you can provide would be greatly appreciated!

Thank you in advance for your help.

Best regards,
José Sarmento

[Hakon]

Hello,

In the two screenshots in the ticket, you are comparing two different partitions, where the overflowing one is TF-M when CONFIG_TFM_PROFILE_TYPE_NOT_SET is enabled. The other one is the application, which has a lot of free space in any configuration.

 

Two run the sample, you need to do two things:

• Set CONFIG_PM_PARTITION_SIZE_TFM_SRAM=0xc000 in either prj.conf or the Thingy 91X board file. This is because the TF-M SRAM partition is set to 0xa000 by default for the board
• Create a sysbuild.conf file in the root of the sample and add SB_CONFIG_THINGY91X_NO_PREDEFINED_LAYOUT=y. This is to let the partition manager set the TF-M flash partition dynamically instead of using the default partition layout. Note that this will make the resulting firmware build incompatible with the factory-programmed bootloader on the device, and requires an external debugger to flash the board.

[JoseQS]

Thank you for your answer! One clarification:
If I flash the firmware using the dynamic partition layout (SB_CONFIG_THINGY91X_NO_PREDEFINED_LAYOUT=y), will that prevent me from using FOTA?

Thanks again for the support!

[Hakon]

JoseQS said:

will that prevent me from using FOTA?

Yes, I think so. If you can't use the bootloader to update the image on the device, then that would mean FOTA is impossible.

[JoseQS]

Thanks for the clarification. Given that FOTA is essential for our use case, especially since the device will be deployed in an unreachable location. Is there any alternative approach to enable encryption without compromising GNSS, LTE, or the ability to perform FOTA updates?

[Hakon]

There could be a way to make FOTA work if you make sure the partitions are the same in the new image every time. You can achieve this by specifying the partition sizes in pm_static.yml.