The 3V3 dc converter has very little load normally, produces all sorts of unstable spurs till you pull some current
from it (I've been running FFT testing a lot from smartpin ADC, this shows up the rail noise nicely if the pin is
floating). Try adding 50mA load to the 3V3 line and see if it cleans up the rail and makes it more stable to
sudden load change.
Mark,
Thank you for this. I've placed a 68 ohm resister across main capacitors, C707/C709 on output of the switcher circuit. I've got all the VIO jumpers back to the switcher and I/O clocking enabled as before. The picture is clean as.
That images is showing the whole sequence:
- DTR reset.
- Program download.
- Normal 100 MHz with one cog testing the I/O. I/O clocking is progressively engaged across 62 pins at the middle where the current rises slightly (maybe 20 mA) before dropping back to 20 MHz RCFAST.
- Reckless 100 MHz spike, then all 8 cogs running a tight loop of multiplies. I/O clocking still engaged.
EDIT: That progression on the I/O clocking takes place over 5.3 ms, so isn't as long as I thought. The small rise in current draw has short time because the time consuming debug output is mostly before this.
The 3V3 dc converter has very little load normally, produces all sorts of unstable spurs till you pull some current
from it (I've been running FFT testing a lot from smartpin ADC, this shows up the rail noise nicely if the pin is
floating). Try adding 50mA load to the 3V3 line and see if it cleans up the rail and makes it more stable to
sudden load change.
Mark,
Thank you for this. I've placed a 68 ohm resister across main capacitors, C707/C709 on output of the switcher circuit. I've got all the VIO jumpers back to the switcher and I/O clocking enabled as before. The picture is clean as.
Many SMPS chips give a choice of light-load operation.
You can run in forced PWM, which is less efficient at light loads, but is cleaner ( less ripple, higher frequency) as the switching is always (eg) 1MHz.
Or, you can run in a sparse pulse mode, that kicks the inductor on an energy required basis.
More efficient, but has rather higher ripple, and lower frequency and variable components due to the sparse kicks.
hmm... The AOZ1284 info says "Under steady-state conditions, the converter operates in fixed frequency and Continuous-Conduction Mode (CCM)." which I thought meant fixed MHz ?
@evanh
Great detective work. I am using USB power on my P2-EVAL board.
The switcher results are truly interesting.
Looks like
* a switcher down to say 3.8-4.0V and then LDO(s) to 3V3 and
* a switcher down to say ~2V2 and then LDO(s) to 1V8
would be the best mix for a high powered P2.
Going to hope the respin P2 gets the power down significantly for most apps which will not push the P2 to its limits.
Now I think about it, it was probably just a light duty mode for the regulator. Those pulses didn't show up that way at 350 MHz where the pins need a bit more juice. Like you say JMG, we were likely just seeing a slow top-up pulse. Probably nothing to worry about.
EDIT: And 20 mA for clocked I/O at 100 MHz is on the mark from earlier measurements too. So, if anything did change with the stairs then it must have been the pulsing showing up there as well.
EDIT2: I won't be removing that 68R resistor though. It's nicer not having to see those pulses.
@evanh
Looks like
* a switcher down to say 3.8-4.0V and then LDO(s) to 3V3 and
* a switcher down to say ~2V2 and then LDO(s) to 1V8
would be the best mix for a high powered P2.
The 1v8 is more tolerant of supply noise than the 3v3 rail, so it's less important to have the LDO there.
3v3 rails vary a lot in their use, so a mix of LDO and SMPS may be needed, depending on application ?
All good at 9000 cycles and counting ... A little surprised because I'm sure it did lock-up at least once since the resistor went in. Sadly I didn't have the scope armed at the time.
Whether it's 100% or not, I have to admit it appears more stable than before.
EDIT: Doing some speculating ... If this is the cause of the USB lock-ups then somehow the VIO switching regulator is stressing the FTDI chip causing it to fault out and create a bus wide shutdown on the USB side I guess.
Only vaguely direct path is via Prop2 pins#62/63. I did feel I'd noted a correlation with a change I'd made to #62 at one stage. Any other path would have to go via the Common 5 Volt rail.
EDIT: Doing some speculating ... If this is the cause of the USB lock-ups then somehow the VIO switching regulator is stressing the FTDI chip causing it to fault out and create a bus wide shutdown on the USB side I guess.
Only vaguely direct path is via Prop2 pins#62/63. I did feel I'd noted a correlation with a change I'd made to #62 at one stage. Any other path would have to go via the Common 5 Volt rail.
That seems a stretch... but if it has improved, there must be some mechanism ?
I guess there could be a ground loop at play here, is the 5V supply isolated and low noise ?
Do you have a LDO on the VCO/PLL pins ?
LDO's are all unconnected since putting the resistor in.
Benchtop supply is fully isolated. It has independent earth stud. Oscilloscope ground is earthed. USB ground is earthed via the desktop PC. All are powered from one mains circuit supplying this room. Only other powered devices in the room is network switch and ADSL modem/router.
Attached is a scope grab of the AOZ1284 at light loads.
It seems to give a kick of 3 full drive cycles, (here ~ 12KHz) then drops to a low-duty mode, then flips to what may be a special mode for BOOT cap charge?
Notice to the left of the 3 drive pulses, the ringing and drive is not quite the same, as the low-duty drives to the right of the 3 drive pulses.
That's a lot of ~10MHz ringing.
The spacing of those full inductor kicks, will vary to suit the level of light load.
Ah, there we go. Of course, it's totally pin#62. I'd forgotten I'd made a specific change to pin#62 a while back. Namely, turning off the async serial smartpin mode just before running the crazy PLL code.
I'm going to have to redo all the tests again. I get the feeling it's going to be much quicker results from now ...
PS: I've just completed 6000 cycles of the prior test but with the resistor disconnected. Again, no issues at all.
EDIT: And, having now removed the pin mode clearing code for pin#62, I've already had 3 port open failures in the first few minutes.
EDIT:2: In hindsight I can see I'd not completed the testing of pin#62 when I had first suspected it.
Ah, there we go. Of course, it's totally pin#62. I'd forgotten I'd made a specific change to pin#62 a while back. Namely, turning off the async serial smartpin mode just before running the crazy PLL code.
I'm going to have to redo all the tests again. I get the feeling it's going to be much quicker results from now ...
PS: I've just completed 6000 cycles of the prior test but with the resistor disconnected. Again, no issues at all.
EDIT: And, having now removed the pin mode clearing code for pin#62, I've already had 3 port open failures in the first few minutes.
Trying to follow that .. ?
Are you saying if you do not disable/re-enable the smart pin, that is somehow not reset correctly, and whatever it does during VCO lock, is enough to send the FTDI chip/driver out to lunch ?
I thought a reset cleared all the registers, smart pins included ?
At this stage all I'm saying is, somehow, just by having the Tx smartpin configured as Tx, it can upset the FTDI chip. I'm not sure what else, if anything, is contributing just yet.
At this stage all I'm saying is, somehow, just by having the Tx smartpin configured as Tx, it can upset the FTDI chip. I'm not sure what else, if anything, is contributing just yet.
I'll have to start over on all the combinations.
Could it be supplying power to the FTDI chip at times through its clamp diodes? Maybe keeping it from resetting properly?
Err, sorry, when I say lock-ups I mean a shutdown of all devices on that USB bus. It would be more accurate for me to say dead connection rather than lock-up.
Could it be supplying power to the FTDI chip at times through its clamp diodes? Maybe keeping it from resetting properly?
That's a known problem with the FTDI chips. Without a computer connected to the USB input, the Prop will parasitically power the FTDI chip when Tx goes high. That will cause a pulse on the DTR output, resetting the Prop, causing Tx to tri-state until the program starts again, ad infinitum. The solution is to buffer Tx and Rx against any backflow from the Prop. A less-desirable solution is to install pull-ups on Tx and Rx, so the FTDI chip is always parasitically powered, thus breaking the reset cycle.
However, I do not know if this behavior is contributing to the issue being reported here.
At this stage all I'm saying is, somehow, just by having the Tx smartpin configured as Tx, it can upset the FTDI chip.
..
It does look like the crazy PLL bashing is needed as well. I'm too tired to continue tonight.
Possible pathways ?
Could P2 emit some high baud rate ? I wonder if there is some phantom FTDI test mode path that is being triggered, where they use short pulses to enter it.
Usually safe, in 99% of applications, until a MCU hits it with something above the data-sheet MAX baud speed ?
Anything like that should be visible on a scope ?
Or, maybe it is related to the peak current the crazy PLL passes thru, as it seeks lock.
That could disturb either P2 smart pin or FTDI ?
I notice the RX line from FTDI to P2 is quite long, and has a series 3k9 inserted , and going the other way P2 -> FTDI also as a 3k9, both with long traces.
Maybe it's smarter to move the LEDs to lower port pins ? Those long traces are disturbing SD too... blinky leds are useful for early code testing, but hamper the higher speed pin-use.
Addit: If you instead configure Tx smartpin as CMOS out, that's electrically the same as Smart-pin, but without the buried logic behind it. That may split smart-pin / external to smart pin ?
Right, the USB 5 volts never goes away. It's one of the voltages I've been monitoring. EDIT2: Well, not until I power everything down to do the recovery.
As far as I can remember, when clearing pin#62 pin mode, I had it config'd as an output. I'll give it another try anyway with both high and low steady ...
This might be more important, since pin#62 will continue to be an output as long and the smartpin stays configured. EDIT: The code for the pin mode changes had all been added at about the same time, when I decided to use the LEDs on the EVAL board to tell me when a cog has started up.
Interesting, I had assumed the incmod did what it says, which is a maths based modulus,
Wiki says this about the math MOD operator
For example, the modulo of powers of 2 can alternatively be expressed as a bitwise AND operation:
x % 2n == x & (2n - 1)
Examples (assuming x is a positive integer):
x % 2 == x & 1
x % 4 == x & 3
x % 8 == x & 7
If the second parameter is included in the range, that's not MOD, so maybe this is better called INCWRAP or similar ?
Even that, is not quite exact, as the DOCs say this is the decision process
"Increment with modulus. If D = S then D = 0 and C = 1, else D = D + 1 and C = 0. *"
So it looks to be WRAPINC ? (Short for WRAP or INC) - ie the wrap test is done on the entry value, and if that fails to wrap, it increments.
11000 test cycles with pin#62 driven high - no port open errors, no lock-ups
3000 test cycles with pin#62 driven low - no port open errors, no lock-ups
What I've discovered though is that OUT and DIR registers of each cog are reset at COGINIT. Not so for a smartpin. A smartpin is only reset with the whole chip.
PS: Just got something now that I'm driving pin#62 from the later COGINIT'd programs ...
Confirmed. This is what I have so far:
- Following a bad PLL setting
- with pin#62 (Tx) driven, either high or low
- and Prop2 is DTR reset
- the subsequent program download has a small chance of failing to complete due to the USB bus shutting down every device on the bus at the end of that download.
EDIT: In addition, although a USB shutdown (lock-up) can occur without a preceding port open error, the intermittent singular port open errors always foretell an impending USB shutdown. They are clearly another symptom. And part of this symptom is it always has a bump in the PC-USB 5 volt trace.
Comments
Mark,
Thank you for this. I've placed a 68 ohm resister across main capacitors, C707/C709 on output of the switcher circuit. I've got all the VIO jumpers back to the switcher and I/O clocking enabled as before. The picture is clean as.
- DTR reset.
- Program download.
- Normal 100 MHz with one cog testing the I/O. I/O clocking is progressively engaged across 62 pins at the middle where the current rises slightly (maybe 20 mA) before dropping back to 20 MHz RCFAST.
- Reckless 100 MHz spike, then all 8 cogs running a tight loop of multiplies. I/O clocking still engaged.
EDIT: That progression on the I/O clocking takes place over 5.3 ms, so isn't as long as I thought. The small rise in current draw has short time because the time consuming debug output is mostly before this.
Many SMPS chips give a choice of light-load operation.
You can run in forced PWM, which is less efficient at light loads, but is cleaner ( less ripple, higher frequency) as the switching is always (eg) 1MHz.
Or, you can run in a sparse pulse mode, that kicks the inductor on an energy required basis.
More efficient, but has rather higher ripple, and lower frequency and variable components due to the sparse kicks.
hmm... The AOZ1284 info says "Under steady-state conditions, the converter operates in fixed frequency and Continuous-Conduction Mode (CCM)." which I thought meant fixed MHz ?
Great detective work. I am using USB power on my P2-EVAL board.
The switcher results are truly interesting.
Looks like
* a switcher down to say 3.8-4.0V and then LDO(s) to 3V3 and
* a switcher down to say ~2V2 and then LDO(s) to 1V8
would be the best mix for a high powered P2.
Going to hope the respin P2 gets the power down significantly for most apps which will not push the P2 to its limits.
EDIT: And 20 mA for clocked I/O at 100 MHz is on the mark from earlier measurements too. So, if anything did change with the stairs then it must have been the pulsing showing up there as well.
EDIT2: I won't be removing that 68R resistor though. It's nicer not having to see those pulses.
The peak variations may be worse on a clock-gated P2, which could give more crosstalk and PSU issues ...
The 1v8 is more tolerant of supply noise than the 3v3 rail, so it's less important to have the LDO there.
3v3 rails vary a lot in their use, so a mix of LDO and SMPS may be needed, depending on application ?
I first did a shorter run, ~4000 cycles, of unclocked I/O with crazy PLL start-up. This also produced no USB lock-ups.
Now starting a run of clocked I/O with crazy PLL start-up ...
Whether it's 100% or not, I have to admit it appears more stable than before.
EDIT: Doing some speculating ... If this is the cause of the USB lock-ups then somehow the VIO switching regulator is stressing the FTDI chip causing it to fault out and create a bus wide shutdown on the USB side I guess.
Only vaguely direct path is via Prop2 pins#62/63. I did feel I'd noted a correlation with a change I'd made to #62 at one stage. Any other path would have to go via the Common 5 Volt rail.
I guess there could be a ground loop at play here, is the 5V supply isolated and low noise ?
Do you have a LDO on the VCO/PLL pins ?
Benchtop supply is fully isolated. It has independent earth stud. Oscilloscope ground is earthed. USB ground is earthed via the desktop PC. All are powered from one mains circuit supplying this room. Only other powered devices in the room is network switch and ADSL modem/router.
It seems to give a kick of 3 full drive cycles, (here ~ 12KHz) then drops to a low-duty mode, then flips to what may be a special mode for BOOT cap charge?
Notice to the left of the 3 drive pulses, the ringing and drive is not quite the same, as the low-duty drives to the right of the 3 drive pulses.
That's a lot of ~10MHz ringing.
The spacing of those full inductor kicks, will vary to suit the level of light load.
I'm going to have to redo all the tests again. I get the feeling it's going to be much quicker results from now ...
PS: I've just completed 6000 cycles of the prior test but with the resistor disconnected. Again, no issues at all.
EDIT: And, having now removed the pin mode clearing code for pin#62, I've already had 3 port open failures in the first few minutes.
EDIT:2: In hindsight I can see I'd not completed the testing of pin#62 when I had first suspected it.
Trying to follow that .. ?
Are you saying if you do not disable/re-enable the smart pin, that is somehow not reset correctly, and whatever it does during VCO lock, is enough to send the FTDI chip/driver out to lunch ?
I thought a reset cleared all the registers, smart pins included ?
I'll have to start over on all the combinations.
Could it be supplying power to the FTDI chip at times through its clamp diodes? Maybe keeping it from resetting properly?
However, I do not know if this behavior is contributing to the issue being reported here.
-Phil
Possible pathways ?
Could P2 emit some high baud rate ? I wonder if there is some phantom FTDI test mode path that is being triggered, where they use short pulses to enter it.
Usually safe, in 99% of applications, until a MCU hits it with something above the data-sheet MAX baud speed ?
Anything like that should be visible on a scope ?
Or, maybe it is related to the peak current the crazy PLL passes thru, as it seeks lock.
That could disturb either P2 smart pin or FTDI ?
I notice the RX line from FTDI to P2 is quite long, and has a series 3k9 inserted , and going the other way P2 -> FTDI also as a 3k9, both with long traces.
Maybe it's smarter to move the LEDs to lower port pins ? Those long traces are disturbing SD too... blinky leds are useful for early code testing, but hamper the higher speed pin-use.
Addit: If you instead configure Tx smartpin as CMOS out, that's electrically the same as Smart-pin, but without the buried logic behind it. That may split smart-pin / external to smart pin ?
As far as I can remember, when clearing pin#62 pin mode, I had it config'd as an output. I'll give it another try anyway with both high and low steady ...
EDIT: Yep, here's the now commented lines
This might be more important, since pin#62 will continue to be an output as long and the smartpin stays configured. EDIT: The code for the pin mode changes had all been added at about the same time, when I decided to use the LEDs on the EVAL board to tell me when a cog has started up.
I've now changed this to and uncommented the earlier WRPIN/DRVH.
Interesting, I had assumed the incmod did what it says, which is a maths based modulus,
Wiki says this about the math MOD operator
If the second parameter is included in the range, that's not MOD, so maybe this is better called INCWRAP or similar ?
Even that, is not quite exact, as the DOCs say this is the decision process
"Increment with modulus. If D = S then D = 0 and C = 1, else D = D + 1 and C = 0. *"
So it looks to be WRAPINC ? (Short for WRAP or INC) - ie the wrap test is done on the entry value, and if that fails to wrap, it increments.
so a incmod x, 3 does
0-1-2-3-0-1-2-3
I was assuming 0-1-2-0-1-2
RTFM, Mike
Mike
Yes, I think many will not expect that, as that is NOT what the MOD operator does, so it really does need a rename, to avoid that natural confusion.
3000 test cycles with pin#62 driven low - no port open errors, no lock-ups
What I've discovered though is that OUT and DIR registers of each cog are reset at COGINIT. Not so for a smartpin. A smartpin is only reset with the whole chip.
PS: Just got something now that I'm driving pin#62 from the later COGINIT'd programs ...
- Following a bad PLL setting
- with pin#62 (Tx) driven, either high or low
- and Prop2 is DTR reset
- the subsequent program download has a small chance of failing to complete due to the USB bus shutting down every device on the bus at the end of that download.
EDIT: In addition, although a USB shutdown (lock-up) can occur without a preceding port open error, the intermittent singular port open errors always foretell an impending USB shutdown. They are clearly another symptom. And part of this symptom is it always has a bump in the PC-USB 5 volt trace.