ashcloud
-- BANNED! -- Lactose Intolerant Volcano
Congratulations! You finally understood the issue. That's exactly what the blocking capacitors are for.
Congratulations! You finally understood the issue. That's exactly what the blocking capacitors are for.
I've managed to fry an µC with RF imission (30V/m (3x industrial limit)) once. That moment when you hold a measuring tape with λ/2 instead of cm or inchWhat if a trace or power plane catches the 1.5Ghz RF signal like an antenna?
If GND "swings" at an offset to PE, that should not be a problem for the CPU itself, since other traces should then just have the same offset to PE (on multi-layer). Assuming the DC/DC blocks noise from supply lines, the relevant distance is from the DC/DC converter to the CPU (you can apply noise between VCC and GND only there).Quarter-wave of 1.5Ghz is 5cm. The space between the CPU board connectors looks close to that size.
This would be more like cross-talk, which normally only affects high-impedance non-burried traces. So you'd probably see random SD/SPI/I²C errors before any cpu crash.The CPU might be blasting it's 1.5Ghz clock signal into the main board
(Assuming we are still talking about VCC,) the caps are way to big to get a (high-Q) resonator at GHz (or MHz). Besides that, the caps were already changed which would have shifted the frequency.resonate with something, like an accidental LC circuit
Who knows? We applied a lot of fixes, but as mentioned, they cannot be tested with this CPU Board, we need to produce more prototypes of those.Still no progress then?
Does the OMAP5 DEV board also has this issues?
The board works perfectly fine with 1,5GHz, if you only use ONE CPU.
(Assuming we are still talking about VCC,) the caps are way to big to get a (high-Q) resonator at GHz (or MHz). Besides that, the caps were already changed which would have shifted the frequency.
This would be more like cross-talk, which normally only affects high-impedance non-burried traces. So you'd probably see random SD/SPI/I²C errors before any cpu crash.
Is there a remote possibility that it's the OMAP5 themselves? Like they're lower quality that simply can't function at the advertised rate because they're "pre-production" units or whatever you'd call them when they ship you parts to use in prototypes?
Usually parts sent for prototyping/sampling are the better ones so you don't have an issue and think their chips are worthless.
"1st impressions" and all that.
Im sure that I missed this, but when will the new CPU boards happen?
Not sure if I've missed something, but has the 1.5ghz issue not been fixed? Or does need new PCBs/cpuboards to test?No, often samples are being taken from the first production run, which is often a prototype revision.
That's what's on the Classic Pandoras as well
However, our current boards have the latest production revision, so it's not that.
Probably soon. One production run costs about 10k EUR and takes 6 weeks, so we should do anything but RUSH it.
That's why we're doing multiple tests and are improving the general layout (adding more vias, etc.), to make sure to improve it as good as possible.
Adding more vias reduces the noise in the ground plane, so that could VERY much cause exact such issue.
But there are some other ideas worth checking. We're hurrying, but not rushing
Adding more vias reduces the noise in the ground plane, so that could VERY much cause exact such issue.
The issue has not be "fixed", some possible causes were identified and a new round of boards are being produced. They won't know if one of the things that were changed will fix the issue until the new boards are complete and tested.Not sure if I've missed something, but has the 1.5ghz issue not been fixed?
Ah righto, thanks!The issue has not be "fixed", some possible causes were identified and a new round of boards are being produced. They won't know if one of the things that were changed will fix the issue until the new boards are complete and tested.