The STM32F103 does not appear to drive its digital pins to known values immediately at reset. Only the analog pins are defined to high-impedance inputs at reset. If you read the ST Micro forum posts about this, non-Spark users of this processor have problems too.
The Spark code intentionally drives some digital pins low briefly during the start-up code. The reason for this is being looked at, but it happens out side your code. There are lots of posts here about the outputs âglitchingâ at startup.
So you will have a lot fewer problems if you switch your circuit to the analog pins.
@casm, I regret having to say you are right and there actually seems to be a problem I didnât experience before.
When I earlier said: âI canât see this on my Coreâ, I did test this on my local build Core that never saw a new Spark firmware
Iâve got a test circuit 3V3 -> LED -> 470Ohm -> jumper wire to connect to any pin.
And I do see your exact problem. The LED lights up and stays lit while connecting on all D pins, but not on any A pin and on RX/TX.
After connect the LED goes off on D2, D4, D5 and D6 - but not on D7 (partly expected due to on-board LED), D3 (expected due to default LOW) and unexpected on D1 and D0 (not due to I2C, since the same goes for other D pin constellations).
According to @peekay123âs early post, the JTAG pins are all applied Pullups or Pulldowns during reset/power on. The JTAG pins map to D3-D7. D5 will have a pull-up until the spark firmware runs and does hardware initialization at least, and maybe even until your setup routine runs and sets its specific hardware value.
@casm, I believe the only TRUE way you can avoid the boot sequence pin-level issue is to either use analog pins or put a tri-state buffer on the digital pins that you control via a single analog pin.
Thanks @peekay123, @kennethlimcp, @bko for your advice and @ScruffR for your advice and confirmation. @pra what you say is definitely not the case, the pin is high only briefly, it is then held low until the user code runs.
Analog pins looks like my solution shame i just got my prototypes built.
In that case it is high until the Spark hardware initialization changes the default pin mapping and mode. Seeing as that is the first thing to run after reset, it would be a very short period of time.
I have modified my prototype board to use A0 and it now performs as expected. The forum contributors and the forum data are incredible resources, I just wish I could read and absorb everything!
but it doesnât fix the problem. It only makes the switch much faster than placing it in the setup function but - is there any way around this problem, or my only solution would be to reverse the logic with the use of some transistors?
How about a pull-down resistor?
Since the pin will be Hi-Z till you set the pinMode() - and there is not internal pull-resistor attached on bootup, as would be with the JTAG pins - that should work.
@ScruffR that is an elegant and clean solution, but I never heard of attaching pull-down (or pull-up) resistors on OUTPUT digital pins. This is âby the guide bookâ solution?
If itâs a âweakishâ pull-resistor itâll be fine on OUTPUT too.
Thatâs whatâs done with I2C when writing LOW against a 4k7 pull-up resistor.