It might be nice to have the FlexProp header on the P2 Edge card as well. The chip's going to need programming one way or another... Even if the header is enormous compared to everything else in there.
Never mind - it does have that already. My bad. S.
The P2 Edge module has the pads on the back for PropPlug (or similar) programming.
Options include soldering on a header that accepts the PropPlug and 5V/GND,
or adding pogo pins to a PropPlug, and pressing that against the back of the P2 Edge PCB whilst programming.
Are you thinking of a different type of connector ?
It works by generating lots of transitions on P28-31 that triggers massive P2 PLL jitter when the PLL is not setup as simple multiples of 10, 20MHz etc, some rates are better than others. If you are running video you will see a lot of distortion in your output or the monitor may not even sync.
Kills video when operating at 252MHz, 297MHz, 325MHz etc on a few P2-EVAL boards I tried. No permanent damage I've seen, it just affects the output during these noisy high speed transitions. When these stop the system recovers.
I found other operating P2 frequencies of 20, 40,..., 200MHz and 240MHz etc were immune from the problem. The PLL seems less sensitive there for some of these simpler multipliers. It would be good to identify all the "safe" frequencies. You can also monitor for jitter and observe it directly with a pin in NCO output mode hooked to a scope too. The signal jumps all over the place once it is triggered.
This problem was discovered yesterday when I was putting together a PSRAM memory driver using these pins and observed video distortion, then today Tubular, ozpropdev and I got together and finally narrowed it down to high frequencies on these pins triggering noise into the PLL of the chip because it shares the same VIO supply pin for this nibble. So it's best to avoid using these particular pins for high frequencies if you want a stable PLL.
Roger,
Do you have a complete demo of this issue?
Does the problem only occur with HDMI, or DVI?
Does it fail with VGA?
And what resolutions?
Cluso,
Here's my testing program. There's no video out since the video issues are only a symptom, instead it produces a square-wave on pin 0 for an oscilloscope to monitor. I edit and comment out various lines to change the config for different tests.
EDIT: Doh! Added listing:
It fails with analog VGA, it might not fail with HDMI if the clock jitter is within spec, haven't actually tried that. But I would doubt it meets the spec, jitter looks pretty severe.
You can take this binary as a demo, fit the A/V board in P0-P7, leave P28-P31 free, and see if it syncs on your monitor. It should show Chip's 720x400 Mario image from HUB RAM in a 1024x768 mode for several seconds then I add the P28-P31 activity for about 8 seconds and repeat this process, to demonstrate it periodically suffering from the nasty jitter. It typically fails for most P2 frequencies that are not simple multiples of 20MHz, though there are exceptions to that generalization. E.g. 252, 297, 325MHz all fail while 200, 240MHz are okay.
Check it out...this one runs at 325MHz.
Update: Yes the HDMI output gets affected too - my Dell monitor always drops out whenever the P28-31 noise is present.
EDIT: this attached zip file has a second binary already in it left over from something else by mistake, ignore that and run the video.binary one.
It does depend on what the PLL parameters are as to how sever the jitter becomes. %D divide by 3 makes it really bad. Seems to be bad ranges similar to the old revA silicon. Eg:
Interestingly, using OUTNOT instead of OUTRND I can refine it a little further. There is no problem if driving two pins inverted from the other two. It can even be 28 and 29 one polarity with 30 and 31 the other polarity.
PS: I bumped into this because I tried to use %TT = %10 for generating the random data at full sysclock, but the interference all vanished. Then I realised the odd pins are inverted from the random on the even pins.
@evanh said:
In fact, any two of those four pins is enough.
Interestingly, using OUTNOT instead of OUTRND I can refine it a little further. There is no problem if driving two pins inverted from the other two. It can even be 28 and 29 one polarity with 30 and 31 the other polarity.
Interesting, that suggests it is inductive supply bounce effects, rather than pin C crosstalk.
Pin C crosstalk would strongly favour the nearest pin. If that nearest pin was driven static, it should reduce the effect from next pin over.
Another idea, that doesn't conflicts with the series inductor present at each pin, represented by the gold wire that connects each metal pad to its inner soldering point, at the pad ring:
Isn't it due the fact that, by simultaneously switching a pair of pins to the same polarity, while the other two are reversed, you are balancing the current flow level at both Vio/Gio nodes?
Perhaps you could test it, by selecting differing (unmatching) values among the eight possibilities.
P.S. Amkor states that any pads near the center of the sides would have a loop inductance of 2.57nH, while the ones at the corners would have 3.32nH.
@Yanomani said:
Isn't it due the fact that, by simultaneously switching a pair of pins to the same polarity, while the other two are reversed, you are balancing the current flow level at both Vio/Gio nodes?
The current is mainly cap charge/discharge.
One this differential drive does, is the ripple frequency doubles, as every edge gives a Vcc spike, and every edge gives a gnd spike. That may be enough to improve things.
For reference (based on Amkor's datasheet), P2 uses the package at page 8, whose cross-section is depicted at the second (center) figure, to the right of the page.
@evanh said:
It will be very interesting to see if an external oscillator fixes it.
I think in #15 Chip said If you feed an external 20MHz into XI, the problem goes away. ie I took that as a CMOS signal.
I'm curious if an AC coupled clipped sine external oscillator is same/worse/better/between ?
Unfortunatelly XI and XO are located at the corners, where the loop inductance is at its maximum.
I'm not sure about the divider/multiplier rates used, to get those three frequencies (252, 297 and 325MHz), but crystal-based circuits tend to be very peeky, if the biasing of the driving inverter experiences some wild transitions.
Divisions by prime numbers (other than two) would tend to group upper odd harmonics deleterious effects, that, when added to the innescapable buffer delays, will mess exactly with the resulting waveform slew rate.
JMG,
I didn't think he'd actually tested it. He would have had to remove the crystal and what, feed a shielded cable from 20 MHz generator ... maybe he has.
One thing that was noticed across a sample of 5 or 6 boards was that the number and order of pins required to cause the effect varied, but all included P31.
Some were impacted by 31 + 1 other pin between 28 an 30. Others needed 2 other pins. One board needed all 4 pins driven. The pins didn't need to be consecutive, the total was what mattered.
XI was injected with 20MHz from a func gen at +-10v, coupled to XI by 56pF.
As with any square-wave signal, the 5th harmonics (100 MHz, at the present case) would be the main responsible, in determining the waveform slew-rate.
IMHO, the following three (short) articles could help @VonSzarvas, into the design process of stuffing an HCMOS clock oscillator at the revised pcbs (but the prospective audience is not limited to himself):
@rogloh said:
It fails with analog VGA, it might not fail with HDMI if the clock jitter is within spec, haven't actually tried that. But I would doubt it meets the spec, jitter looks pretty severe.
You can take this binary as a demo, fit the A/V board in P0-P7, leave P28-P31 free, and see if it syncs on your monitor. It should show Chip's 720x400 Mario image from HUB RAM in a 1024x768 mode for several seconds then I add the P28-P31 activity for about 8 seconds and repeat this process, to demonstrate it periodically suffering from the nasty jitter. It typically fails for most P2 frequencies that are not simple multiples of 20MHz, though there are exceptions to that generalization. E.g. 252, 297, 325MHz all fail while 200, 240MHz are okay.
Check it out...this one runs at 325MHz.
Update: Yes the HDMI output gets affected too - my Dell monitor always drops out whenever the P28-31 noise is present.
EDIT: this attached zip file has a second binary already in it left over from something else by mistake, ignore that and run the video.binary one.
I have very interesting results !!!
Presuming that everything is working as expected, I do not see any problems with my RetroBlade2. The video is rock stable on my Acer X233H 23" 1920x1080 monitor using the VGA input.
For the test, I needed to using an FT232RL with the reset circuit on the dongle (ie my version of a PropPlug) plus an extra transistor reset circuit which is enabled on my RetroBlade2, because the CP2102 and loadp2 (v520 or v531) combination will not load the video.binary even at 115200 baud. The binary is a very large 401KB file. I have jumpers from GND and P0-7 to the AV Breakout board to the VGA as my onboard VGA uses the pins P27-31.
When using the P2EVAL with the AV Breakout I see the two Mario images, which alternate between the bad jitter and stable pictures.
When using the P2EVAL with tubular's dual VGA with USB adapter I get a wierd green/blue version of Mario that alternates between jitter and stable versions. Sometimes the monitor loses sync until the next stable pic. The stable version has blurry streaks going to the right of Mario. It is as if I am missing the red but perhaps it is more than just this???
Both boards are being powered from my PC's USB.
My summation...
I have a problem with CP2102 and large files. Could be a loadp2 problem or a CP2102 problem.
IMHO, my RetroBlade2 design has proper bulk and bypass capacitors.
Interesting that you see no effect on your own board Cluso, so perhaps this becomes more of a board design issue than P2 XI input sensitivity directly. Do you have an oscillator or crystal on your board? Oscillators might be more resilient.
Not sure about the Tubular dual VGA board. I have one of those too, I should try to solder it up and try it. Maybe one of the pins is loose or a has a colour shorted somewhere to sync perhaps?
I did recently find a new bug in my video driver if you attempt to use port B pins with VGA. It think it wasn't setting the DAC pins 100% correctly. It's still present in the code, so until I update the code with a fix, don't use port B with my VGA driver for now. It appears that in the streamer commands you need to also setup the top ppp bit to enable port B output. I knew this would apply to parallel output but it wasn't clear it was needed for DAC output as well. DVI should be okay, I know I've had it working at P48-55 for example. But I'll need to revisit this as well as test the component and TV outputs on all port positions.
Actually I don't have the code handy anymore as it has already morphed into something else. Can't you run any of your own VGA stuff on it to test the pins?
I'm assuming that is the RetroBlade2. That's why it behaves okay. DAC drive on those pins is not strong enough to upset the crystal oscillator. It can't do both VGA output and bit-bash the oscillator testing on the same pins.
I'm assuming that is the RetroBlade2. That's why it behaves okay. DAC drive on those pins is not strong enough to upset the crystal oscillator. It can't do both VGA output and bit-bash the oscillator testing on the same pins.
No Evan. On the RetroBlade2 I put the VGA on to pins0+ as I was using Roger's binary. There is nothing (other than the VGA connector) soldered to the P2's P27-31 pins.
@rogloh said:
Interesting that you see no effect on your own board Cluso, so perhaps this becomes more of a board design issue than P2 XI input sensitivity directly. Do you have an oscillator or crystal on your board? Oscillators might be more resilient.
Not sure about the Tubular dual VGA board. I have one of those too, I should try to solder it up and try it. Maybe one of the pins is loose or a has a colour shorted somewhere to sync perhaps?
I did recently find a new bug in my video driver if you attempt to use port B pins with VGA. It think it wasn't setting the DAC pins 100% correctly. It's still present in the code, so until I update the code with a fix, don't use port B with my VGA driver for now. It appears that in the streamer commands you need to also setup the top ppp bit to enable port B output. I knew this would apply to parallel output but it wasn't clear it was needed for DAC output as well. DVI should be okay, I know I've had it working at P48-55 for example. But I'll need to revisit this as well as test the component and TV outputs on all port positions.
I have a 3225 20MHz Crystal, not an oscillator.
Re tubular's dual VGA, I suspect a bad connection.
I wanted to confirm using the same VGA code and picture. Once things start to change that introduces other variations into the mix. That's why the binary was good, but unfortunately without source it's not easy to try anything else.
Also, I'd like to see why CP2102 and LOADP2 fails together on large files.
@Cluso99 said:
No Evan. On the RetroBlade2 I put the VGA on to pins0+ as I was using Roger's binary. There is nothing (other than the VGA connector) soldered to the P2's P27-31 pins.
Yeah I reckon its most likely a loose connection, as we used that board to demo dual-screen to the MP people and it sure had red color working on both screens then
Might be a stroke of genius to put the VGA DACs on 27~31 and block out those pins from other uses
Ray that red pin is fairly easy to access if its a solder joint. P3 connects to the corner pin closest to the 'A2' text
Same for P11 down on the second connector
Hopefully a bit of reflow sorts it out. Or post it back we'll sort it out for you
Comments
It might be nice to have the FlexProp header on the P2 Edge card as well. The chip's going to need programming one way or another... Even if the header is enormous compared to everything else in there.
Never mind - it does have that already. My bad. S.
The P2 Edge module has the pads on the back for PropPlug (or similar) programming.
Options include soldering on a header that accepts the PropPlug and 5V/GND,
or adding pogo pins to a PropPlug, and pressing that against the back of the P2 Edge PCB whilst programming.
Are you thinking of a different type of connector ?
Roger,
Do you have a complete demo of this issue?
Does the problem only occur with HDMI, or DVI?
Does it fail with VGA?
And what resolutions?
Cluso,
Here's my testing program. There's no video out since the video issues are only a symptom, instead it produces a square-wave on pin 0 for an oscilloscope to monitor. I edit and comment out various lines to change the config for different tests.
EDIT: Doh! Added listing:
CON XTALFREQ = 20_000_000 'PLL stage 0: crystal frequency XDIV = 2 'PLL stage 1: crystal divider (1..64) XMUL = 24 'PLL stage 2: crystal / div * mul (1..1024) XDIVP = 2 'PLL stage 3: crystal / div * mul / divp (1,2,4,6..30) ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss ' enable oscillator XOSC = %10 ' OSC ' %00=OFF, %01=OSC, %10=15pF, %11=30pF XSEL = %11 ' XI+PLL ' %00=rcfast(20+MHz), %01=rcslow(~20KHz), %10=XI(5ms), %11=XI+PLL(10ms) XPPPP = ((XDIVP>>1) + 15) & $F ' 1->15, 2->0, 4->1, 6->2...30->14 CLK_MODE = 1<<24 | (XDIV-1)<<18 | (XMUL-1)<<8 | XPPPP<<4 | XOSC<<2 ' CLK_MODE = XOSC<<2 pllpins = 28 | 3<<6 freqpin = 0 DAT 'not Spin code ORG 0 'longword addressing at 0 hubset ##CLK_MODE waitx ##25_000_000 / 100 hubset ##CLK_MODE | XSEL fltl #freqpin wrpin #P_NCO_FREQ | P_OE, #freqpin wxpin #50, #freqpin wypin ##$8000_0000, #freqpin dirh #freqpin ' wrpin ##P_HIGH_1K5 | P_LOW_1K5, #pllpins dirh #pllpins rep #1, #0 outrnd #pllpins jmp #$It fails with analog VGA, it might not fail with HDMI if the clock jitter is within spec, haven't actually tried that. But I would doubt it meets the spec, jitter looks pretty severe.
You can take this binary as a demo, fit the A/V board in P0-P7, leave P28-P31 free, and see if it syncs on your monitor. It should show Chip's 720x400 Mario image from HUB RAM in a 1024x768 mode for several seconds then I add the P28-P31 activity for about 8 seconds and repeat this process, to demonstrate it periodically suffering from the nasty jitter. It typically fails for most P2 frequencies that are not simple multiples of 20MHz, though there are exceptions to that generalization. E.g. 252, 297, 325MHz all fail while 200, 240MHz are okay.
Check it out...this one runs at 325MHz.
Update: Yes the HDMI output gets affected too - my Dell monitor always drops out whenever the P28-31 noise is present.
EDIT: this attached zip file has a second binary already in it left over from something else by mistake, ignore that and run the video.binary one.
It does depend on what the PLL parameters are as to how sever the jitter becomes. %D divide by 3 makes it really bad. Seems to be bad ranges similar to the old revA silicon. Eg:
XDIV = 3 'PLL stage 1: crystal divider (1..64) XMUL = 23 'PLL stage 2: crystal / div * mul (1..1024)In fact, any two of those four pins is enough.
Interestingly, using OUTNOT instead of OUTRND I can refine it a little further. There is no problem if driving two pins inverted from the other two. It can even be 28 and 29 one polarity with 30 and 31 the other polarity.
PS: I bumped into this because I tried to use %TT = %10 for generating the random data at full sysclock, but the interference all vanished. Then I realised the odd pins are inverted from the random on the even pins.
Interesting, that suggests it is inductive supply bounce effects, rather than pin C crosstalk.
Pin C crosstalk would strongly favour the nearest pin. If that nearest pin was driven static, it should reduce the effect from next pin over.
Another idea, that doesn't conflicts with the series inductor present at each pin, represented by the gold wire that connects each metal pad to its inner soldering point, at the pad ring:
Isn't it due the fact that, by simultaneously switching a pair of pins to the same polarity, while the other two are reversed, you are balancing the current flow level at both Vio/Gio nodes?
Perhaps you could test it, by selecting differing (unmatching) values among the eight possibilities.
P.S. Amkor states that any pads near the center of the sides would have a loop inductance of 2.57nH, while the ones at the corners would have 3.32nH.
The current is mainly cap charge/discharge.
One this differential drive does, is the ripple frequency doubles, as every edge gives a Vcc spike, and every edge gives a gnd spike. That may be enough to improve things.
For reference (based on Amkor's datasheet), P2 uses the package at page 8, whose cross-section is depicted at the second (center) figure, to the right of the page.
222.122.118.111/datasheet/4-LeadFrame.pdf
It will be very interesting to see if an external oscillator fixes it.
I think in #15 Chip said If you feed an external 20MHz into XI, the problem goes away. ie I took that as a CMOS signal.
I'm curious if an AC coupled clipped sine external oscillator is same/worse/better/between ?
Perhaps it'll be (almost certainly, to be true).
Unfortunatelly XI and XO are located at the corners, where the loop inductance is at its maximum.
I'm not sure about the divider/multiplier rates used, to get those three frequencies (252, 297 and 325MHz), but crystal-based circuits tend to be very peeky, if the biasing of the driving inverter experiences some wild transitions.
Divisions by prime numbers (other than two) would tend to group upper odd harmonics deleterious effects, that, when added to the innescapable buffer delays, will mess exactly with the resulting waveform slew rate.
JMG,
I didn't think he'd actually tested it. He would have had to remove the crystal and what, feed a shielded cable from 20 MHz generator ... maybe he has.
One thing that was noticed across a sample of 5 or 6 boards was that the number and order of pins required to cause the effect varied, but all included P31.
Some were impacted by 31 + 1 other pin between 28 an 30. Others needed 2 other pins. One board needed all 4 pins driven. The pins didn't need to be consecutive, the total was what mattered.
XI was injected with 20MHz from a func gen at +-10v, coupled to XI by 56pF.
Cool. That's quite the volts. How to know the level needed?
3.3v level usually. The 10v was just for testing to punch the signal over a longer cable and ensure nice sharp fast edges.
Oh, so slamming the capacitor against the protection diodes.
As with any square-wave signal, the 5th harmonics (100 MHz, at the present case) would be the main responsible, in determining the waveform slew-rate.
IMHO, the following three (short) articles could help @VonSzarvas, into the design process of stuffing an HCMOS clock oscillator at the revised pcbs (but the prospective audience is not limited to himself):
https://jauch.com/downloadfile/5fdb142fc53b4a351124ad046a864d5ec/source_impedance_termination_hcmos_xos_20201127.pdf
https://edn.com/rule-of-thumb-3-signal-speed-on-an-interconnect/
https://vishay.com/docs/60107/freqresp.pdf
Hope it helps.
Henrique
I have very interesting results !!!
Presuming that everything is working as expected, I do not see any problems with my RetroBlade2. The video is rock stable on my Acer X233H 23" 1920x1080 monitor using the VGA input.
For the test, I needed to using an FT232RL with the reset circuit on the dongle (ie my version of a PropPlug) plus an extra transistor reset circuit which is enabled on my RetroBlade2, because the CP2102 and loadp2 (v520 or v531) combination will not load the video.binary even at 115200 baud. The binary is a very large 401KB file. I have jumpers from GND and P0-7 to the AV Breakout board to the VGA as my onboard VGA uses the pins P27-31.
When using the P2EVAL with the AV Breakout I see the two Mario images, which alternate between the bad jitter and stable pictures.
When using the P2EVAL with tubular's dual VGA with USB adapter I get a wierd green/blue version of Mario that alternates between jitter and stable versions. Sometimes the monitor loses sync until the next stable pic. The stable version has blurry streaks going to the right of Mario. It is as if I am missing the red but perhaps it is more than just this???
Both boards are being powered from my PC's USB.
My summation...
Roger,
Are you able to confirm this please?
Interesting that you see no effect on your own board Cluso, so perhaps this becomes more of a board design issue than P2 XI input sensitivity directly. Do you have an oscillator or crystal on your board? Oscillators might be more resilient.
Not sure about the Tubular dual VGA board. I have one of those too, I should try to solder it up and try it. Maybe one of the pins is loose or a has a colour shorted somewhere to sync perhaps?
I did recently find a new bug in my video driver if you attempt to use port B pins with VGA. It think it wasn't setting the DAC pins 100% correctly. It's still present in the code, so until I update the code with a fix, don't use port B with my VGA driver for now. It appears that in the streamer commands you need to also setup the top ppp bit to enable port B output. I knew this would apply to parallel output but it wasn't clear it was needed for DAC output as well. DVI should be okay, I know I've had it working at P48-55 for example. But I'll need to revisit this as well as test the component and TV outputs on all port positions.
Roger,
can you post a binary using VGA on base 8 (or the source) so I can verify the dual VGA connector is just one side with a faulty red pin please?
Actually I don't have the code handy anymore as it has already morphed into something else. Can't you run any of your own VGA stuff on it to test the pins?
I'm assuming that is the RetroBlade2. That's why it behaves okay. DAC drive on those pins is not strong enough to upset the crystal oscillator. It can't do both VGA output and bit-bash the oscillator testing on the same pins.
No Evan. On the RetroBlade2 I put the VGA on to pins0+ as I was using Roger's binary. There is nothing (other than the VGA connector) soldered to the P2's P27-31 pins.
I have a 3225 20MHz Crystal, not an oscillator.
Re tubular's dual VGA, I suspect a bad connection.
I wanted to confirm using the same VGA code and picture. Once things start to change that introduces other variations into the mix. That's why the binary was good, but unfortunately without source it's not easy to try anything else.
Also, I'd like to see why CP2102 and LOADP2 fails together on large files.
Ah, ok, it seemed like that was the Eval Board.
Yeah I reckon its most likely a loose connection, as we used that board to demo dual-screen to the MP people and it sure had red color working on both screens then
Might be a stroke of genius to put the VGA DACs on 27~31 and block out those pins from other uses
Ray that red pin is fairly easy to access if its a solder joint. P3 connects to the corner pin closest to the 'A2' text
Same for P11 down on the second connector
Hopefully a bit of reflow sorts it out. Or post it back we'll sort it out for you