TRNG Error: Conflict between BLE and Wi-SUN

[eriknayan]

Description of defect

When running simultaneously the BLE stack and the Wi-SUN interface, the application returns a Fatal Run-time error in the HAL_RNG_GenerateRandomNumber function. It doesn't happen until both WisunInterface and BLE are up.

After some investigation, I found out that the error occurs inside the stm32wbxx_hal_rng.c in line 574:

 while (__HAL_RNG_GET_FLAG(hrng, RNG_FLAG_DRDY) == RESET)
    {
      if ((HAL_GetTick() - tickstart) > RNG_TIMEOUT_VALUE)
      {
        hrng->State = HAL_RNG_STATE_READY;
        hrng->ErrorCode = HAL_RNG_ERROR_TIMEOUT;
        /* Process Unlocked */
        __HAL_UNLOCK(hrng);
        return HAL_ERROR;
      }
    }

Target(s) affected by this defect ?

NUCLEO_WB55RG

Toolchain(s) (name and version) displaying this defect ?

GCC for Arm (gcc-arm-none-eabi-9-2019-q4-major)

What version of Mbed-os are you using (tag or sha) ?

mbed-os-6.0.0 (165be79)

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

mbed-cli 1.10.2

How is this defect reproduced ?

This issue occurs either when the BLE stack is started after the Wi-SUN interface is connected or when the Wi-SUN interface calls the connect method after the BLE initialization. It seems that the problem is related to both instances trying to access the TRNG.

I'm using the last version of the BLE Full stack firmware from STM32Cube_FW_WB_V1.7.0.

@jeromecoutant @mikter

[ciarmcom]

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers.
Internal Jira reference: https://jira.arm.com/browse/MBOTRIAGE-2723

[jeromecoutant]

Hi @eriknayan

I am investigating with BLE experts, but you can check in parallel the application note describing RNG use in both STM32WB core (M4 and M0+):
https://www.st.com/resource/en/application_note/dm00598033-building-wireless-applications-with-stm32wb-series-microcontrollers-stmicroelectronics.pdf

Note also that there are few updates inSTM32WB since 6.0 release to enable AES HW crypto and USB device, so maybe you can have a try with the master branch ?

@LMESTM

[eriknayan]

Hi @jeromecoutant ,

Thanks for the quick answer!

Sure, I'm going to take a look at the AN you sent me to help finding what may be the cause of the issue. It looks like the TRNG can't provide a new number when both BLE and Wi-SUN are up (because RNG_FLAG_DRDY is always in RESET state).

Regarding the test with the master branch, I've just pulled it here and I still get the same error.

[jeromecoutant]

It looks like the TRNG can't provide a new number when both BLE and Wi-SUN are up (because RNG_FLAG_DRDY is always in RESET state).

Need to check why the CFG_HW_RNG_SEMID semaphore use is not sufficient?

Maybe we can have a look on this part:
https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/trng_api.c#L41

Regarding the test with the master branch, I've just pulled it here and I still get the same error.

Thx for the test

[eriknayan]

Yes, I guess it's probably related to a TRNG concurrence by both interfaces.

Maybe we can have a look on this part:
https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/trng_api.c#L41

I'm going to have a look on this!

[eriknayan]

Hi @jeromecoutant , any news about the issue?

https://www.st.com/resource/en/application_note/dm00598033-building-wireless-applications-with-stm32wb-series-microcontrollers-stmicroelectronics.pdf

I've read the AN and couldn't figure out what may be problem. It looks like the Sem0 should be enough to manage the RNG IP sharing between the two CPUs, but for some reason the RNG gets stuck and can't provide new numbers after the Wi-SUN interface and the BLE Stack are up simultaneously.

[jeromecoutant]

Hi
Could you try to comment all trng_free lines?
https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/trng_api.c#L126

[eriknayan]

Hi @jeromecoutant ,

I've commented these lines and I got the following MbedOS Error:

Error Status: 0x80FF0100 Code: 256 Module: 255
Error Message: Fatal Run-time error
Location: 0x8084D57
Error Value: 0x0
Current Thread: main Id: 0x20016D88 Entry: 0x807B895 StackSize: 0x6E20 StackMem: 0x2001D1A0 SP: 0x20023DD4 
For more info, visit: https://mbed.com/s/error?error=0x80FF0100&tgt=NUCLEO_WB55RG
-- MbedOS Error Info --
Only 1 RNG instance supported

So apparently the semaphore is working as expected...

[jeromecoutant]

Let's remove more lines:
546ecde

[eriknayan]

I've run this test here and still have the same issue:

++ MbedOS Error Info ++
Error Status: 0x80FF0100 Code: 256 Module: 255
Error Message: Fatal Run-time error
Location: 0x8084D71
Error Value: 0x0
Current Thread: main Id: 0x20016D88 Entry: 0x807B885 StackSize: 0x6E20 StackMem: 0x2001D198 SP: 0x20023DCC 
For more info, visit: https://mbed.com/s/error?error=0x80FF0100&tgt=NUCLEO_WB55RG
-- MbedOS Error Info --
trng_init: HAL_RNG_GenerateRandomNumber

[jeromecoutant]

Let's introduce a RNG_inited variable:
jeromecoutant@aa2ed61

[eriknayan]

With the RNG_inited variable, the application run without problems until the Wi-SUN EAP-TLS handshake:

[DBG ][tlsp]: TLS: start
[ERR ][tlsl]: drbg seed fail
[ERR ][tlsp]: TLS: library init fail
[DBG ][tlsp]: TLS: finish
[ERR ][eaps]: EAP-TLS: handshake fatal error
[INFO][eaps]: EAP-TLS finish