I could do that now. Could you confirm the steps and any source code ?
Pulldown on P58
<insert SD card, FAT32, file content?> ?
<run code> ?
Trigger on P58 ?
Also, bearing in mind P2-EVAL has 47pF on that pin... do you want that removed or reduced first?
I think P2D2 had 10-12pf there, but I don't have one of those to test.
I could do that now. Could you confirm the steps and any source code ?
Pulldown on P58
<insert SD card, FAT32, file content?> ?
<run code> ?
Trigger on P58 ?
Also, bearing in mind P2-EVAL has 47pF on that pin... do you want that removed or reduced first?
I think P2D2 had 10-12pf there, but I don't have one of those to test.
This would be great thanks vonszarvas.
Just use another close pin such as P56 ( dont think anything is on this pin).
Place a pulldown and do this for the 3 values ie 3 traces
Trigger on the pin
Run a simple program to
DRVH #56 ‘trigger here on high
WAITX #30
FLTH #56
JMP #$
Repeat the above with pullups ie 3 traces using the program
DRVL #56. ‘trigger here on low
WAITX #30
FLTL #56
JMP #$
This would be fantastic thanks. I know this wouldbe slightly different with an sd card present but will be good enough to see what is happening.
Ray
Yes, its only the 4 boot pins that are of interest P58-61.
Because i found a problem, i want to understand the timing because it could potentially affect the ROM Boot code.
From the trace i should be able to ensure i read in the correct eindow. The small hysterisis where the chip sees the change should not matter if ive chosen the timing correctly.
With this code and 10K pulldown I get the attached.
Is this the right setup for the detail you need?
I'll install the scope software on this PC, then grab the rest right now.
dat org
' set up clock
hubset ##%1_000000_0000001100_1111_10_00 'enable crystal+PLL, stay in 20MHz+ mode
waitx ##20_000_000/100 'wait ~10ms for crystal+PLL to stabilize
'hubset ##%1_000000_0000001100_1111_10_11 'now switch to PLL
loop
DRVH #56 'trigger here on high
WAITX #30
FLTH #56
WAITX #30
jmp #loop
Yes, that will do nicely with just the waitx changes so i can see that we got to gnd. So just tweek them as follows please
dat org
' set up clock
hubset ##%1_000000_0000001100_1111_10_00 'enable crystal+PLL, stay in 20MHz+ mode
waitx ##20_000_000/100 'wait ~10ms for crystal+PLL to stabilize
'hubset ##%1_000000_0000001100_1111_10_11 'now switch to PLL
loop
DRVH #56 'trigger here on high
WAITX #15
FLTH #56
WAITX #45
jmp #loop
Just trying P58 for comparison...
Scope results the same for P58, except that with 22K the pulse frequency starts to vary slightly as the cap influences.
It would be interesting to see separate captures for CAP added pins, 59.60.61, vs no-cap pins. (I have no R's or soldering iron on this station)
Expected to be ~ 38% slower again.
Your capture of Pin 56 ? maps to a rather high 125pF P2-Eval loading value. (sounds much higher than P2D2 would be )
Attached image shows the Spice Timing match for your 10k captures.
Yes, its only the 4 boot pins that are of interest P58-61.
Those 4 will not be the same, as Pins 59.60.61 show additional added loading C of 47pF, on the P2-Eval.
Seems that is totally unnecessary, if the P2-Eval loading is already ~125pF ? (as indicated by P56,P58 ?)
Addit: Pin61 looks to be the worst trace, length wise. Pin59,Pin60 are shorter and roughly equal paths.
@VonSzarvas
Many thanks for doing this. Nothing looks amiss here. I'll look at the timing either tonight or over the w/e to ensure my software meets the timing shown. 22K is fine. BTW I was using P2D2 so the extra caps were not present in my tests.
@jmg
Shouldn't the 10k be across the capacitance, not in series, and this will be for the external parts. Then the internal will be a small 22R? in series with some small capacitance, which would be across that. ???
Chip,
I've noticed what seems to be a hub like timing to the event generation of COGATN/WAITATN. I haven't come up with another explanation ... although COGATN execution doesn't stall like other hub types do.
I wouldn't have thought it needed such arbitration. I was expecting something as simple as an OR function, like what OUT uses.
Chip,
I've noticed what seems to be a hub like timing to the event generation of COGATN/WAITATN. I haven't come up with another explanation ... although COGATN execution doesn't stall like other hub types do.
I wouldn't have thought it needed such arbitration. I was expecting something as simple as an OR function, like what OUT uses.
Have I got this wrong?
There's no hub timing relationship. It is an OR function. What are you seeing?
Hmm, you've prompted me to try cleaning up the code, namely clean out all the lutRAM sharing parts, and funnily the artefact has gone away. I'll see if I can identify if it was just a bug ...
I found the culprit finally - COGID. I had assumed it was a 2-clock instruction. So a bug, yes. It was added for the testing of coinciding lutRAM writes, just yesterday.
I found the culprit finally - COGID. I had assumed it was a 2-clock instruction. So a bug, yes. It was added for the testing of coinciding lutRAM writes, just yesterday.
Hehe, it does have that feel of chasing after each distant yelp coming from yonder on the beach.
I remember back when I first joined the forums and was reading old posts of others finding the latest discoveries on the Prop1. I so wanted to do that. I guess I've got there for the Prop2.
Ok, cogid is hub instruction. A little strange that a cog has to ask which one it is...
But, it's not like you'd be using this instruction very often...
Having deja vu… Sure this came up in P1 thread before...
I guess if the cogs are truly identical, then it has to be this way... Or, does it?
It could have easily been made into a 2-clock instruction, but it's a little more economical to keep it in the hub. Its implementation is mainly a carryover from the first Propeller chip.
Comments
If only I had a scope!
Pulldown on P58
<insert SD card, FAT32, file content?> ?
<run code> ?
Trigger on P58 ?
Also, bearing in mind P2-EVAL has 47pF on that pin... do you want that removed or reduced first?
I think P2D2 had 10-12pf there, but I don't have one of those to test.
Just use another close pin such as P56 ( dont think anything is on this pin).
Place a pulldown and do this for the 3 values ie 3 traces
Trigger on the pin
Run a simple program to
DRVH #56 ‘trigger here on high
WAITX #30
FLTH #56
JMP #$
Repeat the above with pullups ie 3 traces using the program
DRVL #56. ‘trigger here on low
WAITX #30
FLTL #56
JMP #$
This would be fantastic thanks. I know this wouldbe slightly different with an sd card present but will be good enough to see what is happening.
Ray
http://forums.parallax.com/discussion/comment/1447922/#Comment_1447922
However most of the time we were looking at the jtag pins. I take it you are primarily interested in the boot select pins.
Note from those previous captures, the depth of the negative going pulse varies by pin (perhaps, hypothetically, by jtag loading?).
Also I am not sure where the switching threshold is on the P2. On the P1 it was somewhere around 1.42v, ie its not simply vcc/2.
Because i found a problem, i want to understand the timing because it could potentially affect the ROM Boot code.
From the trace i should be able to ensure i read in the correct eindow. The small hysterisis where the chip sees the change should not matter if ive chosen the timing correctly.
Is this the right setup for the detail you need?
I'll install the scope software on this PC, then grab the rest right now.
dat org ' set up clock hubset ##%1_000000_0000001100_1111_10_00 'enable crystal+PLL, stay in 20MHz+ mode waitx ##20_000_000/100 'wait ~10ms for crystal+PLL to stabilize 'hubset ##%1_000000_0000001100_1111_10_11 'now switch to PLL loop DRVH #56 'trigger here on high WAITX #30 FLTH #56 WAITX #30 jmp #loopdat org ' set up clock hubset ##%1_000000_0000001100_1111_10_00 'enable crystal+PLL, stay in 20MHz+ mode waitx ##20_000_000/100 'wait ~10ms for crystal+PLL to stabilize 'hubset ##%1_000000_0000001100_1111_10_11 'now switch to PLL loop DRVH #56 'trigger here on high WAITX #15 FLTH #56 WAITX #45 jmp #loop4K7, 10K and 22K.
Is 15K crucial ? Could construct the value....
Edit:
Scope results the same for P58, except that with 22K the pulse frequency starts to vary slightly as the cap influences.
Freq. was locked on 320 KHz for all except P58 22K, which rolls ~312 to 320 KHz.
There is no need to do more than a single capture, as from there you can derive the PCB capacitance, either from formula, or from Spice.
Note: SCH shows C108.C109.C110 of 47pF added to Pins 59.60.61, plus I think a few traces run much further than others. ( I think P56 is not one ?)
It would be interesting to see separate captures for CAP added pins, 59.60.61, vs no-cap pins. (I have no R's or soldering iron on this station)
Expected to be ~ 38% slower again.
Your capture of Pin 56 ? maps to a rather high 125pF P2-Eval loading value. (sounds much higher than P2D2 would be )
Attached image shows the Spice Timing match for your 10k captures.
Those 4 will not be the same, as Pins 59.60.61 show additional added loading C of 47pF, on the P2-Eval.
Seems that is totally unnecessary, if the P2-Eval loading is already ~125pF ? (as indicated by P56,P58 ?)
Addit: Pin61 looks to be the worst trace, length wise. Pin59,Pin60 are shorter and roughly equal paths.
Screen caps show x1 probe mode, could you repeat a test at x10 @VonSzarvas and see if that 125pF drops?
And an extra P56 at x10
Try again...
re-run the spice gives ~54pf (includes scope CL)
So expect Pin61 to be about 2x that ?
Many thanks for doing this. Nothing looks amiss here. I'll look at the timing either tonight or over the w/e to ensure my software meets the timing shown. 22K is fine. BTW I was using P2D2 so the extra caps were not present in my tests.
@jmg
Shouldn't the 10k be across the capacitance, not in series, and this will be for the external parts. Then the internal will be a small 22R? in series with some small capacitance, which would be across that. ???
Here you go, 10k across the cap.
Notice the risetimes are identical, as the RC time constant is what matters here.
I've noticed what seems to be a hub like timing to the event generation of COGATN/WAITATN. I haven't come up with another explanation ... although COGATN execution doesn't stall like other hub types do.
I wouldn't have thought it needed such arbitration. I was expecting something as simple as an OR function, like what OUT uses.
Have I got this wrong?
There's no hub timing relationship. It is an OR function. What are you seeing?
Thanks for the info, btw.
I found the culprit finally - COGID. I had assumed it was a 2-clock instruction. So a bug, yes. It was added for the testing of coinciding lutRAM writes, just yesterday.
It's a hub instruction.
I'm glad you're turning every rock over.
I remember back when I first joined the forums and was reading old posts of others finding the latest discoveries on the Prop1. I so wanted to do that. I guess I've got there for the Prop2.
But, it's not like you'd be using this instruction very often...
Having deja vu… Sure this came up in P1 thread before...
It could have easily been made into a 2-clock instruction, but it's a little more economical to keep it in the hub. Its implementation is mainly a carryover from the first Propeller chip.