Why were references to the STM32L051C8 RNG peripheral removed?

[DAlbe.3]

In some ST documents the STM32L0X1 is listed as having an RNG peripheral and older versions of the CMSIS headers list the RNG register addresses. Moreover, enabling the peripheral and using it appears to generate random numbers. However newer manuals and CMSIS headers appear to have removed references to the RNG. What's the situation?

[Amel NASRI]

Hi @Community member​ ,

Only STM32L0x2 & STM32L0x3 have TRNG available.

RNG isn't available in STM32L0x1, and reference manual as well as CMSIS headers were updated in order to make this aligned.

May you please precise the ST documents where RNG is still listed as STM32L0x1 peripheral?

-Amel

[DAlbe.3]

Well that's troubling; quite some time ago, I selected and designed the STM32L051 into a product based on that documentation, using the RNG for AES IV generation. Moreover, the peripheral seems to be there: you can enable it in RCC and then get random numbers from it...although I have not tested their true randomness, they certainly appear random.

The current RNG peripheral document is AN4230 (STM32 microcontroller random number generation validation using the NIST statistical test suite - Application note). On table 2 (page 2), it clearly lists STM32L05x. Please note that when specific versions are referenced, the table lists them explicitly such as STM32L072/073 rather than using an x. It seems clear that the STM32L051 includes the RNG and that ST decided at some point that it was not usable and removed the peripheral references.

This is why I am asking for more information as to what actually happened: you said that "reference manual as well as CMSIS headers were updated in order to make this aligned". What caused the update (removal)? Does the RNG fail SP800 or in some other way fail to behave as a TRNG? A manufacturer should never just silently remove references when there is a problem, that's what errata are for. In any complex product, there will be problems, but it's important to let designers know about them so we can work around them properly.

So: I would be grateful if you would please let me know what the issue was with the L051 RNG that caused it to be removed from the reference documentation.

Thanks and regards,

David

[Peter BENSCH]

Application notes such as the AN4230 are not relevant for product details, that is only and exclusively what the data sheets are for. And exactly in the data sheet of the STM32L051 there has never been a peripheral device TRNG or RNG.

It could possibly be that with the STM32L051, where an RNG worked, you had a so-called umbrella device, which contained a higher-level chip that was only partially tested and where only the parameters in the data sheet are guaranteed. So if this chip (only theoretically assumed) had common parameters with the STM32L052, it could have been in the initial phase that you only had one common chip, which were nevertheless tested differently for the respective data sheet parameters. In this case, it would be conceivable, but still not covered by the functional guarantee of the data sheet, that peripherals appear to work, but are not guaranteed in the data sheet.

So it is still true, and in this case especially true, that only those functions are guaranteed that are mentioned in the data sheet (not in application notes). In this respect, @Amel NASRI​'s statement that a TRNG (which is a much improved RNG) is only included and guaranteed to work on the STM32L0 in the STM32L0x2 and STM32L0x3 families is completely correct.

Does it answer your question?

Regards

/Peter

[DAlbe.3]

I appreciate the detailed answer (and also the quick responses from you (Peter) and Amel. We knew something bad was likely when we updated to a newer CMSIS and the RNG code stopped compiling. We had hoped that the situation was that the L051 RNG had proven insufficiently random and so was removed from the datasheet; this would have been OK for us because we generate IVs very infrequently so imperfect would still have been good enough for our application. However, it sounds like we're out of luck and will have to find a workaround and a solution for fielded product.

While I understand the need from a corporate perspective, this statement: "Application notes...are not relevant for product details" is disappointing: including incorrect product details in an app note is obviously much worse than not including product details at all; suggesting that developers can't trust what's in the app notes is not good (it begs the question: what other details can't we trust?). Just my $0.02: it's better to just acknowledge that the app note has an error (everyone makes mistakes), fix the app note and add a note in the product errata - developers are used to checking errata.

Thanks again for the quick responses; my question is answered; please feel free to close or delete this thread as you see fit.

Regards,

David

[Nikita91]

In a large company which has quality procedures and standards (ISO9000...) to respect, it is difficult to recognize that there has been an error. This would indicate a breach or defect in the quality procedures. It is easier to say that the content of the document is not important and not rock the boat...

[Peter BENSCH]

Unfortunately, this gives the wrong impression. As already mentioned, it is instead correct that the respective data sheet is always responsible for the guaranteed function of a component; all other documents only have a supplementary and informative character.

Since the data sheet of the STM32L051 never mentions an RNG/TRNG, its function is therefore not guaranteed.

Regards

/Peter

[Nikita91]

only have a supplementary and informative character

But false information...

So actually now what to believe in these application notes?

You don't seem ready to admit there was a mistake and correct it.

Too bad, the reliability of information and transparency are essential to have confidence.

[Tesla DeLorean]

Sorry, I think ST is playing dodge ball here, they have made representations that the part has a T-RNG

What's being asked for is an EXPLANATION, supported by data, as to why this was subsequently walked backward.

http://www.emcu.it/MKT/Mar16/Silica_Friday.pdf

[DAlbe.3]

In fairness, mistakes happen; I certainly make more than my share. I appreciate how responsive ST staff is on this forum and even though I wish the answer were different in this case, I'm grateful that they responded quickly and knowledgeably. Because there has been some confusion on this, and because it is not reasonable to expect customers to know what information they can and can't trust in ST app notes, I encourage ST to consider adding a note about this in the component errata. In the interim, we'll have to develop a poor-man's RNG using other analog peripherals (e.g. LSI, MSI, HSI) on this part.