Shop OBEX P1 Docs P2 Docs Learn Events
P2 Reset - possible problem - Page 2 — Parallax Forums

P2 Reset - possible problem

2456

Comments

  • evanhevanh Posts: 15,091
    edited 2019-02-25 22:47
    whicker wrote: »
    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.
  • evanhevanh Posts: 15,091
    VonSzarvas wrote: »
    " The PC-USB power LED has gone out! "

    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.
  • Cluso99Cluso99 Posts: 18,066
    edited 2019-02-26 01:41
    whicker wrote: »
    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?
    Cluso99 wrote: »
    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!
  • evanhevanh Posts: 15,091
    edited 2019-02-26 02:01
    evanh wrote: »
    VonSzarvas wrote: »
    " The PC-USB power LED has gone out! "

    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.
  • I always thought USB stood for "Un-Stable Bus"
  • jmgjmg Posts: 15,140
    ozpropdev wrote: »
    I always thought USB stood for "Un-Stable Bus"

    Or Usable Sometimes Bus ?
  • jmgjmg Posts: 15,140
    evanh wrote: »
    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 ?

  • Cluso99 wrote: »
    whicker wrote: »
    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?
    Cluso99 wrote: »
    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.
  • evanhevanh Posts: 15,091
    Unreliable and incompatible are quite different things. The big complaint here is unreliability.

    USB is very very sensitive to disturbance, including from RF. I've had to do a lot to protect it in the past.
  • SeairthSeairth Posts: 2,474
    edited 2019-02-26 12:12
    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?
  • evanhevanh Posts: 15,091
    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.
    port-open-fail.PNG

    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.
    port-open-zoom.PNG

    Third image is, like the first, shows four apparently normal runs ... then just dead. The PC-USB LED has gone out.
    lockup.PNG

    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.
    lockup-boot.PNG

    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)
    normal-boot.PNG
    640 x 480 - 11K
    640 x 480 - 10K
    640 x 480 - 11K
    758 x 480 - 11K
    760 x 480 - 11K
  • 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
  • evanhevanh Posts: 15,091
    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.
  • ke4pjwke4pjw Posts: 1,059
    edited 2019-02-26 16:53
    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.
  • jmgjmg Posts: 15,140
    evanh wrote: »
    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 ?
    evanh wrote: »
    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 ?
  • Mark_TMark_T Posts: 1,981
    edited 2019-02-26 19:19
    ke4pjw wrote: »
    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.
  • evanhevanh Posts: 15,091
    edited 2019-02-27 02:50
    jmg wrote: »
    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.

    evanh wrote: »
    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.
  • evanhevanh Posts: 15,091
    edited 2019-02-27 11:23
    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)
    pin_lat0066.PNG

    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)
    
    		mov	pin, #55
    .unpins
    		dirl	pin			'un-AND
    		outl	pin			'un-AND
    		incmod	pin, #62	wz
    if_nz		jmp	#.unpins
    
    
    '
    'MUL on all cogs
    '
    		loc	ptra, #\@multest
    		mov	count, #15
    .mult
    		waitx	#500
    		coginit	count, ptra
    		djnf	count, #.mult
    
    		cogid	count
    		cogstop	count
    
    
    ORG
    multest
    cid		cogid	cid
    rnd1		add	cid, #55
    rnd2		drvl	cid
    .multloop
    		getrnd	rnd1
    		getrnd	rnd2
    		rep	@.rend, #10
    		mul	rnd1, cid
    		mul	rnd2, cid
    		mul	cid, rnd2
    		mul	cid, rnd1
    .rend
    		jmp	#.multloop
    
    
    640 x 480 - 11K
  • evanhevanh Posts: 15,091
    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.
    pin_lat0068.PNG

    Second image is a normal download and correct 100 MHz PLL engage at the start of the program.
    pin_lat0070.PNG

    Third image is the failed download and no run.
    pin_lat0071.PNG
    640 x 480 - 10K
    640 x 480 - 10K
    640 x 480 - 10K
  • evanhevanh Posts: 15,091
    I'm off to bed now but I may have found something with the Prop's tx pin, #62. Needs more testing ...
  • jmgjmg Posts: 15,140
    evanh wrote: »
    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 ?
    evanh wrote: »
    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 ?



  • jmgjmg Posts: 15,140
    evanh wrote: »
    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 ?)

    What is the test baudrate here ?
  • evanhevanh Posts: 15,091
    jmg wrote: »
    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.
  • evanhevanh Posts: 15,091
    jmg wrote: »
    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.
    pin_lat0072.PNG
    640 x 480 - 11K
  • evanhevanh Posts: 15,091
    Here's source for above
    		hubset	#0
    		waitx	##20_000_000/10		'~100ms
    		outl	#58
    		hubset	##_ENAFREQ		'setup and enable oscillator together (expected lock-up)
    		...
    
  • jmgjmg Posts: 15,140
    evanh wrote: »
    jmg wrote: »
    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+ ?
  • evanhevanh Posts: 15,091
    edited 2019-02-28 00:49
    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.
  • evanhevanh Posts: 15,091
    edited 2019-02-28 01:01
    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.
  • jmgjmg Posts: 15,140
    evanh wrote: »
    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,
    evanh wrote: »
    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 ?

Sign In or Register to comment.