Almost 2 Amps. Although it drops away to below 1.9, I think, as the prop2 heats up. I never leave it running long so haven't really seen how bad.
I've worked out that the PLL sourced sys-clock frequency is dropping off at the same time. It drops down to 350 MHz pretty quickly, then only slowly drops after that. So the reducing current is because of reducing clock rate.
PS: I believe it's stable at 360 MHz if the heatsink temperature is held around 20 oC.
I remember something like this happening with the rev A glob top testing. The overall frequency was slipping. The monitors didn't show it, they seemed to track the (slowing) video signal ok.
Its a good reason to have a freq/1000 output hooked into an external frequency meter
I remember something like this happening with the rev A glob top testing. The overall frequency was slipping. The monitors didn't show it, they seemed to track the (slowing) video signal ok.
Its a good reason to have a freq/1000 output hooked into an external frequency meter
Interesting, that suggests the loss of lock is more subtle, and does not involve chattering in frequency as you might expect from a PLL ?
Just retested the RevB board using the "primes-silent.c" program, to see the asymptotic curve of the current consumption. This is just a side test, done in the same conditions as the last ones.
Use the constants at the top to choose which test program to run (BURN_TYPE), the number of cogs to use (COGS_TO_BURN) and what clock rate to run at (XMUL/XDIV). Then assemble and download as per normal.
So, for program #3, set burn type to 3. For 8 eight cogs set cogs to burn to 8. For 360 MHz set xmul to 36.
Be warned: You can't do this only powered from the PC-USB socket. And if your AUX-USB is not strong then it will power down. And you'll likely have to unplug the USB to recover.
Did some tests with the RevB board running your code at 180MHz and 240MHz. Tried 360MHz, but the current is too big to be measured directly by the USB test switch. However, I would estimate about 1,62A.
Samuell,
Your readings are definitely scaled high. The bigger the reading the greater the error. I noticed it in an earlier test but thought the difference might have been the extra load from the USB chip. Now I see that that definitely isn't the case.
Here's what my multimeters and bench-top supply say for 8 cogs running test #3:
180 MHz 5.10 V 486 mA
240 MHz 5.06 V 645 mA
300 MHz 5.02 V 805 mA
360 MHz 4.98 V 976 mA
PS: Here's an updated version of the source code with tuned test programs #4 and #5, and neutral silicon detect code, and added comments for programs #2 and #3.
Definitely, my readings are even higher than yours. However, this is not due to a reading error, or something like that. The USB test switch current sense is confirmed to be within its 2.5% accuracy. I think that my P2 truly consumes that amount of current.
Is it possible for you to run "primes.c" without any user input, and post the value of current that you see? This would give me something to compare.
Samuell,
If your USB 5 volts is drooping under load then the nature of the switchmode regulator on the Eval Board will draw extra current, as the voltage droops more, to acquire the needed power.
The 5 volt readings I've posted above were metered at one of the accessory headers. Just have to close the ACC HDR 5V jumper and obviously need a volt meter.
Samuell,
If your USB 5 volts is drooping under load then the nature of the switchmode regulator on the Eval Board will draw extra current, as the voltage droops more, to acquire the needed power.
That is what I was thinking. The uCharge USB charger module outputs a very solid 5V, and can output up to 2A, or a bit more, before the OC protection kicks in. However, the USB test switch shows an on resistance of 0.22Ω. That, plus the resistance on the cables themselves, can cause a significant droop, thus increasing the perceived deviation or "error", as you well wrote. It is not an error on the current measurement side, but due to the voltage drop.
Given the previous, I'll have to repeat the tests while measuring the voltage at the "LDO VIN 5V" jumper.
As promised, I did some measurements and concluded that there is a significant voltage drop, causing a unwanted "deviation" on the current measurement. As you can see, the graph is not linear, indicating a larger "error", as the frequency and consumption current increase. The table shows that the voltage drop on the USB channel is pretty significant, and it is mostly caused by the cables themselves. The USB test switch shows some voltage drop too, but is is significantly smaller.
Note that the voltage supplied by the "uCharge" USB charger is very stable and solid. On the other hand, the voltage as measured on the "Aux" connector drops significantly.
Ah, cool. Much better. And I just woke up that I can duplicate that with the benchtop - I'm getting about 2.6% lower current for 4.17 V, at 240 MHz, when it should have been higher.
I think we can close the gap further. The voltage reading at AUX-USB will be a little high because there is an intermediary USB power switch on the Eval Board. Best place to measure the 5V-Common rail is at one of the accessory headers.
Redid all the measurements, even those that I did before, just because I saw some variation in the current and voltages, even though the conditions are similar (same cables and everything). Notice that I added to the table the measurements done on the "ACC HDR 5V" header. The U603 switch drops some voltage, but not that much. Still, it might account for a 1.7% difference, so the gap is further closed. The remaining difference might be due to the ADC and current sense amplifier used in the USB test switch, to measure the current. It is still well within the expected tolerance.
I've also added more data points so we can compare results. To avoid confusion, the column named "Switch drop (V)" was renamed to "TSW drop (V)". The USB test switch is an external board that is used to measure the current, and should not be confused with the U603 that is a switch internal to the P2 Eval.
By looking at the graph, there is some deviation that I can't understand, at 120MHz. I can speculate that the consumption current varies wildly, and can even increase a couple of mA for the same conditions, once the P2 heats up and settles. If we ignore that point, it is easy to see that the graph is not linear and has a tendency to curve upwards. I could calculate the core power, and do a new graph based on that, but I don't have the reference number of U701 and I can't take into account its efficiency (though it seems to be very close to 100%, as the part barely gets warm by itself).
I hope to hear from you, and I'm eager to compare results. This is important, because it will further validate my USB test switch.
Nice, that brings us to about 1% 1.3%. 240 MHz 4.097 V 792 mA. I'm happy.
Well, there are two factors to consider: one is the accuracy of the current metering circuit integrated in the USB test switch (and the difference is most likely to be due to that), and the other are differences in the silicon itself, or the boards (observed as the current tends to drift upwards with temperature).
Comments
I've worked out that the PLL sourced sys-clock frequency is dropping off at the same time. It drops down to 350 MHz pretty quickly, then only slowly drops after that. So the reducing current is because of reducing clock rate.
PS: I believe it's stable at 360 MHz if the heatsink temperature is held around 20 oC.
Its a good reason to have a freq/1000 output hooked into an external frequency meter
Interesting, that suggests the loss of lock is more subtle, and does not involve chattering in frequency as you might expect from a PLL ?
Thanks, Evan! Will be done next.
Kind regards, Samuel Lourenço
Did some tests with the RevB board running your code at 180MHz and 240MHz. Tried 360MHz, but the current is too big to be measured directly by the USB test switch. However, I would estimate about 1,62A.
Kind regards, Samuel Lourenço
Your readings are definitely scaled high. The bigger the reading the greater the error. I noticed it in an earlier test but thought the difference might have been the extra load from the USB chip. Now I see that that definitely isn't the case.
Here's what my multimeters and bench-top supply say for 8 cogs running test #3:
180 MHz 5.10 V 486 mA
240 MHz 5.06 V 645 mA
300 MHz 5.02 V 805 mA
360 MHz 4.98 V 976 mA
PS: Here's an updated version of the source code with tuned test programs #4 and #5, and neutral silicon detect code, and added comments for programs #2 and #3.
Is it possible for you to run "primes.c" without any user input, and post the value of current that you see? This would give me something to compare.
Kind regards, Samuel Lourenço
Your's was in the 150's I believe.
If your USB 5 volts is drooping under load then the nature of the switchmode regulator on the Eval Board will draw extra current, as the voltage droops more, to acquire the needed power.
That is what I was thinking. The uCharge USB charger module outputs a very solid 5V, and can output up to 2A, or a bit more, before the OC protection kicks in. However, the USB test switch shows an on resistance of 0.22Ω. That, plus the resistance on the cables themselves, can cause a significant droop, thus increasing the perceived deviation or "error", as you well wrote. It is not an error on the current measurement side, but due to the voltage drop.
Given the previous, I'll have to repeat the tests while measuring the voltage at the "LDO VIN 5V" jumper.
Kind regards, Samuel Lourenço
As promised, I did some measurements and concluded that there is a significant voltage drop, causing a unwanted "deviation" on the current measurement. As you can see, the graph is not linear, indicating a larger "error", as the frequency and consumption current increase. The table shows that the voltage drop on the USB channel is pretty significant, and it is mostly caused by the cables themselves. The USB test switch shows some voltage drop too, but is is significantly smaller.
Note that the voltage supplied by the "uCharge" USB charger is very stable and solid. On the other hand, the voltage as measured on the "Aux" connector drops significantly.
Kind regards, Samuel Lourenço
I think we can close the gap further. The voltage reading at AUX-USB will be a little high because there is an intermediary USB power switch on the Eval Board. Best place to measure the 5V-Common rail is at one of the accessory headers.
Redid all the measurements, even those that I did before, just because I saw some variation in the current and voltages, even though the conditions are similar (same cables and everything). Notice that I added to the table the measurements done on the "ACC HDR 5V" header. The U603 switch drops some voltage, but not that much. Still, it might account for a 1.7% difference, so the gap is further closed. The remaining difference might be due to the ADC and current sense amplifier used in the USB test switch, to measure the current. It is still well within the expected tolerance.
I've also added more data points so we can compare results. To avoid confusion, the column named "Switch drop (V)" was renamed to "TSW drop (V)". The USB test switch is an external board that is used to measure the current, and should not be confused with the U603 that is a switch internal to the P2 Eval.
By looking at the graph, there is some deviation that I can't understand, at 120MHz. I can speculate that the consumption current varies wildly, and can even increase a couple of mA for the same conditions, once the P2 heats up and settles. If we ignore that point, it is easy to see that the graph is not linear and has a tendency to curve upwards. I could calculate the core power, and do a new graph based on that, but I don't have the reference number of U701 and I can't take into account its efficiency (though it seems to be very close to 100%, as the part barely gets warm by itself).
I hope to hear from you, and I'm eager to compare results. This is important, because it will further validate my USB test switch.
Kind regards, Samuel Lourenço
It seems that there was a transcription error on the current value at 120MHz. Consider the results here attached, instead.
Kind regards, Samuel Lourenço
Kind regards, Samuel Lourenço