strange power-on behavior (booting from flash ) (solved)
Rayman
Posts: 14,641
Flashed this simple code that toggles LEDs on P56 and P57
PUB main()
repeat
pinl(56)
pinh(57)
waitms(100)
pinh(56)
pinl(57)
waitms(100)
It does exactly what you think when run while powered.
But, when power is removed and then applied the toggling code from flash seems to get stuck a few times for a few hundred ms or so...
It's like the clock is off or something...
Maybe has something to do with being in RC fast mode with no clkfreq defined...
Anybody know what's going on?
Update: Solved. @JRoark figured out it is actually the PC resetting the P2 several times when first connected.
Comments
Actually, it does this with _clkfreq = 297_000_000 too...
Hi Rayman
Did you checked/noticed any strange behaviour/waveform at V2831?
Sometimes, small cracks at ceramic decoupling caps are really hard to spot.
This happens with both a P2 eval board and a board of my own.
So unlikely a power problem
And both experiments where conducted at differing powering conditions; IOW, not the same PC USB, or adapter, as to rule out any interference coming from the "outer world"?
Any significant noise, coupled from any other connection, can be cause of that kind of behaviour.
The power-up levels for those LEDs is always erratic. The pins are floating so the logic driver IC for the LEDs changes state multiples times for a couple of seconds. Your freshly booted program takes over even before they're settled.
@evanh Ok, sounds like you're not surprised. But, my board does not have a logic driver, it's just P2 pins to resistors and LEDs.
Also, I think the pinh and pinl Spin2 commands are supposed to set both DIRB and OUTB.
Something looks wrong here to me, but have no idea what's causing it...
@Yanomani Actually, a power supply issue might be what's going on here... The blue LEDs are probably very sensitive to the 3.3 V level and won't work if power drops below some value like 3.0 V.
There must be some surge a second or so after power on that dips the 3.3 V level...
Rayman: you seem to have hit on something I’ve been looking at too, and in my case it seems to be related to how the SD card gets initialiazed.
I bet if you change the pin numbers to anything not in the 63:56 range, it works just fine.
Phew! Thanks a lot for the update, Rayman!
So, now, I'm suposing that the anodes of the leds are connected to P2 pins thru low-value series resistors, and their cathodes are routed towards GND (the position of the resistors doesn't really matter, provided their value is low, due needing to be so, as to be able to be used with the blue leds) .
If the above is true, perhaps just by inverting the setup could be enough to fix it, thoug now, you'll be faced with some extra concerns:
P.S. as about inverting the setup, I meant connecting the led anodes towards Vio, and their cathodes to P2 pins. Again, the position of the series resistors don't matter.
If you use the same Vio that feds the pins, whose will be driving the cathodes (in a multi-regulator setup, each one of them driving one, or a small group of Vio pins), the value of each series resistor can be lowered to a minimum, only enough to ensure the maximum allowable current of each regulator, AND also the pins, will not be surpassed;
This works because the internal NMos drivers are a lot likely to get satisfyed by the internal pre-drivers, so their outputs will be able to drive the pins nearest GND potential, than the PMos-ones would be able to drive them towards Vio;
If you use another 3.3 V source, or a "general" 3.3V -source (in a single regulator setup, feeding all Vios, or even a wider group of (perhaps four, like a source-per-side setup)), extra care should be considered, since any spikes, induced by the heavier current switching, can be coupled to P2 thru the pins themselves, messing with otherwise protected circuits, and be cause of any other riot-events.
Sure, either way, GND-bounce will be ever a concern that can be even agraveted by any eventual poor routing.
Henrique
Good point, JRoark, and it also provides some extra clues, that can add to what I'd explainned at post #9 #10.
Thanks for posting it!
Henrique
Broke out the scope and it's not a power supply issue.
In fact, instead of power drooping at times, there's about 6 times during the first 5 seconds where the 5V supply actually increases a bit for ~100 ms each time.
Looks like maybe P2 clock is actually stopping, resulting in a decrease in power draw... Not sure though...
It's nothing to do with the pins either. I flashed with code that does nothing, just a repeat and it does the same thing...
Here's the 5V signals from Eval board and my board. It's much more noticeable on my board...
What about pins not in that 56-63 range?
@JRoark It does the same thing with no pins doing anything...
Here's that simple test code that demonstrates the behavior...
Just fire up with Eval board...
Just as a confirmation: IMG_1795.JPG is the one produced when using the eval board?
I’m away from home at the moment, (and the blasted iphone wont open the Spin2 code snippet) but I wanted to clarify my original question: does this bootup behavior occur on all pins, or just those in pin group 56-63?
@Yanomani Yes, that's right
@JRoark don't have leds on any other pins... But, it's the 5V supply I'm looking at in the above scope pics...
@Rayman Wowzers. It behaves exactly the same on my bench too!
As an experiment I rewrote your code in FlexBASIC and ran it, thinking maybe there was some mischief with the spin interpreter or something else. Nope. My code behaves exactly the same. I'll get a capture on the LA and post it in a minute, but all of this wierdness happens before the board starts executing user code. only after a pin gets set to be an output! It doesn't seem to matter where in the pin-space you look, if you set a pin to be an output, it does this dance for the first 4 seconds.
For clarity: The ONLY time this happens is when code has been flashed, power has been cycled, and at power-up the board boots from flash. It does NOT happen when code is downloaded to HUB and a DTR-reset is done, nor does it happen if you download to flash and do a DTR-reset.
Trace:
The program execution starts 3.98 secs after the 3.3v rail goes high. Everything in that red box is the P2 doing... something... outside of my/Rayman's code. Program execution starts immediately. But the P2 is doing the "Rayman Dance" during those first 4 seconds.
Any ideas?
My test code:
CONST PINA=56 CONST PINB=57 CONST PGMSTART = 48 print "Running" pinhi(PGMSTART) do pinlo(PINA) pinhi(PINB) pausems(100) pinhi(PINA) pinlo(PINB) pausems(100) loopADDIT: Changing to code to 20mS delays instead of 100mS delays tells an interesting story. Six times (always six) there seems to be a bus contention problem, (or the cog gets disconnected, or something), for 160 mS. Then there is a 500 mS delay of good pulses, followed by another 160 mS of contention.
ADDIT2: Changing the clock frequency has no effect on this. I expected doubling the clock speed to reduce the window of contention from 4 seconds to 2 seconds. Nope. Even at 80 mhz that window stays the same width.
@rayman I think I figured it out. This seems to be some sort of interaction with the PC. If you power the board from a battery pack and have it completely disconnected from the PC, it works fine.
This is now officially above my pay grade. LOL.
@JRoark You're right! I see that too now... Must be the PC somehow resetting the P2 a few times when first connected....
Thanks for figuring this out! Had me baffled...
Had me baffled too, and the reason I went hunting it was because it was shades and phases of this other oddball bug I was seeing in the Flex SD/MMC file system. I'm still hunting that one, but it looks like its basically the same bug. File system mounts fine if you compile/download to either HUB or flash as long as you keep the power on. But booting from flash it gets wonky. Unlike this bug however, the filesys bug rears its head without power-cycling. Hitting the reset button causes it too.
So, its happening even when not booting the EEPROM, just the power up alone does it, right? Opps, didn't read enough.
Ah, the dip in voltage happens when any program draws more power than the idle RCFAST. So that explains why voltage changes. Doesn't explain why there is multiple bumps though.
I sort of ran out of time on this today (She Who Must Be Obeyed had a list of honey-do’s… ahem), but tomorrow I’ll put the LA on the USB chip and see what is going on there. Also, I just realized I was using a Rev B EVAL board to test this, but should probably use the Rev C so I can better isolate the DTR reset line.
Hehe, doesn't happen with Linux. Here's a screenshot of scope on 5V_Common of RevB Eval Board when powering up and booting straight to EEPROM with the above program compiled with Flexspin.
PS: And second screenshot powering up with the Flash switch turned off.
Bet it'll be Windoze probing for a serial mouse. DTR was the power pin for those.
If that is the case, the ps2 probe feature can be disabled through device manager / com port options. Along with another typically unhelpful com setting that is s blur to remember just now
Ok, device manager settings does fix this...
Need to check "disable modem ctrl at startup" and uncheck "serial enumerator".
This behavior is described here: http://www.ftdichip.com/Documents/AppNotes/AN_107_AdvancedDriverOptions_AN_000073.pdf
Ha! I’ll be darned. Works! Sweet!
This needs to be part of the docs.