I'm testing this on two boards, both F4-based. I don't know if this is F4 specific, but I imagine someone else would have run into it if it affected other series as well. It could also be something specific to my setup, but I've accounted for that to the best of my ability.
The boards I'm using are:
- Discovery F407VG
- Custom F446VE Board
In both cases, using the latest version of this core for the F407VG and my fork for the F446, I am seeing a problem with the pins when used as inputs.
My understanding is that it's expected the pins will work as either digital or analog inputs by default, without any call to pinMode. The code in the Arduino AnalogRead examples tends to bear this out - there is no call to pinMode in that example, nor in any of the examples included in the STM32Generic core - i.e., the AnalogReadSerial_12bit example:
void setup() {
// initialize serial communication at 115200 bits per second:
Serial.begin(115200);
// configure the ADC for 12 Bits
analogReadResolution(12);
}
// the loop routine runs over and over again forever:
void loop() {
// read the input on analog pin 0:
int sensorValue = analogRead(PA0);
// print out the value you read:
Serial.println(sensorValue);
delay(1); // delay in between reads for stability
}
If I run that code on either of the boards I have, the results returned seem to have no relation to the actual status of the pin. On both boards, I'm seeing very low analogRead values, < 10. The value seems to have a small amount of noise present (i.e. it might change by a digit or two) but does not change if I connect the pin to 3.3V or ground.
This problem seems to extend to using the pins as digital inputs as well, the pins appear to be stuck low and do not change as the external voltage changes.
If I add the call to pinMode(PA0) to the above code, before the pin is read, then I see values as expected, both for digital and analog reads.
Is it possible the default pin setup is leaving the pins in the wrong state somehow? Obviously it's not a problem for me to add the pinMode call to my code, but some libraries or existing applications that depend on the default behaviour might not work as expected.