Add SoftDevice rng version to MicroBitDevice::seedRandom().

[microbit-carlos]

Otherwise, calling this function when BLE is running results in 0xBBC5EED as always being used as the seed.

[microbit-carlos]

@martinwork could you review this PR?

This version is slightly slower, but it might be safer, would you agree?

[github-actions]

Build diff

Base commit: bd446c49f5501584e2cef3b5f53ebb826928e47b
Action run: https://github.com/lancaster-university/codal-microbit-v2/actions/runs/10852858654

     VM SIZE    
 -------------- 
  +3.9%     +44    /home/runner/work/codal-microbit-v2/codal-microbit-v2/libraries/codal-microbit-v2/source/MicroBitDevice.cpp
  +0.0%      +4    [section .text]
  +0.0%     +48    TOTAL

[martinwork]

Elsewhere, SOFTDEVICE_PRESENT and ble_running() have been nested the other way. Would another BLE implementation also block direct access to NRF_RNG, etc?

codal-microbit-v2/source/MicroBitFlash.cpp

Line 118 in e88ca61

#ifdef SOFTDEVICE_PRESENT

Does using sd_rand_application_bytes_available_get make it safer?

If sd_rand_application_bytes_available_get will eventually say 4 bytes are available, then a simple loop on sd_rand_application_vector_get should eventually succeed.

The only error sd_rand_application_vector_get returns is not enough bytes. In that case it has not written to the buffer.
https://github.com/microbit-foundation/codal-microbit-nrf5sdk/blob/d41d5c7ebe53a1d01935e61d4ffa891e5112e119/nRF5SDK/components/softdevice/s113/headers/nrf_soc.h#L472

Maybe there's a faint to non-existent possibility that an interrupt could steal a byte between sd_rand_application_bytes_available_get and sd_rand_application_vector_get?

I experimented some more, for interest... sd_rand_application_pool_capacity_get returns 64. Immediately after uBit.init() there are 1-3 bytes available. It takes >6500us for bytes_available to be 64. After that, claiming 4 bytes repeatedly takes <20us for the first 17 requests, then each request takes 300-500us.

With a loop like this, I haven't seen count go over 100.

      for ( int count = 0; count < 1000; count++)
      {
        if ( sd_rand_application_vector_get((uint8_t*)&r, sizeof(r)) == NRF_SUCCESS)
          break;
      }

Assuming any call like sd_rand_application_vector_get will eventually succeed makes me nervous, but I suppose it's just like this.

codal-microbit-v2/source/MicroBitDevice.cpp

Line 82 in e88ca61

while(NRF_RNG->EVENTS_VALRDY == 0);

[microbit-carlos]

Elsewhere, SOFTDEVICE_PRESENT and ble_running() have been nested the other way. Would another BLE implementation also block direct access to NRF_RNG, etc?

codal-microbit-v2/source/MicroBitFlash.cpp

Line 118 in e88ca61

#ifdef SOFTDEVICE_PRESENT

Yeah, we have discussed in the past exploring other BLE stacks, definitely not in the short term, but it is possible in the future that ble_running() could return true and SD not being present.

Does using sd_rand_application_bytes_available_get make it safer?

Right, not safer than checking the return state of sd_rand_application_vector_get in a loop, I was just comparing it as safer than the DAL implementation, which tries to get 4 bytes only once:
https://github.com/lancaster-university/microbit-dal/blob/master/source/core/MicroBitDevice.cpp#L343

If sd_rand_application_bytes_available_get will eventually say 4 bytes are available, then a simple loop on sd_rand_application_vector_get should eventually succeed.

Do you mean a loop trying to get one byte at a time instead of trying to get 4 bytes out in one go?

The only error sd_rand_application_vector_get returns is not enough bytes. In that case it has not written to the buffer. https://github.com/microbit-foundation/codal-microbit-nrf5sdk/blob/d41d5c7ebe53a1d01935e61d4ffa891e5112e119/nRF5SDK/components/softdevice/s113/headers/nrf_soc.h#L472

Ah, or do you mean to try in a loop until success?

while (sd_rand_application_vector_get((uint8_t*)&random_value, sizeof(random_value)) != NRF_SUCCESS);

Maybe there's a faint to non-existent possibility that an interrupt could steal a byte between sd_rand_application_bytes_available_get and sd_rand_application_vector_get?

Yes, but I think in those edge cases is probably fine for the default seed to be returned.

[martinwork]

it is possible in the future that ble_running() could return true and SD not being present.

I think the original idea was not to burden a no-BLE build with checking ble_running, and that maybe only softdevice precludes using the direct calls. On adding a non-softdevice BLE: if nested the old way it might just work; this way, it would initially revert to doing nothing, and need to be edited even if using NRF_RNG is OK.

Ah, or do you mean to try in a loop until success?

Yes, instead of a loop trying sd_rand_application_bytes_available_get. It's a bit hard to see in
#409 (comment)