Added temperature sensor calibration values. #506
Conversation
|
it should be fine to overlap them. However, I wonder if we should instead do a single "peripheral" for all these calibration values? Making one for each random calibration value is going to be a lot of churn. The 0x1FFFFxxxx area seems to be some kind of "factory OTP". UID also seems to be in that area. Where is this documented, does ST give some name to tihs "OTP calibration data" thing? |
|
Yeah that is probably a good idea to keep all that stuff together. Interestingly there is a bunch more info in that memory area. The "Device Electronic Signature" is also in the 
There is not a dedicated documentation for that memory area. It is all dispersed between the reference manual and the datasheet of the particular part. The addresses don't always have a corresponding define in the ST published headers either. The VRef internal calibration value and Temperature Sensor value addresses are usually listed in the datasheet of each part. One can find it by searching for For this particular patch I checked a few representative datasheets for each part family. I did not check them all to make sure there are no outliers. If we want to make a consistent structure for all this information we should check what possible memory arrangements we have throughout the STM32 families. The unique device ID existed in STM32 devices since STM32F1, so we will probably need a bunch of different versions of this "peripheral". Let me know your thoughts. |
|
The memory containing the data is usually not named at all by ST, but when it is named something it is either "Factory Information" or "Engineering Bytes". I still thing "Factory OTP" is most descriptive even though ST does not use the term as far as I can tell. As I could not find machine readable source of the memory locations I went ahead and spent the last 4 days compiling the values myself: https://docs.google.com/spreadsheets/d/1-ieFzBtAUM4z5IefX1OkKll63qaJ4KMeVZzAd5jBvVc/edit?usp=sharing it would be fantastic to at least get it spot checked by someone else. I am also happy to open a dedicated Issue to serve as the discussion thread for the new "peripheral". If you need the data exported into something we can commit to the repository let me know. The data I collected also indicates that we will have quite a big work cut out for us to figure out how to divide the peripheral versions so that we can cover the sheer variability of the stuff. Let me know what you think. |
|
Hi. I just found this PR. I also just brought up this question on the Matrix chat. I got no feedback. I'd be happy to have a chat concerning this suggestion. I also think this "peripheral" is quite useful for a plethora of uses. I also think that although there may be tons of variations across devices even having some is better than not having them at all. |
|
The Google Doc contains addresses for most if not all devices. I spent two weeks collecting them from all the ST datasheets that I could find. Someone (potentially me, but I have no idea when I will come around to it) has to find time to take that table and convert it to code that can be merged. We can then continue building on top of that into the higher layers of embassy. |
|
Let me see what I can do for next week. I'll send you a link to the branch on my fork if I make some headway into this. |
|
Here's my branch. I've only put like 3 families. |
I am not 100% sure that this is the correct way to add these values. They do straddle the location of the VREFINTCAL. But I also did not want to make them into two separate peripherals.