/* — there was a pullup in my shematics —
It seems that during flashing new code the A4 pin is activly driven high for some time.
External hardware on this pin can cause damage to the core and the external hardware.
Pins should be inputs until other actions during user code.
It is happing during reset too.
*/
Pin D7 is driven HIGH during flashing which can be seen on the small blue led,
but not during reset.
Any idea why / where this happens?
Does it belong to other pins too?
I’m not sure what you are asking here.
Did you use pinMode() and digitalWrite() to set the pin of D7? It should remain in the same state prior to OTA.
Eg.
void setup(){
pinMode(D7,OUTPUT);
pinMode(D7,OUTPUT);
digitalWrite(D4, LOW);
digitalWrite(D7, LOW);
}
You can try with this code and perform an OTA. The pins should remain LOW.
Thanks.
Programming the core works fine.
When I flash new code, during the flashing procedure the led on D7 is flashing.
So it seems that something alters the pin during flashing, that could cause
connected hardware problems.
Weird. I dont think that is what i am observing but i will try again and report back
Hi @miky
Another good question to ask here is what is connected to D7 since that could be pulling it high or partially pulling it high and lighting the LED.
@bko and @kennethlimcp, I have to back @miky in this.
My Cores do something similar. The D7 LED comes on (dimmly) during flashing, as if it was powered via the internal pull-up - even without any ext circuitry attached.
It could also be quick on/off duty cycle, but I doubt that and will have a look with my osc.
Edit: Checked it and it’s definetly a constand signal of about 2.3V during the rapid magenta blinking (actual flash write) phase
This is not new for me - I got this right from the beginning, so I assumed it to be normal and I’m surprised that others don’t see it 
Knowing this behaviour I always avoided using D7 with any circuitry that couldn’t cope with that - just the same as with the “start-up low” problem on all the D pins.
Hi,
thanks for all of your inputs!
It shows up when flashing the bare metal (so only the core on a USB cable).
@ScruffR your analysis is great!
The “start-up low” problem sounds worse too!
Maybe we should set all pins to high impedance input at startup?
1.) I assumed the OP was "flashing" using OTA so my bad
2.) Will check the behavior during DFU mode and see what i find out`
3.) As @ScruffR pointed out:
So this is not a problem DURING OTA but during the moment when code is copied to the STM32.
We need to get on the same page for this before checking further 
To set DFU_Util mode you press reset and hold the mode button down for the required period of time. The boot loader is started by the reset and monitors the mode button, and places the spark core as responsive to DFU_Util commands. I’m pretty sure the boot loader does nothing with GPIO pins, as pin mapping is done later in the hardware initialization in the spark firmware.
The following in an extract from RM0008, the technical reference for the STM32F1XX.
**8.1.1 General-purpose I/O (GPIO)**
During and just after reset, the alternate functions are not active and the I/O ports are configured in Input Floating mode (CNFx[1:0]=01b, MODEx[1:0]=00b).
The JTAG pins are in input PU/PD after reset:
PA15: JTDI in PU
PA14: JTCK in PD
PA13: JTMS in PU
PB4: NJTRST in PU
When configured as output, the value written to the Output Data register (GPIOx_ODR) is output on the I/O pin. It is possible to use the output driver in Push-Pull mode or Open-Drain mode (only the N-MOS is activated when outputting 0).
The Input Data register (GPIOx_IDR) captures the data present on the I/O pin at every APB2 clock cycle.
All GPIO pins have an internal weak pull-up and weak pull-down which can be activated or not when configured as input.
D7 is PA13/JTMS so it will have an internal pull-up applied until the spark firmware runs and performs its hardware initialization. I’ve noticed in the past that when using the JTAG shield and STLink, the D7 Led is always doing something (which is should being JTMS). To use JTAG you have to set/change a #define in the firmware to prevent hardware initialization from remapping the JTAG pins as GPIO.
This explains a constant signal on D7 while flashing with DFU_Util. It will stay on until DFU_Util completes and the boot loader gives control to the spark firmware. I have no idea what would cause it to flash if that is happening, which now doesn’t appear to be the case anymore.
@pra,
great information! So i guess there’s no way we can change this behavior? Or there’s still possibilities during DFU mode?
I would love to have this condition stated in documentation 
Opened a github issue to make sure i don’t miss it: https://github.com/spark/docs/issues/321
This should also help to answer the behavior during startup/reset/other modes
Well, it is stated in RM008 which maybe should be mandatory reading 
Thought i would ask since DFU is not a reset condition and the pins should all be set to high Z if possible.
What RM008 mentioned is for reset condition and we should be able to initialize the pins in DFU mode
FYI; @bko, @kennethlimcp, @miky, @ScruffR
On my cores D7 is dimmly lid during flashing like said above
In order to pull some threads about this issue together, I created a new topic in the troubleshooting section
You cannot take a core from running an application to DFU without pressing reset or turning power on/off. As DFU is an optional state between reset/powerup and the execution of the spark firmware, you would have to change the boot loader to initialize the pins. You are definitely size constrained there, and I don’t know what that would do to people (like myself) who expect JTAG pins to be JTAG pins and use the STLink utility or a debugger to load the application.
Even if you did do this in the boot loader, the reset state of the JTAG pins would exist from reset until the boot loader code run, even if only for a few microseconds. Even this short periods would be enough to affect attached electronics that expected different.
In the I/O expansion board I made for the CC3200 Launchpad, I didn’t bring the JTAG pins out as GPIO (they are still on the Launchpad itself for debugging). Nor are the I2C or SPI standard pins available as GPIO (they have their own connections). This simplifies/eliminates having this issue.
Yup, gave this a thought as well.
So my conclusion thus far is to have this documented down so that users are aware.
Thanks for the input everyone!