I am setting up the DFU example to compile in Clion using ARMGCC 4.9 2015q3 and cmake. Everything compiled as it should and the DFU advertises. However, when trying to do a firmware upgrade, I got Signature failed.
From further investigation, the fault comes from line 377 in dfu_req_handling.c:
err_code = nrf_crypto_ecdsa_verify_hash(sig_info_p256, &crypto_key_pk, &init_packet_hash, &crypto_sig);
nrf_crypto_ecdsa_verify_hash() returns NRF_ERROR_INVALID_ADDR, and with further investigation, I found that it was because crypto_sig.p_value is not aligned properly.
crypto_sig is defined with the line NRF_CRYPTO_ECDSA_SIGNATURE_CREATE(crypto_sig, SECP256R1); on line 142 in dfu_req_handling.c, and from the definition of NRF_CRYPTO_ECDSA_SIGNATURE_CREATE it can be found that the p_value of crypto_sig (crypto_sig_buffer) is not set to be alligned.
The init_packet_hash variable, which are also passed into nrf_crypto_ecdsa_verify_hash() is defined on line 146: NRF_CRYPTO_HASH_CREATE(init_packet_hash, SHA256);. In the NRF_CRYPTO_HASH_CREATE the p_value of init_packet_hash (init_packet_hash_buffer) is set to be alligned.
My question is, am I compiling the whole thing wrong, or is this a bug in the SDK? When changing line 142 in dfu_req_handling.c to __ALIGN(4) NRF_CRYPTO_ECDSA_SIGNATURE_CREATE(crypto_sig, SECP256R1); the DFU works as expected again (changed in dfu_req_handling.c as I don't want to change the source files of the crypto library).
TL;DR: Is it a bug that ..._buffer in the definition of NRF_CRYPTO_ECDSA_SIGNATURE_CREATE is not alligned? As it is required to be alligned by nrf_crypto_ecdsa_verify_hash()? DFU works again when the ..._buffer is specified to be alligned.
FIX: Change line 146 in dfu_req_handling.cto __ALIGN(4) NRF_CRYPTO_ECDSA_SIGNATURE_CREATE(crypto_sig, SECP256R1);
Links:
nrf_crypto_ecdsa_verify_hash()
