Yeah it's really nice powering from a separate wall wart transformer because RS232 doesn't supply power.
There's pros and cons on this one. Heavy wiring in the data cable would be problematic. 5 volts could be seen as poor choice. Flexibility and reliability are sacrificed.
Yeah it's great having to put charge pumps in to swing the voltage and also receive a swing as high as ±15 V.
You may have noticed the transition to switchmodes these days. They are way more complicated than any charge pumps.
It's great how flow control is a crapshoot, and probably is ignored by the master sending the data anyway.
Hardware flow control wasn't of much use in practise. Some ancient equipment did use it though. Really, if there needs to be flow control of any sort then it should be in the data stream via a chosen protocol. Even RS485 needs software(driver) allowances for turnaround.
Dial everything down to 9600 baud because "at least that works". So the download takes longer than a laptop battery can last?
Limited by the equipment. If the manufacturer only wants that speed then so be it. Older stuff is slower, nothing new there. That's just showing the flexibility. We're running the Prop2 up to 2 Mbps.
Requiring gender benders and crossover adapters and crossover cables?
USB has it's own mix and match issues. How many different Type-A's and Type-B's are there? I'd never even seen a uUSB plug before the EVAL board landed in my lap.
Of course, comparing USB to a UART isn't really apples with apples. USB is closer to being a computer expansion bus than any comms/network link.
UARTs are far more primitive, they have no protocol. USB has large protocol burden.
At that point, the PC has suspended the USB port. That is the only reason the PWR LED can go off like this.
I wondered if the issue is simply due to code that has P2 pulling over-current from the PC USB port; perhaps spikes that are faster than the USB circuit can protect against, or just some heavy load that forces too much voltage drop. But then you mentioned the board was powered by AUX at the same time, so the above won't make sense- as no power would be sourced from PC-USB whilst AUX is active.
I'll get the scope out today and keep a close eye on the supply rails.
Still- the PC is sure suspending the port for some reason. Maybe you've found a weakness with all those test-repetitions.
You may be able to disable/re-enable the HUB in device manager, rather than needing to power-cycle the PC.
I later found that the USB extension system I'm using may have some smarts in it. Just by replugging it in the same PC socket turned out to be enough (this time). I didn't have to move to another controller on the PC.
evanh:
Do you have a data-only cable or could you DIY one and run that same kind of test?
VonSzarvas, would that be okay to only power the P2 Eval board from the P2 USB (aux) plug, and only have a data connection (snip the +5V, leave Data+ Data- and GND) on the PC USB plug?
USB still sucks compared to the old reliable serial.
Getting nostalgic looking through rose-tinted glasses?
Yeah it's really nice powering from a separate wall wart transformer because RS232 doesn't supply power.
Yeah it's great having to put charge pumps in to swing the voltage and also receive a swing as high as ±15 V.
It's great how flow control is a crapshoot, and probably is ignored by the master sending the data anyway.
Dial everything down to 9600 baud because "at least that works". So the download takes longer than a laptop battery can last?
Requiring gender benders and crossover adapters and crossover cables?
Well, it's like this...
P2 runs serial at 2MB and 3V3 without charge pumps. Serial has evolved, and would have without USB taking over.
Unfortunately, one way or another, USB has problems of reliability. Personally, I don't know if it is the protocol or drivers or both. But I don't care - it just isn't as reliable as it should be. At least async was/is reliable!
At that point, the PC has suspended the USB port. That is the only reason the PWR LED can go off like this.
I wondered if the issue is simply due to code that has P2 pulling over-current from the PC USB port; perhaps spikes that are faster than the USB circuit can protect against, or just some heavy load that forces too much voltage drop. But then you mentioned the board was powered by AUX at the same time, so the above won't make sense- as no power would be sourced from PC-USB whilst AUX is active.
I'll get the scope out today and keep a close eye on the supply rails.
Nothing odd happens with the power rails. I was even watching the scope when this one happened. Four probes on 1v8 VDD supply, 3v3 VIO supply, 5v AUX supply, and 5v PC-USB supply. Trigger was set for low going edge at 4.2 volts on PC-USB supply soldered at the fuse. No trigger occurred.
USB 5 volts is still present even though, presumably, the PC has told all devices on that bus to shut down.
Nothing odd happens with the power rails. I was even watching the scope when this one happened. Four probes on 1v8 VDD supply, 3v3 VIO supply, 5v AUX supply, and 5v PC-USB supply. Trigger was set for low going edge at 4.2 volts on PC-USB supply soldered at the fuse. No trigger occurred.
USB 5 volts is still present even though, presumably, the PC has told all devices on that bus to shut down.
Maybe the current sense is not voltage-droop based, but more a genuine current reading, that only impacts millivolts (4.2V may be too low) ?
What actual current do you see while this is cycling, and how much do the peaks vary ?
Does the BIOS/OS signal in any way, when a decision is made to suspend a connected device ?
evanh:
Do you have a data-only cable or could you DIY one and run that same kind of test?
VonSzarvas, would that be okay to only power the P2 Eval board from the P2 USB (aux) plug, and only have a data connection (snip the +5V, leave Data+ Data- and GND) on the PC USB plug?
USB still sucks compared to the old reliable serial.
Getting nostalgic looking through rose-tinted glasses?
Yeah it's really nice powering from a separate wall wart transformer because RS232 doesn't supply power.
Yeah it's great having to put charge pumps in to swing the voltage and also receive a swing as high as ±15 V.
It's great how flow control is a crapshoot, and probably is ignored by the master sending the data anyway.
Dial everything down to 9600 baud because "at least that works". So the download takes longer than a laptop battery can last?
Requiring gender benders and crossover adapters and crossover cables?
Well, it's like this...
P2 runs serial at 2MB and 3V3 without charge pumps. Serial has evolved, and would have without USB taking over.
Unfortunately, one way or another, USB has problems of reliability. Personally, I don't know if it is the protocol or drivers or both. But I don't care - it just isn't as reliable as it should be. At least async was/is reliable!
I guess my experience was different. USB was a great step forward.
I still have to keep over 40 different RS232 serial adapter cables for the PC com port.
Laplink, activesync, MicroLogix, PPI, null modem, some 15-pin nonsense, hilarious 25-pin serial, 3-pin 8mm round something... the list goes on and on.
Compare that to a (Type A to 5 pin mini-b) and a (Type A to micro-b) cable. All that I need.
We'll just have to agree to disagree. Having lived it, the RS232 world sucked and I would never wish it upon anyone. USB is great.
PC Serial went through its own phase of incompatible/unreliable nonsense. Remember having to specifically spec 16550 Uarts? I do.
On another line of thought, does the SD boot ROM use the smart pins and events/interrupts? Is there a possibility that an event survives the reset and causes the lockup? I would assume all smart pin and event settings/flags are also cleared on reset, but it my be worth reviewing?
Okay here's some screen shots showing current draw from the benchtop supply to 5 volt AUX. I used a clamp probe with 0.5 V/A sensitivity.
- Green trace is AUX 5V current, 200 mA/div. 0 mA is one division above bottom.
- Blue trace is AUX 5V voltage at the supply header pins, 200 mV/div. 5 V is two divisions below top.
- Pink trace is PC-USB 5V voltage at the fuse, 200 mV/div. 5 V is two divisions below top.
- Orange is logic pin #58. 2 V/div. 0 V is bottom.
First image is of few normal runs then a singular port-open-failure. I think the 100 mV surge on PC-USB is unusual case even for a port-open-fail.
Second image shows the voltage surge zoomed in. You can see it roughly coincides with the start of the 10 ms wait between HUBSETs. Ie: When PLL gets initialised. The low region leading up to that will be the program download over USB.
Third image is, like the first, shows four apparently normal runs ... then just dead. The PC-USB LED has gone out.
Fourth image, I've stitched two screen shots together, is zoomed in on the very end piece where it has reset and appears to begin downloading but sort of trails off at that point.
Fifth image is same scale as fourth but for a normal boot sequence showing the three resets at the beginning and a successful download and engaging of the PLL. (at 350 MHz)
I find the complaint that USB is unstable interesting. I have a Prop1 powered by USB that communicates via a FTDI FT245. After tweaking all of Window's power settings to not sleep the USB buss or any other related systems, I can run my dongle for months at a time. I use it to send DMX to my prop powered light controllers with a C# program. It is solid. Maybe I am lucky. I dunno. Those USB and other power setting can be hard to find and track down.
How far away is the dongle from the computer? The term dongle often means no cable at all. USB cable length makes a big difference. Another factor is any nearby devices that are electrically noisy. Or just static discharges when working around the equipment.
Once the data is on the 485 cable it's a much more robust environment - partly because glitches there are not going to automatically kill the link. And even more robust if electrically isolated.
The USB-A to B cable is about 3ft. It does have a ferrite core at the B connector. I also have a ferrite bead "jumper" on the power lead that feeds the FT245. It is not in a RF noisy environment. It is in a residential environment sitting next to a 25mw VHF (106.5Mhz) transmitter. Occasionally a 5W VHF or UHF handheld transmitter is used in the near field. The power is clean, no heavy machinery or anything like that.
I can see how USB could be problematic in an industrial setting. I didn't think of that.
Okay here's some screen shots showing current draw from the benchtop supply to 5 volt AUX. I used a clamp probe with 0.5 V/A sensitivity.
- Green trace is AUX 5V current, 200 mA/div. 0 mA is one division above bottom.
- Blue trace is AUX 5V voltage at the supply header pins, 200 mV/div. 5 V is two divisions below top.
- Pink trace is PC-USB 5V voltage at the fuse, 200 mV/div. 5 V is two divisions below top.
- Orange is logic pin #58. 2 V/div. 0 V is bottom.
First image is of few normal runs then a singular port-open-failure. I think the 100 mV surge on PC-USB is unusual case even for a port-open-fail.
Second image shows the voltage surge zoomed in. You can see it roughly coincides with the start of the 10 ms wait between HUBSETs. Ie: When PLL gets initialised. The low region leading up to that will be the program download over USB.
Third image is, like the first, shows four apparently normal runs ... then just dead. The PC-USB LED has gone out.
Fourth image, I've stitched two screen shots together, is zoomed in on the very end piece where it has reset and appears to begin downloading but sort of trails off at that point.
Fifth image is same scale as fourth but for a normal boot sequence showing the three resets at the beginning and a successful download and engaging of the PLL. (at 350 MHz)
Are the resets those short drops to minimum green current, I think the internal reset-exit timer runs, but nothing else.
What is changing for the Pink USB voltage drop, lasts ~ 30ms ? is that the code download window ?
The +100mV step on USB seems to be a PC-Side decision, & some state change in the USB controller, but you say that is rare ?
Whenever it does freeze, does the P2 reset still work ok ? - I think pushing the RST button would give those RST-Idd signatures ? If the code is not corrupted, it would also then run ?
On trace 1 following the strange pink USB PC-Side pulse, (5ms after send completes, and during the 10ms P2 wait ?), after that time it seems to start a test sequence, but seems to not complete it, if I follow the green Icc right.
= other tests have a longer time at 350MHz ? - why did that one stop early - did the USB port generate a RST pulse ? The Green trace seem to go-min, and stay-min ?
Is there a RXD level test in the boot tree, ie suppose an errant RST arrives during serial send, as P2 boot-inspects pins, it may find RXD low ?
Fourth image, I've stitched two screen shots together, is zoomed in on the very end piece where it has reset and appears to begin downloading but sort of trails off at that point.
Looks like download completed, but P2 stays at 20MHz ? Would maybe a corrupted download do that ?
I find the complaint that USB is unstable interesting. I have a Prop1 powered by USB that communicates via a FTDI FT245. After tweaking all of Window's power settings to not sleep the USB buss or any other related systems, I can run my dongle for months at a time. I use it to send DMX to my prop powered light controllers with a C# program. It is solid. Maybe I am lucky. I dunno. Those USB and other power setting can be hard to find and track down.
--Terry
I've never heard of such issues on Linux or Mac, I think it could be Windows specific. What I do see a lot of is USB A connectors wearing out or filling with crud/dirt so they become unreliable. Careful restoring of contact springiness with
a jeweler's screw-driver can be useful. Hesistant plugging or unplugging of usb connectors is obviously best avoided.
Another problem I've seen is using cheapo USB1 leads for USB2 and higher. USB2 leads need to be of a certain minimum
quality just like network cables, they run at higher speeds than CAT5/CAT6 is rated for in fact...
I've encountered some driver-related issues for particular USB devices/OSs, but those are usually cause kernel panics and
are buggy 3rd-party drivers.
Are the resets those short drops to minimum green current, I think the internal reset-exit timer runs, but nothing else.
Yes, although I haven't actually compared the DTR/reset signal. I'm using loadp2 so it won't be identical to Pnut sequence.
What is changing for the Pink USB voltage drop, lasts ~ 30ms ? is that the code download window ?
The +100mV step on USB seems to be a PC-Side decision, & some state change in the USB controller, but you say that is rare ?
Yes, that fits the expected sequence. Program runs immediately after download is complete. But same story as above, I haven't compared with actual data transfer.
Whenever it does freeze, does the P2 reset still work ok ? - I think pushing the RST button would give those RST-Idd signatures ? If the code is not corrupted, it would also then run ?
Reset always reverts to ROM code. It'll go back to waiting for boot up steps.
On trace 1 following the strange pink USB PC-Side pulse, (5ms after send completes, and during the 10ms P2 wait ?), after that time it seems to start a test sequence, but seems to not complete it, if I follow the green Icc right.
= other tests have a longer time at 350MHz ? - why did that one stop early - did the USB port generate a RST pulse ? The Green trace seem to go-min, and stay-min ?
That's the nature of my randomiser. You'll see the three steps of I/O testing with terminal output, but after that it does the HUBSET trickery, with an initial 100ms pause for winding down the PLL, and also fills the cog with random data and jumps to #0. The result varies quite a lot. Sometimes the current draw goes up even higher.
Fourth image, I've stitched two screen shots together, is zoomed in on the very end piece where it has reset and appears to begin downloading but sort of trails off at that point.
Looks like download completed, but P2 stays at 20MHz ? Would maybe a corrupted download do that ?
Even if that did happen the next test cycle would bring it back to life - Which didn't happen. Corrupted program on the Prop2 certainly shouldn't cause a shutdown of every device on that USB bus! Which is what is happening there.
Hey Chip,
There is a clear ramp-to-max of the VCO during PLL initialisation. I have no idea how expected this is. I'm stating this based on observed power draw when engaging the PLL before it has obtained lock.
Here's what happens when setting 100 MHz with PLL engaged all the way: (Same scales as before)
Here's a USB lockup using the above code. Everything is nice and regular, including the excessive power spike, until it stops. The point of no activity is again at the end of the download after a reset.
Second image is a normal download and correct 100 MHz PLL engage at the start of the program.
There is a clear ramp-to-max of the VCO during PLL initialisation. I have no idea how expected this is. I'm stating this based on observed power draw when engaging the PLL before it has obtained lock.
That's fairly expected, as the VCO is analog, and has to seek to find lock.
It's why I made sure Chip had the PLL counters capable of dividing up to the maximum expected VCO MHz. You need to be able to follow any VCO swings it may have.
If you enable PLL before lock is complete, the whole clock tree will be hit with a peak-VCO-MHz, hence the large current spike.
You also hope that the whole P2 core, can respond at that peak MHz.
That peak-VCO might not be the highest possible VCO, just where it swings to during lock-phase.
You could ask for 350MHz to check the 'indicated Mhz' of that peak - from the 100MHz lock base there, looks just over 400MHz ?
Does HUBSET have any inbuilt delays ? - you could drop a pin before the hubset command ? - there seems a slight Icc drop, 600us before the VCO swing ?
Here's what happens when setting 100 MHz with PLL engaged all the way: (Same scales as before)
Here's the source code for that:
hubset #0
waitx ##20_000_000/10 '~100ms
hubset ##_ENAFREQ 'setup and enable oscillator together (expected lock-up)
So you have a single 'instant' enable of both Xtal and PLL-VCO, no delay here ?
That is a quite brutal test, (but good stress test) and I'm surprised you seem to have no failures at the PLL init stage (failures seem to be post-download ?)
Quite impressive really...
If you want 100MHz, enable with a PostDIv of 2 or even 3, should lower the sysclk peak, before locking with a higher MHz VCO.
On my P2, even Enable of Xtal alone, and too-soon switch to SysCLK, would lock up P2, on a regular basis.
That was a little surprising, as I expected an auto-pause effect to simply wait until the Xtal amplitude was enough - but with no schmitt stage, seems there will be spiky/noisy clocks until the Xtal starts.
Can't recall if I tried immediate jump to VCO-out, but that would shift any Xtal-Noise effects to be a PFD problem, not a clock-tree problem.
Maybe that's how this test works ok ?
Here's a USB lockup using the above code. Everything is nice and regular, including the excessive power spike, until it stops. The point of no activity is again at the end of the download after a reset.
Second image is a normal download and correct 100 MHz PLL engage at the start of the program.
Third image is the failed download and no run.
Can you predict a failure, from that subtle difference in pink-trace voltage profile ?
When it works, the trace suggests higher current during download, then a move to a lower, cleaner idle current.
When it fails, it looks to not lower as much, and has a different ripple pattern. (but ~1.4x faster than a 1ms repeat rate you might expect on a USB device ?)
So you have a single 'instant' enable of both Xtal and PLL-VCO, no delay here ?
That is a quite brutal test, (but good stress test) and I'm surprised you seem to have no failures at the PLL init stage (failures seem to be post-download ?)
Quite impressive really...
You noticed. Cluso had some ideas of possible contributing reasons so I threw them all together to to try and get quick failures. It's looking like none of them mattered ...
I'm just back up and running again after destroying the AUX-USB switch, U501. Desoldered it and jumpered the power rails. I'm temped to also remove the PC-USB switch since the 5v-Common is now the disable for it. Not to mention the EVAL board never was suited to being powered from USB.
Does HUBSET have any inbuilt delays ? - you could drop a pin before the hubset command ? - there seems a slight Icc drop, 600us before the VCO swing ?
That would appear to be the case. Presumably the sysclock will be very slow at that point.
Thanks.
Yes, looks like the flip to VCO out, first has to wait for the Xtal to start, hence the 600us before the VCO has a PFD clock to lock to.
Then, it locks quite quickly.
There are impulses in current every 500us, is that a repeat in your code ? FWIR COG's did have a mA/MHz value, but rather less than the global clock tree, which dominates.
Reminds me.. I wonder how OnSemi are going, with the P&R and timing closures and the clock gating in P2+ ?
Yeah, no, I'd ignored those pulses. They didn't fit any timing. The cogs at that point are cycling at under one microsecond.
COGSTOPing all eight cogs offests the average level down but does nothing for the size or frequecy of the peaks.
Turns out it is all due to clocked I/O. I had 62 pins with clocking enabled. Turn that off and those pulses go away. I'm guessing those pulses are not something Chip had intended.
PS: That's the current reading of the 5 volt supply. So that has come via the 3v3 switchmode regulator, presumably.
Huh, changing the VIO jumpers over to the LDO regulators has made not only those pulses disappear but also the excess power draw from clocked I/O also go away. The staircase has almost completely disappeared.
So there is some conflict with the 3v3 switcher going on ... one wonders if that has been doing other bad things too ...
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.
Yeah, no, I'd ignored those pulses. They didn't fit any timing. The cogs at that point are cycling at under one microsecond.
COGSTOPing all eight cogs offests the average level down but does nothing for the size or frequecy of the peaks.
Turns out it is all due to clocked I/O. I had 62 pins with clocking enabled. Turn that off and those pulses go away. I'm guessing those pulses are not something Chip had intended.
PS: That's the current reading of the 5 volt supply. So that has come via the 3v3 switchmode regulator, presumably.
but what about IO clocking can have a ~500us spike component ? SMPS is closer to 1MHz,
Huh, changing the VIO jumpers over to the LDO regulators has made not only those pulses disappear but also the excess power draw from clocked I/O also go away.
I have noticed the LDOs oscillate quietly away when not-jumpered (due to no CL) , so maybe they can partly explain the pulses, (LDOs feed from 5V)
- but how do they know you have IO clocking enabled ? that bit does not fit ?
IO Clocking should be a SysCLK domain loading, surely ? The levels shifters should have reasonable PSRR ?
Comments
You may have noticed the transition to switchmodes these days. They are way more complicated than any charge pumps.
Hardware flow control wasn't of much use in practise. Some ancient equipment did use it though. Really, if there needs to be flow control of any sort then it should be in the data stream via a chosen protocol. Even RS485 needs software(driver) allowances for turnaround.
Limited by the equipment. If the manufacturer only wants that speed then so be it. Older stuff is slower, nothing new there. That's just showing the flexibility. We're running the Prop2 up to 2 Mbps.
USB has it's own mix and match issues. How many different Type-A's and Type-B's are there? I'd never even seen a uUSB plug before the EVAL board landed in my lap.
Of course, comparing USB to a UART isn't really apples with apples. USB is closer to being a computer expansion bus than any comms/network link.
UARTs are far more primitive, they have no protocol. USB has large protocol burden.
I later found that the USB extension system I'm using may have some smarts in it. Just by replugging it in the same PC socket turned out to be enough (this time). I didn't have to move to another controller on the PC.
Well, it's like this...
P2 runs serial at 2MB and 3V3 without charge pumps. Serial has evolved, and would have without USB taking over.
Unfortunately, one way or another, USB has problems of reliability. Personally, I don't know if it is the protocol or drivers or both. But I don't care - it just isn't as reliable as it should be. At least async was/is reliable!
USB 5 volts is still present even though, presumably, the PC has told all devices on that bus to shut down.
Or Usable Sometimes Bus ?
What actual current do you see while this is cycling, and how much do the peaks vary ?
Does the BIOS/OS signal in any way, when a decision is made to suspend a connected device ?
I guess my experience was different. USB was a great step forward.
I still have to keep over 40 different RS232 serial adapter cables for the PC com port.
Laplink, activesync, MicroLogix, PPI, null modem, some 15-pin nonsense, hilarious 25-pin serial, 3-pin 8mm round something... the list goes on and on.
Compare that to a (Type A to 5 pin mini-b) and a (Type A to micro-b) cable. All that I need.
We'll just have to agree to disagree. Having lived it, the RS232 world sucked and I would never wish it upon anyone. USB is great.
PC Serial went through its own phase of incompatible/unreliable nonsense. Remember having to specifically spec 16550 Uarts? I do.
USB is very very sensitive to disturbance, including from RF. I've had to do a lot to protect it in the past.
- Green trace is AUX 5V current, 200 mA/div. 0 mA is one division above bottom.
- Blue trace is AUX 5V voltage at the supply header pins, 200 mV/div. 5 V is two divisions below top.
- Pink trace is PC-USB 5V voltage at the fuse, 200 mV/div. 5 V is two divisions below top.
- Orange is logic pin #58. 2 V/div. 0 V is bottom.
First image is of few normal runs then a singular port-open-failure. I think the 100 mV surge on PC-USB is unusual case even for a port-open-fail.
Second image shows the voltage surge zoomed in. You can see it roughly coincides with the start of the 10 ms wait between HUBSETs. Ie: When PLL gets initialised. The low region leading up to that will be the program download over USB.
Third image is, like the first, shows four apparently normal runs ... then just dead. The PC-USB LED has gone out.
Fourth image, I've stitched two screen shots together, is zoomed in on the very end piece where it has reset and appears to begin downloading but sort of trails off at that point.
Fifth image is same scale as fourth but for a normal boot sequence showing the three resets at the beginning and a successful download and engaging of the PLL. (at 350 MHz)
--Terry
Once the data is on the 485 cable it's a much more robust environment - partly because glitches there are not going to automatically kill the link. And even more robust if electrically isolated.
I can see how USB could be problematic in an industrial setting. I didn't think of that.
Are the resets those short drops to minimum green current, I think the internal reset-exit timer runs, but nothing else.
What is changing for the Pink USB voltage drop, lasts ~ 30ms ? is that the code download window ?
The +100mV step on USB seems to be a PC-Side decision, & some state change in the USB controller, but you say that is rare ?
Whenever it does freeze, does the P2 reset still work ok ? - I think pushing the RST button would give those RST-Idd signatures ? If the code is not corrupted, it would also then run ?
On trace 1 following the strange pink USB PC-Side pulse, (5ms after send completes, and during the 10ms P2 wait ?), after that time it seems to start a test sequence, but seems to not complete it, if I follow the green Icc right.
= other tests have a longer time at 350MHz ? - why did that one stop early - did the USB port generate a RST pulse ? The Green trace seem to go-min, and stay-min ?
Is there a RXD level test in the boot tree, ie suppose an errant RST arrives during serial send, as P2 boot-inspects pins, it may find RXD low ?
Looks like download completed, but P2 stays at 20MHz ? Would maybe a corrupted download do that ?
I've never heard of such issues on Linux or Mac, I think it could be Windows specific. What I do see a lot of is USB A connectors wearing out or filling with crud/dirt so they become unreliable. Careful restoring of contact springiness with
a jeweler's screw-driver can be useful. Hesistant plugging or unplugging of usb connectors is obviously best avoided.
Another problem I've seen is using cheapo USB1 leads for USB2 and higher. USB2 leads need to be of a certain minimum
quality just like network cables, they run at higher speeds than CAT5/CAT6 is rated for in fact...
I've encountered some driver-related issues for particular USB devices/OSs, but those are usually cause kernel panics and
are buggy 3rd-party drivers.
Yes, that fits the expected sequence. Program runs immediately after download is complete. But same story as above, I haven't compared with actual data transfer.
Reset always reverts to ROM code. It'll go back to waiting for boot up steps.
That's the nature of my randomiser. You'll see the three steps of I/O testing with terminal output, but after that it does the HUBSET trickery, with an initial 100ms pause for winding down the PLL, and also fills the cog with random data and jumps to #0. The result varies quite a lot. Sometimes the current draw goes up even higher.
Even if that did happen the next test cycle would bring it back to life - Which didn't happen. Corrupted program on the Prop2 certainly shouldn't cause a shutdown of every device on that USB bus! Which is what is happening there.
There is a clear ramp-to-max of the VCO during PLL initialisation. I have no idea how expected this is. I'm stating this based on observed power draw when engaging the PLL before it has obtained lock.
Here's what happens when setting 100 MHz with PLL engaged all the way: (Same scales as before)
Here's the source code for that:
Second image is a normal download and correct 100 MHz PLL engage at the start of the program.
Third image is the failed download and no run.
It's why I made sure Chip had the PLL counters capable of dividing up to the maximum expected VCO MHz. You need to be able to follow any VCO swings it may have.
If you enable PLL before lock is complete, the whole clock tree will be hit with a peak-VCO-MHz, hence the large current spike.
You also hope that the whole P2 core, can respond at that peak MHz.
That peak-VCO might not be the highest possible VCO, just where it swings to during lock-phase.
You could ask for 350MHz to check the 'indicated Mhz' of that peak - from the 100MHz lock base there, looks just over 400MHz ?
Does HUBSET have any inbuilt delays ? - you could drop a pin before the hubset command ? - there seems a slight Icc drop, 600us before the VCO swing ?
So you have a single 'instant' enable of both Xtal and PLL-VCO, no delay here ?
That is a quite brutal test, (but good stress test) and I'm surprised you seem to have no failures at the PLL init stage (failures seem to be post-download ?)
Quite impressive really...
If you want 100MHz, enable with a PostDIv of 2 or even 3, should lower the sysclk peak, before locking with a higher MHz VCO.
On my P2, even Enable of Xtal alone, and too-soon switch to SysCLK, would lock up P2, on a regular basis.
That was a little surprising, as I expected an auto-pause effect to simply wait until the Xtal amplitude was enough - but with no schmitt stage, seems there will be spiky/noisy clocks until the Xtal starts.
Can't recall if I tried immediate jump to VCO-out, but that would shift any Xtal-Noise effects to be a PFD problem, not a clock-tree problem.
Maybe that's how this test works ok ?
Can you predict a failure, from that subtle difference in pink-trace voltage profile ?
When it works, the trace suggests higher current during download, then a move to a lower, cleaner idle current.
When it fails, it looks to not lower as much, and has a different ripple pattern. (but ~1.4x faster than a 1ms repeat rate you might expect on a USB device ?)
What is the test baudrate here ?
You noticed.
I'm just back up and running again after destroying the AUX-USB switch, U501. Desoldered it and jumpered the power rails. I'm temped to also remove the PC-USB switch since the 5v-Common is now the disable for it. Not to mention the EVAL board never was suited to being powered from USB.
Yes, looks like the flip to VCO out, first has to wait for the Xtal to start, hence the 600us before the VCO has a PFD clock to lock to.
Then, it locks quite quickly.
There are impulses in current every 500us, is that a repeat in your code ? FWIR COG's did have a mA/MHz value, but rather less than the global clock tree, which dominates.
Reminds me.. I wonder how OnSemi are going, with the P&R and timing closures and the clock gating in P2+ ?
COGSTOPing all eight cogs offests the average level down but does nothing for the size or frequecy of the peaks.
Turns out it is all due to clocked I/O. I had 62 pins with clocking enabled. Turn that off and those pulses go away. I'm guessing those pulses are not something Chip had intended.
PS: That's the current reading of the 5 volt supply. So that has come via the 3v3 switchmode regulator, presumably.
So there is some conflict with the 3v3 switcher going on ... one wonders if that has been doing other bad things too ...
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.
but what about IO clocking can have a ~500us spike component ? SMPS is closer to 1MHz,
I have noticed the LDOs oscillate quietly away when not-jumpered (due to no CL) , so maybe they can partly explain the pulses, (LDOs feed from 5V)
- but how do they know you have IO clocking enabled ? that bit does not fit ?
IO Clocking should be a SysCLK domain loading, surely ? The levels shifters should have reasonable PSRR ?