4 years, 5 months ago.

TRNG on DISCO-L475VG-IOT01A conflicting clock source

I've been playing around with the disco l475vg iot01a board and was attempting to enable the TRNG and the USB Device at the same time. These two peripherals use the same bus but due to what I believe to be a bug in the trng_api.c implementation the clock sources to the bus are not configured the same causing the USB Device to fail under certain circumstances.

According to the system_clock.c startup for the board and the corresponding *CLOCK_SOURCE* option in the targets.json file. The USB clock source is setup for MSI. and this indeed is what happens when attempting to startup the USB stack.

However if I also enable the psa subsystem with *psa_crypto_init()* the initialization code attempts to bring up the TRNG peripheral which should be making the decision based on the correct *CLOCK_SOURCE* config set in the targets.json file. however the masks for the clock selection do not exist as they do in the system_clock.c implementation file and it defaults to changing the clock source to the PLL because the #define for the clock selection masks is missing.

My quick work around is to copy the #define's from the system_clock.c file into the trng_api.c file and things work as expected.

This leads me to my follow up question, what is the encouraged route to take when attempting to patch the internals of the mbed os community. Should I go to the mbed os repository directly and report bugs do I contact the hardware vendor who is developing the HAL to mbed OS? How can I follow the activities that are on-going? there are multiple references to bug tickets on some internal arm jira servers, shouldn't we be able to view the development activity?

Thanks for reading, and any input you have.

-Brian

Question relating to:

ST
A world leader in providing the semiconductor solutions that make a positive contribution to people’s lives, both today and in the future.

Well in reading the release notes of MbedOS 15.14.2 I noticed that this issue has already been reported and solved.

https://github.com/ARMmbed/mbed-os/issues/11674 https://github.com/ARMmbed/mbed-os/pull/11679

I suppose this answers my question on reporting a bug to the mbed-os repo. But does anyone have any suggestions for understanding the structure of how bug fixes are developed? Or insight as to the function of the internal jira? do only contributors get to view that?

Thanks, -BB

posted by Brian Block 21 Nov 2019
Be the first to answer this question.