STM32H7B3I - Random Number Generator: Occasional SEED_ERROR

[Garnett.Robert]

Hi

I'm using the Random Number Generator in interrupt mode and am getting HAL_RNG_ERROR_SEED errors. I'm not getting clock errors. I use HAL to drive the rng.

The errors are quite infrequent, I don't have stats but probably 1 in 100000.

Are these errors to be expected or am I potentially doing something wrong?

I am running the CPU at 280 MHz. The clock settings are implemented by HAL and I haven't changed these.

The problem I have is that to clear the error you have to restart the rng which take up to 200 ms.

The entropy of the numbers isn't critical in my app as I'm only using the rng to purterbate test data around a mean. So I am thinking that I could just let the rng run without resetting it.

Regards

Rob

[TDK]

Seems like seed errors can occur and you need to monitor for them if you want the advertised randomness out of the peripheral. HAL does this for you. Seems like they should be incredibly infrequent, however, but definitely a finite probability.

 

The recovery sequence doesn't seem like it should take 200ms. But maybe it does.

 

[waclawek.jan]

Doesn't sound right to me. If I read the reasons correctly, there are 16+4 reasons for the error, all with probability of 1/2^64, resulting probability is roughly 10^18. Assuming sampling in the order of 10s of MHz, the error should occur roughly once in 10^10 seconds, i.e. 300 years.

This and also the long recovery time - whatever it means and entails - indicates something wrong either in RNG setup or in the circumstances. The RNG in 'H7 is an overcomplicated beast and it appears that it contains numerous obscure ways to problems (e.g. "magic numbers").

Is this a "known good" board such as Disco/Nucleo? How are both RNG clocks set, are they rock stable and do they obey all requirements set in DS and RM (e.g. RNG clocking chapter in RM)?

JW

[TDK]

> Assuming sampling in the order of 10s of MHz, the error should occur roughly once in 10^10 seconds, i.e. 300 years.

This also assumes it's a perfectly random generator, which it certainly is not as they're postprocessing the data.

The SEIS happens frequently enough that it made it both into the RM and the HAL library. The RM stating that you need to check it every time you read new data.

One can obtain raw RNG data "from ST" which may yield insight. Probably requires an NDA and someone from ST to respond.

[Garnett.Robert]

Hi

TDK

Like you I think that the output of the noise source cannot be truly random, although I believe it can be for practical use be extremely close.

ST claim that the RNG is a "True" random number generator and certainly imply the output is purely random not just the thermal noise source they use. I think that post processing as long as it applied is linearly, deterministically and with no discarding of data will produce resulting number cannot be predicted from previous outcomes and is therefore random. i.e. if I get an analog value from a thermal noise sources quantize it and then multiply it by two the result will be random. The trouble with this is that it requires the measurement of the analog noise values to be sampled linearly. Any non linearity will tend to bias the analog values measured and input to the system, so that the resulting seed numbers will have slight biases. This may influence the randomness of the 32 bit number produced, but I'm no mathematician so I could be wrong.

However I will ask ST about this as it is an interesting and point.

Regards

Rob

[TDK]

> ST claim that the RNG is a "True" random number generator and certainly imply the output is purely random not just the thermal noise source they use.

Where do they claim this?

Here's what they have to say in the F4 manual. It says nothing about a "true random." As the success ratio isn't 100%, presumably they're implying it is not perfect.

 

[Garnett.Robert]

Hi TDK

It is stated in RM0455 The Manual for the H7. I never mentioned an F4. The exact processor I am using is in the title of my post. I always put the part no of the processor in question in the title whenever it is relevant.

 

It seems pretty clear to me that they are claiming it is a "True" random number generator. I have raised a support ticket on this, hopefully they will explain it.

As I said in my original post on the subject I don't care much if it's perfect or not, I just need a good-enough random number for basic testing.

Best regards

Rob

[waclawek.jan]

> > Assuming sampling in the order of 10s of MHz, the error should occur roughly once in 10^10 seconds, i.e. 300 years.

> This also assumes it's a perfectly random generator, which it certainly is not as they're postprocessing the data.

True, but I also work out of the usual assumption that it's more likely to have a user/setup error (and that includes Cube/HAL errors), than ST and the certification authorities overlooking a fault source which would render the RNG inoperational for hundreds of ms.

JW

[TDK]

FWIW, I tested both an STM32F429 and an STM32H743 and couldn't get any error flags after hundreds of millions of samples, which is way less frequent than you're reporting. The RNG peripheral is different on the H7 compared to the F4. Note that the clock source feeding the RNG has some requirements, otherwise those flags will be tripped. Could be a clock thing.

H743:

 

F429:

[03:40.081125] dr_count=251392404, ceis_count=0, seis_count=0

 

[Garnett.Robert]

Hi TDK

Thanks for that.

I've been a way for a couple of days driving steam trains so I haven't got on to it yet. But I'll give your code a try and see what I get.

Regards

Rob

[Garnett.Robert]

Hi TDK

