I set up for minimal activity to keep lowest and steady current draw. They were around 25 mA for VDD and 7 mA for VIO.
I use an old test program I'd made for finding the min/max power needs of the prop2. All cogs were set to run the following. I found that a cog cycling WAITX uses less power than a stopped cog:
It'll be a fixed amount for the PLL at any particular frequency. The prop2 total current can be ramped up a lot at that frequency but the PLL current won't change. I kept the total minimal in my testing to make it easiest to pick out the PLL usage.
PS: I've just rerun testing with a little more care not to be using extra power and got refined answer:
Prop2 revB-globtop (VDD = 1.86 V)
| VIO VDD
--------|-----------------------
RCFAST | 6.320 mA 23.350 mA
25 MHz | 7.287 mA 23.392 mA
Diff | 967 uA 42 uA
Actually, RCFAST seems to be a surprisingly consistent frequency of 25.1 MHz for revB silicon. It changed from revA to revB but Chip did that I think. Has anyone measured revC? It should be at 25.1 MHz, same as revB.
Actually, RCFAST seems to be a surprisingly consistent frequency of 25.1 MHz for revB silicon. It changed from revA to revB but Chip did that I think. Has anyone measured revC? It should be at 25.1 MHz, same as revB.
The changes are more likely related to batch, as within a batch the variation is less, than between batches.
Actually, RCFAST seems to be a surprisingly consistent frequency of 25.1 MHz for revB silicon. It changed from revA to revB but Chip did that I think. Has anyone measured revC? It should be at 25.1 MHz, same as revB.
If I connect a scope to P32 on my revB EVAL and boot into TAQOZ ROM and type "32 PIN $8000_0000 NCO" I get 12.6MHz which means RCFAST is running at around 25.2MHz.
Typing "RCSLOW" (and losing comms) it reads 10.4kHz so 20.8kHz for RCSLOW.
Note: I could have typed "RCSLOW 200,000 WAITX RCFAST" to return back to the console after about 10 seconds.
It's a nice frequency for VGA, but I found it's a bit too unstable for proper syncing on an LCD (maybe an analog monitor could show it).
RC oscillators have just a bit too much jitter, so the monitors act like oscilloscopes, and the Y axis nicely plots the jitter over each line time...
Could be useful for debug, but not something you would ship out the door
For anyone reading the forum that have more or less the same problem like me, I have a solution that works for me.
I worked around the problem. I just do this instead of reset:
asm
coginit #0,#0
endasm
I don't think the problem is in the clock, as the propeller starts booting and loads the first 1024 bytes from flash.
I think the data is read wrong (1 bit or so).
So if rebooting is a problem, don't reboot
Just measured RCFAST on my two revB boards. The glob-top is almost bang on 25.10 MHz and the finished ES is 25.17 MHz. So not much in it here.
Are you using a frequency counter or the scope?
I just went and referenced against the P2D2 RTC and got a much better idea of the clock with a simple loop that times 32768 pulses from the RTC clock output available on P34 through a 100k resistor. I also timed it again back at 300MHz so I guess the 24.9775MHz figure for RCFAST is pretty close.
TAQOZ# 50 ms RCFAST CLKFREQ? 300 clkfreq! . --- 24977544 ok
TAQOZ# CLKFREQ? . --- 300004320 ok
Hmm, maybe the same PLL glitch can lockup a programmed reset. I note Eric has reboot() function in fastspin that drops back to RCFAST before performing the reset.
Ah, interesting. Looking at Eric's code for clkset(), the above introduces a problem. clkset() in fastspin uses the mode value to decide if the clock source select should be the PLL or not. If the mode is greater than 1 then it selects the PLL. The above, with a 10 MHz crystal, will produce an 80 MHz sysclock under fastspin.
pri _clkset(mode, freq) | oldmode, xsel
xsel := mode & 3
if xsel == 0 and mode > 1
xsel := 3
oldmode := __clkmode_var & !3 ' remove low bits, if any
__clkfreq_var := freq
__clkmode_var := mode
mode := mode & !3
asm
hubset oldmode ' go to RCFAST using known prior mode
hubset mode ' setup for new mode, still RCFAST
waitx ##20_000_000/100 ' wait ~10ms
or mode, xsel
hubset mode ' activate new mode
endasm
Comments
I use an old test program I'd made for finding the min/max power needs of the prop2. All cogs were set to run the following. I found that a cog cycling WAITX uses less power than a stopped cog:
That sounds acceptable to me, considering the apparent risk with turning it off...
PS: I've just rerun testing with a little more care not to be using extra power and got refined answer:
Prop2 revB-globtop (VDD = 1.86 V) | VIO VDD --------|----------------------- RCFAST | 6.320 mA 23.350 mA 25 MHz | 7.287 mA 23.392 mA Diff | 967 uA 42 uA@jef_vt seems to be having some issue that appear to be related to coming back to PLL on after having PLL off.
Or, is it all sorted out now?
Although, maybe that's not so important...
Edit: and my RevB Glob-top RCFAST runs at 25.6MHz
Typing "RCSLOW" (and losing comms) it reads 10.4kHz so 20.8kHz for RCSLOW.
Note: I could have typed "RCSLOW 200,000 WAITX RCFAST" to return back to the console after about 10 seconds.
So, RCFAST is different on every die, but relatively temperature stable. Whereas RCSLOW has large temperature drift.
EDIT: RCSLOW jitter is around 3500 ppm. RCFAST looks to have 250 ppm high frequency jitter but then there is a sub 1 Hz wobble that is larger.
RC oscillators have just a bit too much jitter, so the monitors act like oscilloscopes, and the Y axis nicely plots the jitter over each line time...
Could be useful for debug, but not something you would ship out the door
I worked around the problem. I just do this instead of reset: I don't think the problem is in the clock, as the propeller starts booting and loads the first 1024 bytes from flash.
I think the data is read wrong (1 bit or so).
So if rebooting is a problem, don't reboot
Does a hard reboot (pressing a reset button or reset via FT231X) have the same 1% failure rate?
Or, is it something about a soft reboot that is the problem?
Also, are you sharing the flash chip pins with a uSD card or anything else?
Are you using a frequency counter or the scope?
I just went and referenced against the P2D2 RTC and got a much better idea of the clock with a simple loop that times 32768 pulses from the RTC clock output available on P34 through a 100k resistor. I also timed it again back at 300MHz so I guess the 24.9775MHz figure for RCFAST is pretty close.
Ah, interesting. Looking at Eric's code for clkset(), the above introduces a problem. clkset() in fastspin uses the mode value to decide if the clock source select should be the PLL or not. If the mode is greater than 1 then it selects the PLL. The above, with a 10 MHz crystal, will produce an 80 MHz sysclock under fastspin.
pri _clkset(mode, freq) | oldmode, xsel xsel := mode & 3 if xsel == 0 and mode > 1 xsel := 3 oldmode := __clkmode_var & !3 ' remove low bits, if any __clkfreq_var := freq __clkmode_var := mode mode := mode & !3 asm hubset oldmode ' go to RCFAST using known prior mode hubset mode ' setup for new mode, still RCFAST waitx ##20_000_000/100 ' wait ~10ms or mode, xsel hubset mode ' activate new mode endasm