Hi,
I need some help, can anyone tell me what condition the digital I/O pins are in at power up but before the WIFI connection is established for Spark Core. When my system cannot connect and my firmware is not running I need to know what condition the I/O pins are in.
Any advice much appreciated.
Best regards,
Clive
They should be in High-impedance state during the brief moment upon power up to the execution of setup ().
Many thanks for your fast reply. Am I correct that if no WIFI is found setup does not run - I know my code does not run, my assumption is until the system gets WIFI it is high impedance. I am using automatic mode for connection.
Best regards,
Clive
Yes I presume that’s the case in general for microcontrollers but if you want to be sure you can use an external ppull-up/down resistor
To extend @kennethlimcp 's answer, on D pins there is (or may be was, if this got fixed without me knowing) one very short moment before these pins enter stable high impedance mode where these pins go LOW very briefly.
So if you got any circuitry that would have problems with that you could either move this over to an A pin, or apply some HIGH triggered enabling logic.
Something to read in connection
Hi @Scruffr and @kennethlimpc
Thank you very much for your replies, this is useful for me. I had hoped to have my photon’s by now so sidestep my start up issues but not long to wait now…
Best regards,
Clive
Hi,
Has this now changed my prototype goes low not high impedance while connecting to the WIFI. I designed for tristate during start up before connecting to WIFI.
Best regards,
Clive
I don’t think anything was changed since the hardware for the core is the same. If you have tristate design then it should work for all cases 
Hi @kennethlimcp,
Thanks for the reply. I have designed for the output to be held high during tristate start up so if the core cannot connect to the WIFI mt local control keeps running. Now my local control does not run as the pin is not tristate it is low.I have to redesign now for active low on the pin as I cannot do anything with them until the WIFI connects.
Best regards,
Clive
@casm, as @ScruffR pointed out, the issue of the momentary low at startup only affects the digital pins (D0-D7) and the analog pins (A0-A7) correctly stay in tri-state mode. Are you using an analog pin in your design?
@kennethlimcp, I'm not sure if you are aware of this little design flaw in the boot-up process of the Core, but AFAIK the trouble with D0-7 going LOW for a brief moment during boot-up is prevalent and can't be worked around with passive pull-up resistors, since the LOW state is "forced" by the STM32 and you'd need a really low value pull-up to counteract this 
The only way around this seems to be what I suggested in my post if March 11 in this thread (as @peekay123 kindly mentioned already).
Hi Sorry,
I am not being clear. The glitch at start-up is not my issue. I am finding the pin is staying in low state not just a glitch to low. A glitch for me does not matter it is the pin stays in low state not tristate whilst the core is connecting.
I think as you said it is another trip to the PCB house for a redesign to the analog pins, I was saving these for future expansion plans for sensors.
Thanks for the input.
Best regards,
Clive
@casm, which pin specifically is staying low after startup? All pins should be setup as tri-state inputs on boot-up IMO. The user code should then set the pins as required, in a predictable fashion.
@casm, could you please provide some boiled down code that shows this behaviour and as @peekay123 said which pin you’re seeing this on and also how you’re testing that behaviour.
Since I can’t find this on my Core when looking at a A or D (apart from the aforementioned glitch).
@casm & @ScruffR, the STM32 ref doc says:
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
I'm looking at the alternate pin function and pin mapping config in the firmware. The bootloader code does not appear to play a role IMO.
@peekay123, I’m not sure what you are refering to here, but if it was my use of the therm “boot-up process”, I did on purpose not use the term “bootloader”, since I never suspected it to play a role here, after Matthew (mdma) pointed out in an other thread earlier that it only gets active in DFU- and factory reset mode - if I remember right.
But since I can’t tell if it is a Spark framework or STM32 thing with that D-LOW-glitch, I used a “boot-up process”. Maybe it would have been better called “start-up process” to avoid confusion.
At the moment I’m trying to put together some test code to look for that problem, without too much external circuitry or equipment.
@ScruffR, no problemo. I just wanted to clarify where the search needed to go. I was looking at the main.c code in the bootloader to see if there was any GPIO pin setup that could cause the problem. I still don’t have my JTAG debugger working with Windows. It would be interesting to see if the problem comes up before the user constructor code is called.
@casm, do you actually mean while connecting, or rather till the Core is connected?
So, if you are in SYSTEM_MODE(MANUAL) or SYSTEM_MODE(SEMI_AUTOMATIC) the pin is actually high impedance and only goes LOW when calling Spark.connect() and stays LOW, till the code carries on running.
On the other hand, if you are in SYSTEM_MODE(AUTOMATIC), how could you distinguish while from till?
So it still would help to see your code.
In order to establish if this actually is a problem of the Core or just a side effect of something else (HW/SW), I'd like to know some more about @casm 's setup.
Till then, I think I'll set my inquiries on halt
I posted this in the “DIGITAL GPIO start-up glitch” post a while back but thought it worth a re-mention - when I flash from the cloud, pins D0, D1 and D2 go low for 7-9 seconds during the flash. If you add the fix suggested by @developer_bt in that post, pins D0-D7 will also go low but only for a few milliseconds. Otherwise they will go low for seconds. I posted a video of flashing a core without that fix to show both D0-D2 instance, and D0-D7 instance. Video (37 seconds) is here https://vimeo.com/125170411
So suggestion is to think not just about startup but when/if you have to flash to an installed and operating unit.
Hi All,
Sorry to be slow to respond and thank you for all the input. I am currently using digital pins and the one I am having an issue with is D5. The code is extremely simple for this pin, I set the pin to output and then set it to zero (in my setup code) I wish to use it as a fail safe, so when the core starts the relay is on until my code runs. I use automatic mode for the WIFI. On start up with my WIFI router turned off so I know the core cannot connect I wish the relay to be on but it does not stay on, the pin flashes on then off and then stays permanently off. I thought without connection my code will not run so the set up of the pin will not happen and it would remain tristate but it appears not. I attach a schematic below of this part for you to see.
I hope this makes sense and any more questions please ask.
