AnsweredAssumed Answered

STM32F0xx findings

Question asked by waclawek.jan on Nov 14, 2016
Latest reply on Feb 24, 2017 by waclawek.jan
Branched to a new discussion
In a new project there are several identical STM32F031 devices in a role of a slave mcu, driving LEDs and reading in various input signals. As their functionality is very similar, it is tempting to have only one single binary to simplify production. However, the devices have several different IO configurations, i.e. the LEDs and inputs are on different pins for the different role devices, so the program needs to "know" which configuration mcu is it running on.

My idea is to distinguish the configurations based on LEDs being connected to different pins on different configurations. There is always at least one pin for each particular configuration, where in that configuratio a LED is connected (anode to pin, cathode through resistor to ground) and in other configurations this pin serves as an input, guaranteed to be at logic 0 or 1 all the time. So the idea is to measure voltage while pullup is enabled - the LED would ensure cca 2V, whereas other pins would be at 3.3V VCC or GND.

So I went to the DS and RM0091rev.8 to re-read carefully the GPIO chapter. To my disappointment, the Analog configuration clearly reads that the pullups/pulldowns are disconnected (and I confirmed that that is the case indeed with a simple program).

However, DS says, for pins connected to ADC (all of them in this particular case), that they are of "TTa" type, "3.3 V-tolerant I/O directly connected to ADC". My reading of this is that, while the pulls are disconnected in Analog mode of pin, the analog input to ADC is NOT disconnected in every other mode - regardless of what the RM says and displays on the simplified schematics.

And, true enough, this works - setting the pins to ... whatever, input or OC output, the ADC reflects the true voltage on the pin. Of course I understand that the precision of readout may be slightly compromised by the digital input buffer loading and/or digital noise parasitically coupled through it, but in this particular case it does not matter.

So, my question to ST is, is there any cirumstance under which a TTa-marked pin woudln NOT be connected to ADC?

If none, could this fact (that ADC is connected to TTa pins also in non-Analog settings in GPIO) please be mentioned in the RMs?

---

Second observation relates to the ADC's clock. There is a dedicated 14MHz RC oscillator (HSI14), and by default that is selected as the ADC clock (the other option is the APB clock, and there is an explanation of pros and cons of both options in the RM, which is OK). However, the ADC chapter avoids using the "HSI14" name for this clock, which is confusing. I understand the reason (the glued-up-from-IPs nature of these chips unfortunately impacts also the documentation); but I'd like to ask ST to unify the variuos signals' names across the whole RM.

---

There is one more issue with this signal. This HSI14 clock can be switched on and off using  RCC_CR2.HSI14ON, and its current state is indicated by RCC_CR2.HSI14RDY. When the latter changes from 0 to 1, RCC_CIR.HSI14RDYF is set (pending enables it fires an interrupt). So far so good. HSI14 is promised (in ch.7.2.9) to be automatically switched on when selected and used(*) in the ADC (and this behaviour can be disabled by RCC_CR2.HSI14DIS which also works as promised). So I expected, that fiddling with ADC, I will see RCC_CR2.HSI14ON and/or RCC_CR2.HSI14RDY to go up. This did not happen, both bits remained at 0, although I confirmed through outputtin HSI14 to MCO that it (*) switched on either during calibration (and switched off automatically when calibration ended), or all the time while ADCEN was set (these circumstances when HSI14 gets enabled from ADC might perhaps deserve a mention, too).

So, I'd like to as ST to add a remark to  RCC_CR2.HSI14ON and RCC_CR2.HSI14RDY description in RM, that they are *unaffected* by the automatic-switchon-from-ADC. Note that there *is* such a remark at RCC_CIR.HSI14RDYF.

---

While fiddling with enabling/disabling the ADC and its clock, I noticed that in the Snippets in App. A, in very first example, prior to calibration there is a check if ADCEN is set, and if it is, there is an attempt to switch it off by clearing it. However, this can't be done as ADCEN can be cleared only by setting ADDIS (after ensuring a conversion is not running - as the third example demonstrates), so the presented snippet would lock up if the ADC was enabled before calibration. Can ST please correct this both in the RM and the Snippets.

-----

Thanks,

Jan Waclawek

Outcomes