Here is a letter I wrote to Wendy which summarizes our glitch problem:
Wendy,
I realize now that the reason the ROM seemed to be buggy was because of glitching that occurs when floating a high output pin.
In the picture, you see P59 on top and P58 on the bottom. At first, they are each driving low, then driving high, then being FLOATED (DIR falls). When the float occurs on a high pin, each P0..P63 glitches to a different extent. You can see that P59 glitches almost half way down when floated (DIR falls, inducing a temporary negative spike on PO before DIR falling takes effect). Each pin is different in this regard because of the lay of the auto-generated wiring and, possibly, test logic.
Do you have a map of what your test circuitry uses P0..P63 for? That might shed more light. It's kind of hard to imagine that an internally-driven wire could be influenced to actually change state temporarily (4ns is long!), as PO seems to, but maybe there's some intervening test logic that is doing this.
We need to know what's causing this. Perhaps some test-circuitry mux'ing needs to be reorganized, and then we could skew-band the DIR and PO signals, as well as shield them each on the next turn.
Those look similar to Chip's - COGs (Clock tree only) values.
I've not seen RCSLOW Icc numbers or even a confirm RCSLOW works ok ?
The Cpd formula predicts
Vcc=1.8; Pd = Cpd * Vcc^2 * Fi = 112uA at 20kHz,1v8 + Static Iq value
Vcc = 1.5 Pd = 78uA
Vcc = 1.3 Pd = 58uA + Static Iq should drop more quickly ?
My curve fits of Chip's table gave ~5mA static Icc, but that may include Xtal-Osc and/or RCFAST overheads ?
Another means to lower Icc below ~70mA would be to use the lowest PLL output (or just a divided Xtal, if that path exists ?)
What is the lowest possible sysCLK using PLL ?
Is it possible to RCSLOW and keep the Xtal running ? (IIRC Chip mentioned some HW fixed Startup time on Xtal enable?)
I also figured a way to measure RCFAST and RCSLOW, maybe on Chip's P2 Board ?
The NXP 74AHC1G4210/12/14 are new SOT25 Osc/Dividers, so one of those could connect to (or replace) P2 Xtal Osc, and output (eg) 732.421875Hz at 12MHz, 2^14 case.
A ~100mS read time will resolve RCSLOW to 0.05% - I think there is a smart pin mode for measure time for X whole cycles, X = 74 here
Expected dT value is 20k/(12M/2^14/74) = 2020.693
Curve fit of RCFAST and RCSLOW may give a means to measure die temperature.
Addit: low power OSC options :
TG-5035CJ-13N 19.2000M3 gives 19.2MHz Standby (Power Down) 2ms max wakeup, 1.7 V ~ 3.6 V ±500ppb -40°C ~ 85°C < 1.5mA 91c/2.5k
That will also need Xtal-Amplifier ON
Other Oscillator choices :
DSC6001 Microchip - 1.3mA typ Icc ~64c/3k/ ±50ppm
DSC6003CI2A-012.0000T 1.25mA ~ 74c ±25ppm
and for ~ 67c/3k, there are even lower power choices
Current Consumption IDD SiT8021 1 to 26 MHz, Ultra-Small µPower Oscillator 4-UFBGA (1.54mm x 0.84mm)
- Typ Max
– 60 – µA f = 3.072 MHz, Vdd = 1.8V, no load
– 110 130 µA f = 6.144 MHz, Vdd = 1.8V, no load
– 230 270 µA f = 6.144 MHz, Vdd = 1.8V, 10 pFload
– – 160 µA f = 6.144 MHz, Vdd = 2.25V to 3.63V, no load
– 160 – µA f = 12 MHz, Vdd = 1.8V, no load
Standby Current[3] I_std
– 0.7 1.3 µA Vdd = 1.8V, ST pin = HIGH, output is weakly pulled down
– – 1.5 µA Vdd = 2.25V to 3.63V, ST pin = HIGH, output is weakly pulled down
Startup Time T_start – 75 150 ms Measured from the time VDD reaches 90% of its final value
Standby Time T_stdby – – 20 µs Measured from the time ST pin crosses 50% threshold
Resume Time T_resume – 2 3 ms Measured from the time ST pin crosses 50% threshold
InitialTolerance f_tol -15 – +15 ppm Frequency offset at 25°C postreflow
FrequencyStability f_stab -100 – +100 ppm Inclusive of initial tolerance, and variations over operating temperature, rated power supply voltage and output load.
First Year Aging f_1year -3 +3 ppm at 25°C
Contact SiTime for ±25 or ±50 ppm options.
That's low enough to run continually, with modest Icc, and if the design needed to keep more precise time during RCSLOW, it looks like a 74AHC1G421x could feed a smart-pin-counter.
(2.048MHz at 3v3 into 74AHC1G421x indicates ~89uA adder for the high-precision-sleep option. (62.5Hz edges)
This section seems to imply that you can float or drive pins:
%P..P: low-level pin control (needs final silicon to fully operate)
%0000CIOHHHLLL = digital mode (default = %0000000000000)
%C: 1 = clocked I/O (extra clock for IN and OUT)
%I: 1 = invert IN output
%O: 1 = invert OUT input
%HHH: 000 = drive high, other = float when driven high
%LLL: 000 = drive low, other = float when driven low
This is a really good point, you can configure the pin to have one sided drive, other side float. Then you're only toggling OUT without needing to toggle DIR. That doesn't cost the extra clock that clocked/registered I/O might need. So there are few practical workaround options available with the silicon as it is, we're just 'zoomed in' on the problem to gain maximum understanding, at the moment.
Back on the fpga images for a moment, these also used to show up a few phantom pull up/down pins when using the LSIO command. I wonder if some understanding could be gained from this, since we could recompile the FPGA image with different constraints on those signals, or check the correlation between signal path timing and length of external glitch etc.
These pins' DIR and OUT signals come from flop outputs in the core and go straight to the pins' DIR and OUT inputs, without any combinatorial logic, though buffering may exist.
What we are seeing on P59 is purely routing and possibly buffering delays, along with crosstalk.
The tools ensured that the OUT signal would meet setup and hold timing for the I/O pad's internal flop, but what happened outside that window was "don't-care", apparently.
What wide-OR are you meaning? I don't know of any.
P1 Data says this, so I'm assuming P2 is the same OUT/DIR OR ? :
"Pin Directions are the result of OR'ing the Direction Registers of the cogs together. Pin Outputs are the result of OR'ing the output states of the cogs together. A cog's output state consists of the bits of its I/O modules (the Counters, the Video Generator, and the I/O Output Register) OR'd together then AND'd with the bits of its Direction Register. All cogs can still access and influence the I/O pins simultaneously, without electrical contention,"
I guess that means this effect should be checked for all COGs, to see if it varies by their 'place in that OR' ?
This is a really good point, you can configure the pin to have one sided drive, other side float. Then you're only toggling OUT without needing to toggle DIR. That doesn't cost the extra clock that clocked/registered I/O might need. So there are few practical workaround options available with the silicon as it is, we're just 'zoomed in' on the problem to gain maximum understanding, at the moment.
Yes, another workaround, because this is low-energy, could be to add a 100R+47pF RC snubber, to see if that reduces the step.
What wide-OR are you meaning? I don't know of any.
P1 Data says this, so I'm assuming P2 is the same OUT/DIR OR ? :
"Pin Directions are the result of OR'ing the Direction Registers of the cogs together. Pin Outputs are the result of OR'ing the output states of the cogs together. A cog's output state consists of the bits of its I/O modules (the Counters, the Video Generator, and the I/O Output Register) OR'd together then AND'd with the bits of its Direction Register. All cogs can still access and influence the I/O pins simultaneously, without electrical contention,"
I guess that means this effect should be checked for all COGs, to see if it varies by their 'place in that OR' ?
Oh, okay. That happens in the core logic about two clocks before the final DIR and OUT signals come out.
Here are the %PPPPPPPPPPPPP bits for the actual P2 silicon:
Nice table,
Other settings to check there, could be 1mA drive (expect similar to 1.5k ?) - is that 1mA nom when shorted ? ie maybe just enough to direct drive a LED ?
That seems to be missing a 'moderate' drive choice - fastest option is often avoided in MCU designs, for a softer choice (eg) 4mA spec, but that's 4mA at < 0.5V so sub 250 ohms.
I also see 0000_ Pin A Logic OUT
and 0011_ pin A Schmitt OUT
- does the out path change in those ?
& maybe output Invert/non invert also has a slight effect ?
Here are the %PPPPPPPPPPPPP bits for the actual P2 silicon:
Nice table,
Other settings to check there, could be 1mA drive (expect similar to 1.5k ?) - is that 1mA nom when shorted ? ie maybe just enough to direct drive a LED ?
That seems to be missing a 'moderate' drive choice - fastest option is often avoided in MCU designs, for a softer choice (eg) 4mA spec, but that's 4mA at < 0.5V so sub 250 ohms.
I also see 0000_ Pin A Logic OUT
and 0011_ pin A Schmitt OUT
- does the out path change in those ?
& maybe output Invert/non invert also has a slight effect ?
The modes which use OUT for output are normal. The modes which use "input" for output actually use the selected input as the output. For example, You can use the "A > B" "input" mode with the "O" bit set (inverts output) and %010 for HHH and LLL (15k-ohm drive) to build an analog follower.
The current drive modes use real current sources and sinks. Here is how to make a Schmitt oscillator on one pin to convert capacitance to frequency. I used a 0.1uF cap:
dat org
wrpin pinmode,#1 'set Schmitt w/feedback and 100uA drive
dirh #1 'enable output
jmp #$ 'loop
pinmode long %0000_0000_000_0100001101101_00_00000_0
Re: P59 pullup needed for boot.
Regardless of any glitch issue, the P2 should boot without pullups.
A bug in the ROM is the reason for thee need for the P59 pullup.
The rom is correct but does not detect pulldown correctly now that since some pins exhibit this glitch in this silicon. The rom boot was designed so that unless there were pull-up and pulldown resistors, it would boot normally
The ROM checks for 3 pullups.
If no pullups are detected it should go to serial mode and wait, this can't happen the way the ROM code is currently. See here
With 3 pulldowns on my FPGA it shutdowns immediately after reset, same as silicon P2.
The modes which use OUT for output are normal. The modes which use "input" for output actually use the selected input as the output. For example, You can use the "A > B" "input" mode with the "O" bit set (inverts output) and %010 for HHH and LLL (15k-ohm drive) to build an analog follower.
The current drive modes use real current sources and sinks. Here is how to make a Schmitt oscillator on one pin to convert capacitance to frequency. I used a 0.1uF cap:
dat org
wrpin pinmode,#1 'set Schmitt w/feedback and 100uA drive
dirh #1 'enable output
jmp #$ 'loop
pinmode long %0000_0000_000_0100001101101_00_00000_0
Wow, that's nifty to see working. A linear sawtooth too !
Have you tried that as a Capacitive Touch Sensor ?
It should also work with inductors, AC coupled to a LC resonant circuit, for inductive proximity detector use.
The modes which use OUT for output are normal. The modes which use "input" for output actually use the selected input as the output. For example, You can use the "A > B" "input" mode with the "O" bit set (inverts output) and %010 for HHH and LLL (15k-ohm drive) to build an analog follower.
The current drive modes use real current sources and sinks. Here is how to make a Schmitt oscillator on one pin to convert capacitance to frequency. I used a 0.1uF cap:
dat org
wrpin pinmode,#1 'set Schmitt w/feedback and 100uA drive
dirh #1 'enable output
jmp #$ 'loop
pinmode long %0000_0000_000_0100001101101_00_00000_0
Wow, that's nifty to see working. A linear sawtooth too !
Have you tried that as a Capacitive Touch Sensor ?
It should also work with inductors, AC coupled to a LC resonant circuit, for inductive proximity detector use.
I haven't tried all those things, but figured that if we made some simple provisions, they would all be easy to do.
The PLL's VCO tops out at 408MHz, which gives plenty of overhead. Well, it might be the VCO divider that runs out of steam at 408MHz. Not sure, but it's plenty good enough.
I'm going through the PLL, getting a feel for its jitter.
I'm not really sure. I was exploring if it was even practical.
I would need to make my own air gapped capacitor (unless i can find one premade).
The idea is that it would be connected to a shaft and then its value measured as the shaft turned (90 deg rotation max).
My first real question was how to measure this kind of cap fast enough directly from a uC so that I would have reasonable resolution. Most sources I found referenced using an RC circuit and measureing the time it takes the cap to ramp up but that seems completely impractical for quick measurements.
Perhaps the smart pin in this mode answers the speed/resolution question?
I'm not really sure. I was exploring if it was even practical.
I would need to make my own air gapped capacitor (unless i can find one premade).
The idea is that it would be connected to a shaft and then its value measured as the shaft turned (90 deg rotation max).
My first real question was how to measure this kind of cap fast enough directly from a uC so that I would have reasonable resolution. Most sources I found referenced using an RC circuit and measureing the time it takes the cap to ramp up but that seems completely impractical for quick measurements.
Perhaps the smart pin in this mode answers the speed/resolution question?
j
If you are talking shaft rotation, then you can get something premade like this Differential Capacitor claims 2.7 - 19.6 pF for one.
Differential means have two C values you measure, (use 2 pins) and at some rotation they balance for the zero.
The P2 Current sources, and Schmitt thresholds, are error sources, but they will tend to track on adjacent pins.
You could use the 100uA or 10uA drive levels Chip mentioned above - 10pF/100uA/1V is going to give appx 5MHz, so you need short, leads.
Measurement speed depends on resolution, but for a ball-park a 1MHz signal can resolve to 0.1% in a 1ms measure time.
It regulates a heavily-RC-filtered copy of the 1.8V supply from the 3.3V supply on the V2831 pin. So, it has a very quiet VDD-level supply to power itself from. The 20MHz+ RC oscillator uses this same supply for stability.
I can't believe the VCO locks down to 1.25MHz! I had figured it could be conservatively rated for 100MHz-200MHz operation, but I think 25MHz would be okay, too.
With the PLL copying the crystal frequency and dividing it by 20 using the post-VCO divider to get 1MHz, the P2 draws 3.0mA at 1.8V.
With the PLL dividing the crystal frequency by 10 and then post-dividing that by 20 to get 100KHz, the P2 draws 354uA at 1.8V.
Switching down to the internal ~20KHz oscillator, the P2 draws 97uA at 1.8V. So, leakage isn't much.
Here is the program I use to play with the PLL. It's set for 180MHz. I have a 20MHz crystal attached between XI and XO:
con xtl_div = 1 'crystal divider 1..64
vco_mul = 9 'vco multiplier 1..1024
clkmod = 1<<24 + (xtl_div-1)<<18 + (vco_mul-1)<<8 + %1111_10_00
'clkmod = %1_000000_0000000000_1111_10_00 'PLL mode (manual version)
dat org
hubset ##clkmod 'enable crystal+PLL, stay in 20MHz+ mode
waitx ##20_000_000/100 'wait ~10ms for crystal+PLL to stabilize
hubset ##clkmod | %11 'now switch to PLL
.loop drvnot #1 '2 P1 = Fsys/1000
waitx #500-8 '2 + #
jmp #.loop '4
The PLL jitter seems to be identical to the crystal jitter, which makes sense, as long as it's locked.
Based on the value of the 6-bit crystal divider, PLL charge-pump feedback current is increasingly weakened, getting around the need for separate filter settings. It seems to work really well.
Comments
At 200 MHz and ADC, seems we could also do FFT maybe a bit better but slower...
Do you have a circuit of how the synthesis signals interface to the fixed PAD-Ring logic ? (including the wide-OR that's in there too somewhere )
Does the synth process allow you to control P:N drive strengths ?
You could ask onSemi for plots (or sims) of P59, P58 routing paths and cross talks on those paths.
What wide-OR are you meaning? I don't know of any.
Yes, I will ask for some data on P59's and P58's DIR and PO signals from the core.
Those look similar to Chip's - COGs (Clock tree only) values.
I've not seen RCSLOW Icc numbers or even a confirm RCSLOW works ok ?
The Cpd formula predicts
Vcc=1.8; Pd = Cpd * Vcc^2 * Fi = 112uA at 20kHz,1v8 + Static Iq value
Vcc = 1.5 Pd = 78uA
Vcc = 1.3 Pd = 58uA + Static Iq should drop more quickly ?
My curve fits of Chip's table gave ~5mA static Icc, but that may include Xtal-Osc and/or RCFAST overheads ?
Another means to lower Icc below ~70mA would be to use the lowest PLL output (or just a divided Xtal, if that path exists ?)
What is the lowest possible sysCLK using PLL ?
Is it possible to RCSLOW and keep the Xtal running ? (IIRC Chip mentioned some HW fixed Startup time on Xtal enable?)
I also figured a way to measure RCFAST and RCSLOW, maybe on Chip's P2 Board ?
The NXP 74AHC1G4210/12/14 are new SOT25 Osc/Dividers, so one of those could connect to (or replace) P2 Xtal Osc, and output (eg) 732.421875Hz at 12MHz, 2^14 case.
A ~100mS read time will resolve RCSLOW to 0.05% - I think there is a smart pin mode for measure time for X whole cycles, X = 74 here
Expected dT value is 20k/(12M/2^14/74) = 2020.693
Curve fit of RCFAST and RCSLOW may give a means to measure die temperature.
Addit: low power OSC options :
TG-5035CJ-13N 19.2000M3 gives 19.2MHz Standby (Power Down) 2ms max wakeup, 1.7 V ~ 3.6 V ±500ppb -40°C ~ 85°C < 1.5mA 91c/2.5k
That will also need Xtal-Amplifier ON
Other Oscillator choices :
DSC6001 Microchip - 1.3mA typ Icc ~64c/3k/ ±50ppm
DSC6003CI2A-012.0000T 1.25mA ~ 74c ±25ppm
and for ~ 67c/3k, there are even lower power choices
That's low enough to run continually, with modest Icc, and if the design needed to keep more precise time during RCSLOW, it looks like a 74AHC1G421x could feed a smart-pin-counter.
(2.048MHz at 3v3 into 74AHC1G421x indicates ~89uA adder for the high-precision-sleep option. (62.5Hz edges)
Comes down to what is Static Icc looking like ?
This is a really good point, you can configure the pin to have one sided drive, other side float. Then you're only toggling OUT without needing to toggle DIR. That doesn't cost the extra clock that clocked/registered I/O might need. So there are few practical workaround options available with the silicon as it is, we're just 'zoomed in' on the problem to gain maximum understanding, at the moment.
Back on the fpga images for a moment, these also used to show up a few phantom pull up/down pins when using the LSIO command. I wonder if some understanding could be gained from this, since we could recompile the FPGA image with different constraints on those signals, or check the correlation between signal path timing and length of external glitch etc.
The following pins' signals get mux'd, but the other pins' signals don't:
P0 = tck
P1 = trst
P2 = tms
P3 = tdi
P4 = tdo
P6 = test_reset
P7 = shift_capture_clock
P8 = scan_en
P10 = scan_in
P11 = scan_out
P12 = scan_in
P13 = scan_out
P14 = scan_in
P15 = scan_out
P16 = scan_in
P17 = scan_out
So, this means:
P5, P9, P18..P63 = unused for test, no mux'ing.
These pins' DIR and OUT signals come from flop outputs in the core and go straight to the pins' DIR and OUT inputs, without any combinatorial logic, though buffering may exist.
What we are seeing on P59 is purely routing and possibly buffering delays, along with crosstalk.
The tools ensured that the OUT signal would meet setup and hold timing for the I/O pad's internal flop, but what happened outside that window was "don't-care", apparently.
P1 Data says this, so I'm assuming P2 is the same OUT/DIR OR ? :
"Pin Directions are the result of OR'ing the Direction Registers of the cogs together. Pin Outputs are the result of OR'ing the output states of the cogs together. A cog's output state consists of the bits of its I/O modules (the Counters, the Video Generator, and the I/O Output Register) OR'd together then AND'd with the bits of its Direction Register. All cogs can still access and influence the I/O pins simultaneously, without electrical contention,"
I guess that means this effect should be checked for all COGs, to see if it varies by their 'place in that OR' ?
Oh, okay. That happens in the core logic about two clocks before the final DIR and OUT signals come out.
Nice table,
Other settings to check there, could be 1mA drive (expect similar to 1.5k ?) - is that 1mA nom when shorted ? ie maybe just enough to direct drive a LED ?
That seems to be missing a 'moderate' drive choice - fastest option is often avoided in MCU designs, for a softer choice (eg) 4mA spec, but that's 4mA at < 0.5V so sub 250 ohms.
I also see 0000_ Pin A Logic OUT
and 0011_ pin A Schmitt OUT
- does the out path change in those ?
& maybe output Invert/non invert also has a slight effect ?
The modes which use OUT for output are normal. The modes which use "input" for output actually use the selected input as the output. For example, You can use the "A > B" "input" mode with the "O" bit set (inverts output) and %010 for HHH and LLL (15k-ohm drive) to build an analog follower.
The current drive modes use real current sources and sinks. Here is how to make a Schmitt oscillator on one pin to convert capacitance to frequency. I used a 0.1uF cap:
I'm free
Regardless of any glitch issue, the P2 should boot without pullups.
A bug in the ROM is the reason for thee need for the P59 pullup.
If no pullups are detected it should go to serial mode and wait, this can't happen the way the ROM code is currently.
See here
With 3 pulldowns on my FPGA it shutdowns immediately after reset, same as silicon P2.
Wow, that's nifty to see working. A linear sawtooth too !
Have you tried that as a Capacitive Touch Sensor ?
It should also work with inductors, AC coupled to a LC resonant circuit, for inductive proximity detector use.
I haven't tried all those things, but figured that if we made some simple provisions, they would all be easy to do.
I'm going through the PLL, getting a feel for its jitter.
Could this setup do that?
J
I would need to make my own air gapped capacitor (unless i can find one premade).
The idea is that it would be connected to a shaft and then its value measured as the shaft turned (90 deg rotation max).
My first real question was how to measure this kind of cap fast enough directly from a uC so that I would have reasonable resolution. Most sources I found referenced using an RC circuit and measureing the time it takes the cap to ramp up but that seems completely impractical for quick measurements.
Perhaps the smart pin in this mode answers the speed/resolution question?
j
If you are talking shaft rotation, then you can get something premade like this Differential Capacitor claims 2.7 - 19.6 pF for one.
Differential means have two C values you measure, (use 2 pins) and at some rotation they balance for the zero.
The P2 Current sources, and Schmitt thresholds, are error sources, but they will tend to track on adjacent pins.
You could use the 100uA or 10uA drive levels Chip mentioned above - 10pF/100uA/1V is going to give appx 5MHz, so you need short, leads.
Measurement speed depends on resolution, but for a ball-park a 1MHz signal can resolve to 0.1% in a 1ms measure time.
..and a paper on Linear Cap measurement is here
It regulates a heavily-RC-filtered copy of the 1.8V supply from the 3.3V supply on the V2831 pin. So, it has a very quiet VDD-level supply to power itself from. The 20MHz+ RC oscillator uses this same supply for stability.
I can't believe the VCO locks down to 1.25MHz! I had figured it could be conservatively rated for 100MHz-200MHz operation, but I think 25MHz would be okay, too.
With the PLL copying the crystal frequency and dividing it by 20 using the post-VCO divider to get 1MHz, the P2 draws 3.0mA at 1.8V.
With the PLL dividing the crystal frequency by 10 and then post-dividing that by 20 to get 100KHz, the P2 draws 354uA at 1.8V.
Switching down to the internal ~20KHz oscillator, the P2 draws 97uA at 1.8V. So, leakage isn't much.
Here is the program I use to play with the PLL. It's set for 180MHz. I have a 20MHz crystal attached between XI and XO:
Based on the value of the 6-bit crystal divider, PLL charge-pump feedback current is increasingly weakened, getting around the need for separate filter settings. It seems to work really well.
I'm chucking at P2 running at a brisk 1mhz...
If the next one is clock gated, seems like the power equation is going to be a lot more favorable at higher clock rates.