Re: Si5351 breakout solution - that's a really nice I2C programmable clock chip. I've ordered the board and connectors. ...
So, I'll be able to try an external clock solution some time next week.
This clock source move will need a rebuild for P2, (or P1V) and on the A7 board it is maybe possible the P1 on there could manage i2c to Si5351 for you ?
I think an external CLK-in will differ again from the CLKOSC change, so it may be best to avoid too many builds...
A Si5351 is good to 200Mhz and is fully variable.
The other way to go is use a programmable osc that fits the existing 5x7mm footprint the 50 MHz oscillator uses. All you'd have to do is connect the (C1D or data) pin to the P8x32A, and/or fpga.
The Si570/71 would let you do this via i2c, but they're hard to get and expensive. Perhaps there's another option
All you'd have to do is connect the (C1D or data) pin to the P8x32A, and/or fpga.
The Si570/71 would let you do this via i2c, but they're hard to get and expensive. Perhaps there's another option
Si5351(i2c) is a lot cheaper than Si570, and the Si504(C1D) is nice, but now EOL
i2c is also more common, than C1D, and likely easiest to drop into P1.
The test program continues to run but no change in the pattern on the ws2812.
I recall some comments about the WS2812s possibly not being good on these boards - didn't survive the baking process. Is there a better test for proper PLL operation that doesn't rely on the WS2812s?
Rick
As a test to determine if my WS2812's are flaky because of the PLL issue or a possible reflow issue I threw together a simple test program that basically feeds through a real rgb signal from a real P1.
Result is 3 dead leds, 1 with no green. Same result as a P1V.
So it appears my issue is a reflow one and not a PLL one like Tubular's board.
I'm curious what result you get.
Cheers
Brian
The test program continues to run but no change in the pattern on the ws2812.
I recall some comments about the WS2812s possibly not being good on these boards - didn't survive the baking process. Is there a better test for proper PLL operation that doesn't rely on the WS2812s?
Rick
As a test to determine if my WS2812's are flaky because of the PLL issue or a possible reflow issue I threw together a simple test program that basically feeds through a real rgb signal from a real P1.
Result is 3 dead leds, 1 with no green. Same result as a P1V.
So it appears my issue is a reflow one and not a PLL one like Tubular's board.
I'm curious what result you get.
Cheers
Brian
You probably realize this, but you can always use the clock_50 signal, directly, as your system clock. No question about that thing working. Uh, let's hope not, anyway.
I'm sorry that we didn't realize those RGB LEDs were toast. I wonder if they came from some really cheap source, because everything else seemed to survive reflow.
Hi Chip
I started down that road and made a P1V with no PLL but with a 25MHz clock the timing blows out with 16040nS instruction cycles. Also found the P1V erratic loading spin/PASM code to RAM?
Oz, it is easy to replace those LED's by hand. I recommend putting a scope on the data in and data out of each LED and see if you are getting anything. If data does not pass through one is then the others downstream will not work.
On my one the right-most led is the one that doesn't seem to show green, but I think its a soft issue as I've seen something similar driving ordinary led strips. I've got an alternative pasm driver to try
Oz, it is easy to replace those LED's by hand. I recommend putting a scope on the data in and data out of each LED and see if you are getting anything. If data does not pass through one is then the others downstream will not work.
TChap
Thanks for the tip.
Three things are required to succeed with that surgical operation.
A steady hand, good vision and the parts at hand.
Sadly I fail on all three currently.
I think an appointment to seeDoctor Tubular is required.
I have tried a 603 and can't cram it in far enough... I sure would like to find a mechanical drawing of the ball grid layout in context of final package.
BUT I'm wondering about this PLL business. I wonder if it is the problem and if it is the only problem.
I have installed a "heart beat" function into my P1V .... as provided by Jac
In the p123.v file...
wire resn;
assign resn = fpga_resn;
reg [24:0] blinkcount;
reg blink;
always @(posedge clock_50)
begin
blinkcount <= blinkcount + 1;
if (blinkcount == 25'd25000000)
begin
blinkcount <= 0;
blink <= ~blink;
end;
end
// replace the line: assign led[7:0] = ~cogled[8:1]; // lit when COG is inactive
//
// The LEDs are on when set to 0, so we reverse the cog led outputs here
// 1-2-3-FPGA has 16 user LEDs - default is to use 0-7 to indicate active
// and 8-15 to indicate inactive COG
//
wire[8:1] cogled;
assign led[7:0] = ~(blink ? cogled[8:1] : 8'b0); // blink when COG is inactive
//assign led[7:0] = ~cogled[8:1]; // lit when COG is active
assign led[15:8] = cogled[8:1]; // lit when COG is inactive
This causes a one second blink cycle on active cogs. Works just fine. Issue here is that I get a good heartbeat on Cog0 before I get serial communications on my P123. So... if the problem is a PLL... why is my P1V cog blinking 10 times in 10 seconds? But Proptool can't find my P1V?
The test program continues to run but no change in the pattern on the ws2812.
I recall some comments about the WS2812s possibly not being good on these boards - didn't survive the baking process. Is there a better test for proper PLL operation that doesn't rely on the WS2812s?
Rick
As a test to determine if my WS2812's are flaky because of the PLL issue or a possible reflow issue I threw together a simple test program that basically feeds through a real rgb signal from a real P1.
Result is 3 dead leds, 1 with no green. Same result as a P1V.
So it appears my issue is a reflow one and not a PLL one like Tubular's board.
I'm curious what result you get.
Cheers
Brian
Brian,
Thank you for the test programs. After running those, I see the same WS2812 blink pattern with a Quickstart driving the RGB LED string as I do with the P1V running on the 1-2-3 FPGA.
Conclusion #1: I have bad WS2812s on my 1-2-3 FPGA board, so they are not a good indicator for any PLL fix testing.
Conclusion #2: I probably have a PLL issue but it's non-conclusive!
Is there a good test for the PLL problem that I can run to see if any of my poking and prodding of my a1 ball results in a good connection to fix the PLL problem? Let's assume I don't have an oscilloscope - since I don't. I suppose I could string together some discrete WS2812 (I may only have 2811's but it should work) and once I prove I can drive those with a real P1, I can play with driving them from a P1V.
This isn't the type of testing I envisioned when I plunked down money for the A7 version of the 1-2-3- FPGA board!
Probably the best way to do it is to load a program to the P1V to generate a 1MHz signal (synth.spin) on one of the pins and then monitor that signal with a real P1.
Once switched off, my P123 board takes a variable amount of time(sometimes hours), but eventually comes to life and works just fine. I intentionally turned it off to test the heart beat function I described above. Then I turned it off again to see what using clock_160 would do to the heart beat and I'm still waiting. Using clock_160 shows no heart beat... now it is a matter of time before it comes back... still waiting. At that point I want to see the time relationship between the heart beat and serial function.
Materials...
1) Resistor 2K 1% 1/10W or 1/8W (very small style - lead needs to be small enough to slide between the FPGA and PCB)
2) Thin solder/flux
3) Optional heatshrink/spaghetti to slide over resistor
Instructions...
1) Trim one resistor lead to ~1/2" and tin this lead
2) Poke this resistor lead under the FPGA until it touches the ball
3) Heat this lead (closest to the resistor) with the soldering iron until it gets hot enough to solder to the ball.
4) Optionally slide the heatshrink/spaghetti over the resistor and leads, leaving a small part of the unsoldered resistor lead exposed
5) Solder the exposed resistor lead to a ground point on the PCB
What about hammering the end of the resistor lead to flatten it if it does not fit.
Otherwise, use some kynar wire, tin the end and push in and heat the wire as close to the FPGA as possible until it solders to the ball.
Then use the other end to solder to a resistor. Maybe do this first by wrapping this end of the kynar wire around the resistor lead.
FWIW I just tested kynar wire on my DE0 and it slides right under the FPGA nicely (way under between a number of balls). So this should work!
This isn't the type of testing I envisioned when I plunked down money for the A7 version of the 1-2-3- FPGA board!
I know. I am sorry about this. If you'd like, we can arrange for anyone who has one to send them back to us and we'll do the surgery at Parallax and send it right back to you. We'll also replace those RGB LED's. Anyone interested?
This isn't the type of testing I envisioned when I plunked down money for the A7 version of the 1-2-3- FPGA board!
I know. I am sorry about this. If you'd like, we can arrange for anyone who has one to send them back to us and we'll do the surgery at Parallax and send it right back to you. We'll also replace those RGB LED's. Anyone interested?
Rick, don't worry about it. We'll handle this problem the way you'd expect us to. Send the board back to my attention, we'll do surgery, send it back. We can also offer the future replacement -A9 at a low price.
Guess you're part of the Early Adopter Team (EAT!).
If you are going to redesign the boards you could add a test pad to insert a signal to test the LED's from a Prop1 without needing to load an image on the board.
This isn't the type of testing I envisioned when I plunked down money for the A7 version of the 1-2-3- FPGA board!
I know. I am sorry about this. If you'd like, we can arrange for anyone who has one to send them back to us and we'll do the surgery at Parallax and send it right back to you. We'll also replace those RGB LED's. Anyone interested?
Rick, don't worry about it. We'll handle this problem the way you'd expect us to. Send the board back to my attention, we'll do surgery, send it back. We can also offer the future replacement -A9 at a low price.
Guess you're part of the Early Adopter Team (EAT!).
Ken Gracey
What are you doing with the remaining A7 boards that you have in stock? Will you update those with the required resistor before selling them? Will they come with the same offer to upgrade them to the A9 board when it comes out?
If you are going to redesign the boards you could add a test pad to insert a signal to test the LED's from a Prop1 without needing to load an image on the board.
A single image can be loaded to test all IO,DAC's and led's in one hit.
A test pin for the RGB leds may conflict with the level shifter's output connected to the RGB leds.
Update:
"Doctor Tubular" replaced my WS2812's today and the patient has recovered nicely.
All leds working perfectly with no PLL timing issues evident.
Decided not to do the PLL modification as my board freakishly does not seem to need it.
So to confirm Ken, the leds on my board were faulty.
Thanks again Tubular
Just while on the WS2812's - the first led in the chain is in fact on the leftmost side, and is labelled "RGB3". The data signal propagates left to right.
On my board the first 3 WS2812's were fine, but the fourth one seems to be missing green. If I look through the clear window at the top I can see a spill of cloudy/milky material, probably some melted plastic, that the other working leds don't have.
Comments
I don't see A1 anywhere, either, on the schematic:
http://components-asiapac.arrow.com/file_system/intranet/MAR/ADRE/File/Hardware_Reference_Guide_for_BeMicro_CV_A2_v1.04.pdf
I wonder if it is floating.
That's the CV board, not the CV A9. The schematic for the CV A9 is here:
http://download.siliconexpert.com/pdfs/2014/9/2/0/44/44/276/arrowd_/manual/bemicrocv-a9_xb21.pdf
I think an external CLK-in will differ again from the CLKOSC change, so it may be best to avoid too many builds...
A Si5351 is good to 200Mhz and is fully variable.
The Si570/71 would let you do this via i2c, but they're hard to get and expensive. Perhaps there's another option
Si5351(i2c) is a lot cheaper than Si570, and the Si504(C1D) is nice, but now EOL
i2c is also more common, than C1D, and likely easiest to drop into P1.
Rick
As a test to determine if my WS2812's are flaky because of the PLL issue or a possible reflow issue I threw together a simple test program that basically feeds through a real rgb signal from a real P1.
Result is 3 dead leds, 1 with no green. Same result as a P1V.
So it appears my issue is a reflow one and not a PLL one like Tubular's board.
I'm curious what result you get.
Cheers
Brian
You probably realize this, but you can always use the clock_50 signal, directly, as your system clock. No question about that thing working. Uh, let's hope not, anyway.
I'm sorry that we didn't realize those RGB LEDs were toast. I wonder if they came from some really cheap source, because everything else seemed to survive reflow.
I started down that road and made a P1V with no PLL but with a 25MHz clock the timing blows out with 16040nS instruction cycles. Also found the P1V erratic loading spin/PASM code to RAM?
On my one the right-most led is the one that doesn't seem to show green, but I think its a soft issue as I've seen something similar driving ordinary led strips. I've got an alternative pasm driver to try
Thanks for the tip.
Three things are required to succeed with that surgical operation.
A steady hand, good vision and the parts at hand.
Sadly I fail on all three currently.
I think an appointment to see Doctor Tubular is required.
BUT I'm wondering about this PLL business. I wonder if it is the problem and if it is the only problem.
I have installed a "heart beat" function into my P1V .... as provided by Jac
In the p123.v file...
wire resn; assign resn = fpga_resn; reg [24:0] blinkcount; reg blink; always @(posedge clock_50) begin blinkcount <= blinkcount + 1; if (blinkcount == 25'd25000000) begin blinkcount <= 0; blink <= ~blink; end; end // replace the line: assign led[7:0] = ~cogled[8:1]; // lit when COG is inactive // // The LEDs are on when set to 0, so we reverse the cog led outputs here // 1-2-3-FPGA has 16 user LEDs - default is to use 0-7 to indicate active // and 8-15 to indicate inactive COG // wire[8:1] cogled; assign led[7:0] = ~(blink ? cogled[8:1] : 8'b0); // blink when COG is inactive //assign led[7:0] = ~cogled[8:1]; // lit when COG is active assign led[15:8] = cogled[8:1]; // lit when COG is inactiveThis causes a one second blink cycle on active cogs. Works just fine. Issue here is that I get a good heartbeat on Cog0 before I get serial communications on my P123. So... if the problem is a PLL... why is my P1V cog blinking 10 times in 10 seconds? But Proptool can't find my P1V?
So, how would I fix that?
We need to send a team of small guys with jackhammers and welders into that recess. And give them one 0402 resistor to install. Problem solved.
But I'm sticking to my guns on that new P1V reset issue I wrote about...
And I'm worried that it will migrate itself into the P2... we will see soon!!
Thanks
Brian,
Thank you for the test programs. After running those, I see the same WS2812 blink pattern with a Quickstart driving the RGB LED string as I do with the P1V running on the 1-2-3 FPGA.
Conclusion #1: I have bad WS2812s on my 1-2-3 FPGA board, so they are not a good indicator for any PLL fix testing.
Conclusion #2: I probably have a PLL issue but it's non-conclusive!
Is there a good test for the PLL problem that I can run to see if any of my poking and prodding of my a1 ball results in a good connection to fix the PLL problem? Let's assume I don't have an oscilloscope - since I don't. I suppose I could string together some discrete WS2812 (I may only have 2811's but it should work) and once I prove I can drive those with a real P1, I can play with driving them from a P1V.
This isn't the type of testing I envisioned when I plunked down money for the A7 version of the 1-2-3- FPGA board!
Life is like a box of chocolates.
Probably the best way to do it is to load a program to the P1V to generate a 1MHz signal (synth.spin) on one of the pins and then monitor that signal with a real P1.
Once switched off, my P123 board takes a variable amount of time(sometimes hours), but eventually comes to life and works just fine. I intentionally turned it off to test the heart beat function I described above. Then I turned it off again to see what using clock_160 would do to the heart beat and I'm still waiting. Using clock_160 shows no heart beat... now it is a matter of time before it comes back... still waiting. At that point I want to see the time relationship between the heart beat and serial function.
Rich
Otherwise, use some kynar wire, tin the end and push in and heat the wire as close to the FPGA as possible until it solders to the ball.
Then use the other end to solder to a resistor. Maybe do this first by wrapping this end of the kynar wire around the resistor lead.
FWIW I just tested kynar wire on my DE0 and it slides right under the FPGA nicely (way under between a number of balls). So this should work!
Just some suggestions that may work.
I know. I am sorry about this. If you'd like, we can arrange for anyone who has one to send them back to us and we'll do the surgery at Parallax and send it right back to you. We'll also replace those RGB LED's. Anyone interested?
Rick, don't worry about it. We'll handle this problem the way you'd expect us to. Send the board back to my attention, we'll do surgery, send it back. We can also offer the future replacement -A9 at a low price.
Guess you're part of the Early Adopter Team (EAT!).
Ken Gracey
A test pin for the RGB leds may conflict with the level shifter's output connected to the RGB leds.
"Doctor Tubular" replaced my WS2812's today and the patient has recovered nicely.
All leds working perfectly with no PLL timing issues evident.
Decided not to do the PLL modification as my board freakishly does not seem to need it.
So to confirm Ken, the leds on my board were faulty.
Thanks again Tubular
Just while on the WS2812's - the first led in the chain is in fact on the leftmost side, and is labelled "RGB3". The data signal propagates left to right.
On my board the first 3 WS2812's were fine, but the fourth one seems to be missing green. If I look through the clear window at the top I can see a spill of cloudy/milky material, probably some melted plastic, that the other working leds don't have.