I made a test project similar to your code, but using interrupts as I am using interrupts in the Shortt clock project I am building. I don't thing using blocking or interrupts will make any difference to seed errors, but I wanted my test to be as close as possible to my application

Like you I got no errors. I used 64 bit counters to get more data, but still no errors.

The strange thing is I haven't had any more errors in my main project. I'm sure I wasn't imagining them as I put a breakpoints on the error code in the HAL RNG interrupt handler and the error happened twice.

I received an answer back on my service request. On the question of "true" randomness they said:

"The RNG output randomness is inherited from the randomness of the source.

To have a better feeling of the entropy of the RNG output, please refer to AN4320 "STM32 microcontroller random number generation validation using the NIST statistical test suite".

So I'm thinking that compared to algorithmic approximations of random number generation the numbers produced by the RNG are truly random by virtue of the fact they meet the NIST criteria.

On the question of recovering from a seed error there is a new HAL function: HAL_RNGEx_RecoverSeedError which was added in version 1.9 of the HAL Drivers. the code for this is:

/**
 * @brief RNG sequence to recover from a seed error
 * @param hrng: pointer to a RNG_HandleTypeDef structure.
 * @retval HAL status
 */
HAL_StatusTypeDef HAL_RNGEx_RecoverSeedError(RNG_HandleTypeDef *hrng)
{
 HAL_StatusTypeDef status;
 
 /* Check the RNG handle allocation */
 if (hrng == NULL)
 {
 return HAL_ERROR;
 }
 
 /* Check RNG peripheral state */
 if (hrng->State == HAL_RNG_STATE_READY)
 {
 /* Change RNG peripheral state */
 hrng->State = HAL_RNG_STATE_BUSY;
 
 /* sequence to fully recover from a seed error */
 status = RNG_RecoverSeedError(hrng);
 }
 else
 {
 hrng->ErrorCode = HAL_RNG_ERROR_BUSY;
 status = HAL_ERROR;
 }
 
 /* Return the function status */
 return status;
}
 
/**
 * @brief RNG sequence to recover from a seed error
 * @param hrng pointer to a RNG_HandleTypeDef structure.
 * @retval HAL status
 */
HAL_StatusTypeDef RNG_RecoverSeedError(RNG_HandleTypeDef *hrng)
{
 __IO uint32_t count = 0U;
 
 /*Check if seed error current status (SECS)is set */
 if (__HAL_RNG_GET_FLAG(hrng, RNG_FLAG_SECS) == RESET)
 {
 /* RNG performed the reset automatically (auto-reset) */
 /* Clear bit SEIS */
 CLEAR_BIT(hrng->Instance->SR, RNG_IT_SEI);
 }
 else /* Sequence to fully recover from a seed error*/
 {
 /* Writing bit CONDRST=1*/
 SET_BIT(hrng->Instance->CR, RNG_CR_CONDRST);
 /* Writing bit CONDRST=0*/
 CLEAR_BIT(hrng->Instance->CR, RNG_CR_CONDRST);
 
 /* Wait for conditioning reset process to be completed */
 count = RNG_TIMEOUT_VALUE;
 do
 {
 count-- ;
 if (count == 0U)
 {
 hrng->State = HAL_RNG_STATE_READY;
 hrng->ErrorCode |= HAL_RNG_ERROR_TIMEOUT;
 /* Process Unlocked */
 __HAL_UNLOCK(hrng);
#if (USE_HAL_RNG_REGISTER_CALLBACKS == 1)
 /* Call registered Error callback */
 hrng->ErrorCallback(hrng);
#else
 /* Call legacy weak Error callback */
 HAL_RNG_ErrorCallback(hrng);
#endif /* USE_HAL_RNG_REGISTER_CALLBACKS */
 return HAL_ERROR;
 }
 } while (HAL_IS_BIT_SET(hrng->Instance->CR, RNG_CR_CONDRST));
 
 if (__HAL_RNG_GET_IT(hrng, RNG_IT_SEI) != RESET)
 {
 /* Clear bit SEIS */
 CLEAR_BIT(hrng->Instance->SR, RNG_IT_SEI);
 }
 
 /* Wait for SECS to be cleared */
 count = RNG_TIMEOUT_VALUE;
 do
 {
 count-- ;
 if (count == 0U)
 {
 hrng->State = HAL_RNG_STATE_READY;
 hrng->ErrorCode |= HAL_RNG_ERROR_TIMEOUT;
 /* Process Unlocked */
 __HAL_UNLOCK(hrng);
#if (USE_HAL_RNG_REGISTER_CALLBACKS == 1)
 /* Call registered Error callback */
 hrng->ErrorCallback(hrng);
#else
 /* Call legacy weak Error callback */
 HAL_RNG_ErrorCallback(hrng);
#endif /* USE_HAL_RNG_REGISTER_CALLBACKS */
 return HAL_ERROR;
 }
 } while (HAL_IS_BIT_SET(hrng->Instance->SR, RNG_FLAG_SECS));
 }
 /* Update the error code */
 hrng->ErrorCode &= ~ HAL_RNG_ERROR_SEED;
 return HAL_OK;
}

Regards

Rob