STMicroelectronics / STM32CubeWL

STM32Cube MCU Full FW Package for the STM32WL series - (HAL + LL Drivers, CMSIS Core, CMSIS Device, MW libraries plus a set of Projects running on boards provided by ST (Nucleo boards)
Other
99 stars 52 forks source link

RadioRandom() returns often just 0 #46

Closed J0hanss0n closed 1 year ago

J0hanss0n commented 1 year ago

Set-up LSM100A based Evaluation Kit (STM32WL55JC) STM32CubeIDE Version: 1.10.1 https://github.com/SeongJiIoT/LSM100A_SDK

Description Quite often the RadioRandom() function returns 0 which leads e.g. to a devnonce = 0 and breaking a JOIN request. For my setup it is reproducable by issuing a JOIN request right after a successful JOIN.

I tracked this down to insufficient waiting time in SUBGHZ_WaitOnBusy(). The initialization of the count variable with the MACROS SUBGHZ_RFBUSY_LOOP_TIME*SUBGHZ_DEFAULT_TIMEOUT seems wrong: Comment near SUBGHZ_DEFAULT_TIMEOUT mentions "HAL Timeout in ms" but the actual timeout is in the range of 100 microseconds. In my tests the maximum waiting time observed had been near 90000 cycles but the count variable is intialized with 36600.

If the Radio still reports busy when the random rx data is about to be retrieved, an error is reported, but not signalled to upper layer. Instead the random number is just filled with 0.

There's a chance my problem is only related to my SeongJi setup.

ASELSTM commented 1 year ago

ST Internal Reference: 134309

firmwareguru commented 1 year ago

Interesting observation and good sleuthing. I'm running a few devices based on the LORA-E5 modules on the Helium network and while the joins are generally reliable and quick (first request), I have noted instances where the device would sit in a join loop, making multiple requests. The Helium console would show the Join Requests only. I had thought that perhaps a nonce collision had occurred (re-used nonce) but honestly that is not likely if the radio was returning true random numbers. Perhaps the radio random function was seeding the nonce with 0 as described here. Looking forward to updated numbers here and giving it a go. Of course, the proper way to mitigate this is to store the join parameters persistently and re-use them (i.e., stay joined) over power cycles.

ALABSTM commented 1 year ago

Hi @J0hanss0n,

Version 1.2.0 has just been released on GitHub. Would you mind checking please? Our development teams could not reproduce the issue you reported using this version. Please keep us informed.

With regards,

ASELSTM commented 1 year ago

Hi @J0hanss0n,

Please allow me to close this thread as no activity. You can reopen it at any time if you have details to provide us to help you solve this issue. Thank you for your comprehension and thank you once more for your contribution.

With regards,