Why use sd_ecb_block_encrypt() vs nrf_ecb_crypt()?

[Elias]

There are two APIs in SDK 14.2 to access the nrf52832's AES core. What's the difference in behavior between the two?

I noticed that nrf_ecb_crypt() has a useful return value and sd_ecb_block_encrypt() does not. Does this mean that sd_ecb_block_encrypt() internally calls nrf_ecb_crypt() and tries again if it doesn't succeed, or blocks if the SoftDevice is going to use the hardware?

I noticed this question (https://devzone.nordicsemi.com/f/nordic-q-a/5871/nrf51822-aes-hw-module-clarification) almost answers my question, but I'm not sure whether the behavior is different for the nRF51's SoftDevice, and I'm also not sure how that answerer knows what a SoftDevice does "under-the-hood".

[Kenneth]

Hi, there are two api calls depending on whether the softdevice is enabled or not:
https://infocenter.nordicsemi.com/topic/sds_s132/SDS/s1xx/sd_resource_reqs/hw_block_interrupt_vector.html 

The implementation in the softdevice api call should in general provide the same functionality as if the application have direct access, but the return code and actual implementation may differ.

[Elias]

Okay, this does clarify things. Why does sd_ecb_block_encrypt() only have a "success" return value?

[Kenneth]

Because it will not fail.