<lekernel>
roh, ok, then just please send the fucking previous design to the laser subcontractor ASAP, I have a feeling that shit will never get done if I want it to be perfect
<lekernel>
just make 80 (or whatever quantity wolfspraul ordered) of the previous design
<wolfspraul>
80, yes. but I'm sure roh is already on this.
<wolfspraul>
the engraving is a separate workstep, I don't think whether we do engraving or not will delay the making of cases themselves.
<lekernel>
we can engrave with the laser, but it looks complicated for roh, so leave it
<wolfspraul>
as for roh trying to find timeslots to work on this job (80 m1 cases) in parallel with other jobs, I fully understand that
<wolfspraul>
we have this situation with many of our vendors and partners, and I can be nothing but grateful about everybody trying to help and go the extra mile to make the m1 product in all its details a reality
<wolfspraul>
maybe roh can give us a revised deliver date soon, that'd be cool. with or without engraving (I am willing to pay extra for engraving).
<GitHub193>
[extras-m1] adamwang pushed 2 new commits to master: http://bit.ly/j2Ly3M
<GitHub193>
[extras-m1/master] 1, moved some silk screen texts to better view... - adamwang
<GitHub193>
[extras-m1/master] 1, generate drill with suppress leading zeros - adamwang
<GitHub174>
[flickernoise] sbourdeauducq pushed 1 new commit to master: http://bit.ly/lM9ruE
<GitHub174>
[flickernoise/master] Missing include - Sebastien Bourdeauducq
<lekernel>
Dear customer,
<lekernel>
Due to an unforeseen situation in our Support Team we are unable to support you for the ADV Video Products.
<lekernel>
WTF?
<lekernel>
they make crap silicon, and won't stand behind it
<wolfspraul>
that sounds unusual indeed, but at least honest
<wolfspraul>
maybe someone quit?
<lekernel>
I can definitely track down the video input "no more signal acquisition" problem to a silicon issue, unless we really messed up the M1 PCB
<wolfspraul>
how would we rule out the "really mseed up the m1 pcb" possibility?
<lekernel>
the chip won't respond to an I2C reset when the condition appears
<wolfspraul>
messed up
<lekernel>
the reset bit in the register, which the datasheet says should be always self-clearing and reset the chip no matter what, stays set and nothing happens
<wolfspraul>
ok how can we rule out a pcb problem?
<lekernel>
we went over that schematics many times already, and no one noticed any error
<lekernel>
and what could cause that?
<lekernel>
power supply issues?
<wolfspraul>
what kind of mistake could be consistent with what we see, i.e. that signal works, but sometimes when unplugging/replugging it goes into this state?
<lekernel>
incorrect power supply voltage or failing oscillator
<wolfspraul>
how would either of those be related to a unplug/replug event?
<wolfspraul>
the camera always works if it is connected at boot time, I think I never saw a problem there (didn't specifically stress-test it though)
<wolfspraul>
and if not at boot time, I believe it also always, or almost always, it detected on the first insertion
<wolfspraul>
the problem starts with the first unplugging from a running system, I believe
<wolfspraul>
at least from what I've seen so far, without exhaustive testing around this issue though
<lekernel>
circuit just at the brink of failing, and having to re-detect the signal triggers the complete bug
<lekernel>
that being said, if ADI's silicon is the same quality of their technical support, this might not be our fault
<wolfspraul>
it doesn't matter whose fault it is, for the user this is quite a nasty little problem
<wolfspraul>
basically we have to tell people to always plug their camera in before booting, and not unplug/replug in a running system
<lekernel>
there is a ugly workaround for that ultra-super-mega-pesky problem - detect the condition in the FPGA design, and make it reset that crap circuit when it happens
<lekernel>
maybe there's a symptom that is easy to spot, like the video clock stopping
<wolfspraul>
if you believe the circuit is not stable (voltage or oscillator?), how would we test that, or proove it, or fix it?
<wolfspraul>
I thought you said the ADV reset bit doesn't work anymore, so can we get it out of this state without a reboot at all?
<lekernel>
use an oscilloscope
<lekernel>
yes, but the chip still responds to a hard reset (not I2C, but with the pin)
<lekernel>
even though the datasheet says the two should have exactly the same action
<wolfspraul>
aw: have you seen this 'cannot detect camera signal' bug before?
<wolfspraul>
I think you can try this sequence: 1. boot your m1, without camera connected
<wolfspraul>
2. go to the video-in dialog
<wolfspraul>
3. plug in the running obk-2010cw, the signal should be detected and live preview comes up
<wolfspraul>
4. unplug camera
<wolfspraul>
5. replug camera
<aw>
wolfspraul, no, maybe i've not let m1 worked on too long time.
<wolfspraul>
aw: ok, try that sequence
<wolfspraul>
I'm trying here too...
<aw>
wolfspraul, surely, but have u met it?
<lekernel>
if you wait a bit between #4 and #5, the problem has more chances of appearing it seems
<lekernel>
e.g. a few seconds
<lekernel>
if you interrupt the signal for < 1s, the adv7181 doesn't go into "unlocked" state and doesn't bug
<aw>
before i test, pls let me know what version of s/w you're testing now.
<wolfspraul>
aw: I'm pretty sure you will see that problem with any version
<wolfspraul>
just test with whatever version is on your m1 now
<aw>
the lastest or 0603?
<wolfspraul>
test first, then we can compare versions
<wolfspraul>
I'm testing now, one sec...
<wolfspraul>
he, I've had it so many times before, but now that I try a systematic test I can't reproduce it.
<wolfspraul>
unplug/replug 10 times in video-in dialog, all fine
<wolfspraul>
unpug/replug in full-screen video-in patch, also worked a few times in a row
<lekernel>
funny, for me it breaks 90% of the time when waiting a 1-2 seconds between unplug and replug
<wolfspraul>
yes that's what I remember too
<wolfspraul>
but just now I cannot reproduce it
<lekernel>
this is the kind of bugs I love most :(
<aw>
lekernel, just a second, do you want me stop the fedex pak and also send you my smd xtal?
<lekernel>
apparently I agree with the ADI support on that
<wolfspraul>
wait wait, one by one
<wolfspraul>
the ADI response is quite honest actually, we should not jump to conclusions so fast.
<wolfspraul>
aw: oh right, we have a new video-in xtal, right?
<aw>
i am not jumpp to conclusion since i just sent remoter to lekernel , i believe that i can call fedex pak back.
<aw>
i just want to provide that smd xtal to lekernel , how do you guys think?
<aw>
although I've not tested about video input though
<lekernel>
well... we're going to switch to the adv7180 in rc4 anyway
<lekernel>
hopefully they would have fixed that bug
<lekernel>
with the 7181, there is the solution of making the FPGA reset the video chip when it fails
<wolfspraul>
one by one
<wolfspraul>
it seems lekernel does not want the xtal right now
<wolfspraul>
aw: let's try to test the procedure above
<lekernel>
the ugly workaround solution also has the advantage of making existing boards work
<wolfspraul>
if we sell something, we have to support it
<wolfspraul>
but we know too little know, I need to collect some more data
<wolfspraul>
it's good that you can reproduce it so easily now
<aw>
wolfspraul, sure..my h/w patch is not same with you both. stay tuned for tests.
<wolfspraul>
doesn't matter, test first then we see
<wolfspraul>
just the above sequence, whatever sw you have on it
<wolfspraul>
lekernel: for your ideas about unstable supply voltage or oscillator problems, how/where could Adam check for those?
<wolfspraul>
maybe this is already clear to Adam, but not to me :-) if it's clear, then no need to spell it out...
<wolfspraul>
my camera detection is rock solid right now :-)
<lekernel>
measure with oscilloscope
<wolfspraul>
you mean the supply voltage for the ADV chip is not stable?
<lekernel>
if possible (DSO memory), check for glitches, particularly when the problem happens
<lekernel>
it could be glitched, eg from insufficient decoupling
<aw>
hi all your tests for steps 1 ~ 5, after steps 5 then goes to step1 or just turn to step 4 and step5 back and fore to monitor?
<wolfspraul>
after 5, did you see the live video-in again?
<wolfspraul>
did it detect the signal?
<wolfspraul>
if so, repeat 4 and 5
<wolfspraul>
unplug, wait 3 seconds, replug
<wolfspraul>
the bug would be if after replugging, the signal is not detected anymore
<wolfspraul>
lekernel: why and how would those glitches be connected to plugging in the camera though?
<wolfspraul>
I would think that must narrow it down to some very specific places/wires, no?
<wolfspraul>
otherwise it could happen at any time, not just when unplugging/replugging
<wolfspraul>
but I have never seen the camera suddenly loose signal in operation
<wolfspraul>
I have only ever seen this problem on conjunction with unplugging/replugging
<lekernel>
when plugging the camera, it could be that the chip draws a lot of current in a spike, gets an out of specs power supply dip, and goes into failed state
<wolfspraul>
ah ok
<wolfspraul>
that makes sense to me :-)
<lekernel>
maybe this could even be fixed simply by installing larger caps
<wolfspraul>
it could also come from the unplugging side
<lekernel>
yes
<wolfspraul>
well, I can't reproduce it now :-)
<wolfspraul>
I'm using 1.0rc1 built June 6 2011
<aw>
my tests result: 10 times, steps 1 -> ... 3 (pluging 5 seconds)-> 4 (unplug 5 seconds) -> 3(plug 5 seconds), no err no fails.
<wolfspraul>
:-)
<wolfspraul>
aw: so it always picks up the signal after you replug the camera?
<wolfspraul>
well, for months I'd say I saw this and lekernel didn't, and now it's the other way round. I guess neither me or Adam see it, but lekernel does
<aw>
wolfspraul, yes
<aw>
lekernel, does your board a rc2 or rc1?
<lekernel>
rc2
<lekernel>
I never got video in to work on rc1
<aw>
okay...let me take my h/w patch pictures. :-)
<GitHub13>
[rtems-milkymist] sbourdeauducq pushed 1 new commit to master: http://bit.ly/kSP5gr
<GitHub13>
[rtems-milkymist/master] Simplify video chip I2C programming - use chip's default values instead of the complex and obscure sequence from the datasheet - Sebastien Bourdeauducq
<wolfspraul>
aw: for now I think it's ok. you cannot reproduce it, no need to waste time.
<wolfspraul>
I cannot reproduce it either right now.
<wolfspraul>
the only thing I want to avoid is that we are missing a good chance to catch a pcb/routing problem
<wolfspraul>
but it seems there are many workarounds and potential fixes anyway, and we just have to take the risk and move forward
<wolfspraul>
what's better than taking some risks, no? :-)
<aw>
wolfspraul, i believe pcb is under making, some sort of taking risks already though.
<wolfspraul>
always, no risk no fun
<wolfspraul>
aw: thanks for the quick test
<wolfspraul>
if we find out more, we will alert you again :-)
<aw>
wolfspraul, sure :-)
<wolfspraul>
aw: you saw lekernel's theory above, right? the adv chip drawing too much current, leading to a voltage dip...
<wolfspraul>
I don't think we need to investigate this now, but maybe remember...
<wolfspraul>
it's really surprising that I totally cannot reproduce this now
<wolfspraul>
lekernel: which version are you using?
<wolfspraul>
I am probably using one of xiangfu's builds. is it possible that the bug only shows up with particular builds?
<aw>
wolfspraul, well...but i heard here senior engineers before, just heard, the RCA connector was developed very bad though.
<wolfspraul>
you mean RCA in general?
<lekernel>
git head
<aw>
cause between female and male RCA connectors, you can very easily said 50% to let main board's video input to suddently connected to camera's ground which that is exactly the other terminal RCA's shielding ground.
<lekernel>
but I haven't touched the video-in stuff since several releases
<lekernel>
well, lots and lots of stuff in CVBS are developed very bad :p
<lekernel>
that's in fact the main reason we are using adv7181 and not on-FPGA DSP, because there are a lot of utterly pesky and boring details
<lekernel>
it's like the USB of the 70s
<aw>
yeah..just heard before. yeah..CVBS, but mostly video chips handle that collision very well. :-)
<wolfspraul>
alright. bottom line: adam cannot reproduce it, we continue with production as before.
<aw>
um..got it.
<wolfspraul>
if lekernel has any further ideas (since you can currently reproduce the bug), please let us know right away
<wolfspraul>
if that bug manifests itself, it's quite a nasty little thing for users, although there are workarounds (worst case reboot with cam inserted)
<lekernel>
i'll try to implement the "watchdog" in the software anyway
<wolfspraul>
but given how users are, quite a big percentage will just say "camera doesn't work right", and getting the word out about rebooting etc. is all work
<lekernel>
it'll do nothing on correctly working boards, and get intermittently failing boards to work reliably
<wolfspraul>
that'd be great
<lekernel>
ADI datasheet: "The decoupling capacitors should be located between the power plane and the power pin. Current should flow from the power plane to the capacitor to the power pin. Do not make the power connection between the capacitor and the power pin."
<lekernel>
understands who can
<aw>
we all know this but sometime it may not meet for all decoupling caps while routing.
<lekernel>
hmm... shorting L9 has improved things it seems
<lekernel>
now failure mode is a lot more rare
<lekernel>
but since it's rare on wolfspraul 's board as well (and with L9) I'm not sure it's meaningful
<wolfspraul>
the bug is fixed now? do you propose any changes on the board?
<wolfspraul>
we are changing that crystal already, hope this won't cause new problems but if we are lucky it helps?
<lekernel>
simple. electrical noise (that is 100% certain to be the reason of the bug) causes the video chip to stop functioning. one of the symptoms very easily observed of the failure is that the chip stops transmitting the 27MHz video clock to the FPGA.
<lekernel>
now one the most sensitive part of the video input circuit wrt electrical noise is the crystal oscillator
<wolfspraul>
you think electrical noise is picked up on the wires from the crystal to the video chip?
<lekernel>
yes
<lekernel>
or the wires within the crystal itself, etc.
<lekernel>
do you have a photo flash ?
<wolfspraul>
you mean a camera with flash?
<lekernel>
yes, or better, just a powerful separate flash unit
<lekernel>
try flashing it close to the M1
<wolfspraul>
don't have that
<lekernel>
i'd bet this would cause the video chip to fail as well
<wolfspraul>
nice test :-)
<wolfspraul>
what do you propose to do now?
<lekernel>
first, there's some chance it works nicely with the new crystal
<lekernel>
adam's board has the new crystal, right?
<wolfspraul>
yes, I think so
<wolfspraul>
at the bottom though, which will be moved back to the top side in rc3
<lekernel>
and he never managed to reproduce the problem?
<lekernel>
yeah...
<wolfspraul>
'never managed' may be a slight exaggeration, since he never ever tested in that direction
<wolfspraul>
but no, he never saw it, neither before nor now
<wolfspraul>
aw: do you have another m1 board with the old video-in crystal like on the rc2 we sold?
<lekernel>
maybe it's just that the load capacitors should be adjusted
<aw>
wolfspraul, no, my current workable rc2 board is only one. :-)
<wolfspraul>
aw: and it has the new crystal already, on the bottom, right?
<wolfspraul>
aw: you saw what lekernel found out about the clock disappearing?
<aw>
wolfspraul, yes, on the bottom
<wolfspraul>
lekernel: since Adam cannot reproduce the problem right now, you are in the best position to see what could fix it. For adam, we would first need to get him to be able to reproduce it.
<aw>
wolfspraul, not clear on how lekernel found or solved?
<wolfspraul>
not solved I think, just better understood now
<wolfspraul>
"It's an EMI problem. It is possible to make the chip go into this condition without video signal (detected by monitoring the video clock) simply by making the ground of the camera cable touch the metal of the RCA plugs on the M1."
<lekernel>
maybe it's just that the crystal has too large load capacitors
<aw>
well...if this being to be that, we should be easily get the same condition in someone's board though.
<lekernel>
yeah, but heavily depending on PVT
<aw>
how about xiangfu's one?
<lekernel>
as good pesky bugs do
<aw>
wolfspraul, have u checked xiangfu's rc2?
<aw>
lekernel, yeah...maybe the load capacitors, but now the data is few
<aw>
so i'd like to test steps 1 ~ 5 while producing rc3 to monitor if that load capacitors influence this bug.
<aw>
so far now, too few hard data.
<aw>
for examples, if say 10/90 percent we find this while testing rc3, we surely need to fine tune capacitors with whole 90 pcs. if all pass then we get there. is it ok?
<wolfspraul>
I'm already waiting for xiangfu to come back online, to ask him to test
<wolfspraul>
aw: yes of course, that's one solution. but the earlier we know how to fix it the better, so there are no nasty surprises later...
<wolfspraul>
I'm using a different power supply on my camera now, compared to earlier tests
<aw>
wolfspraul, like i say the data is few, even i reproduce here, then if replace it with other value, only lekernel can double confirm with me only, others can not, so the data is still few though.
<wolfspraul>
need to see whether I can find the one I used before...
<wolfspraul>
yes, sure
<wolfspraul>
aw: we are collecting more data & knowledge now :-)
<wolfspraul>
lekernel: should Adam try the grounding test you described, instad of unplug/replug?
<aw>
also the rc3, the newest layout on Y2 is close to parallel digital data which is i mostly concern already though but I have no hard data to know this, but surely those steps must be a test procedure on rc3 to record them.
<lekernel>
this hasn't to do with digital noise from the M1 itself, but with external noise
<wolfspraul>
too bad, the power supply I used earlier was just shipped to Germany a few days ago :-)
<wolfspraul>
so I cannot go back to that right now (not sure it's even related)
<wpwrak>
lekernel: hmm, can you test the current that goes into the video chip when that happens ? seems a little odd that the xo alone would simply stop. not impossible, but i'd consider it much more likely that it just recovers after an upset.
<wpwrak>
lekernel: the metal that you have to touch to make the problem happen, would that be shield or signal ?
<aw>
wolfspraul lekernel , any idea let me know to if can help. i'd go offline now.
<lekernel>
shield
<lekernel>
just connect the camera ground with the M1 ground
<lekernel>
both being powered from mains
<wpwrak>
lekernel: eww.
<lekernel>
without earth and with double insulation transformers (e.g. floating potentials)
<lekernel>
yeah well
<lekernel>
a frustratingly high amount of work in this project is dealing with this kind of issues
<wpwrak>
lekernel: so one of your power supplies is leaking
<lekernel>
all power supplies are leaking
<wpwrak>
lekernel: you can probably feel it if you touch the barrel while being grounded
<wpwrak>
some more, some less :)
<lekernel>
no, I don't. that's one of the first things I tried when I noticed this.
<wpwrak>
hmm
<lekernel>
interestingly enough, those crap ADI datasheet give a lot of contradictory information about the crystal oscillator
<lekernel>
pick a combination of those: 27MHz crystal vs. 28.63636MHz, 1M shunt resistor vs. without, 33pF load capacitance vs. 47pF load capacitance
<lekernel>
p. 96: "Use the correct frequency crystal, which is 28.63636 MHz."
<lekernel>
p.1: "Clocked from a single 27 MHz crystal"
<lekernel>
actually I think I got this one right. there is a I2C register that selects between 27 and 28
<lekernel>
the board has 28.6..., and when I select 28 it works
<lekernel>
when I select 27, the video jumps
<lekernel>
that's at least one thing which is clear
<wpwrak>
i'm reading it. are they in china ? ;-)
<wolfspraul>
can we still implement a monitor in software to hard-reset the chip when the condition occurs?
<wolfspraul>
that's kind of a fall-back that will help everybody, even people who have boards now
<wpwrak>
ah. there's a flag. subaddress 0x1d, EN28XTAL
<wolfspraul>
[connect camera gnd to m1 gnd] isn't that what happens when I plug in the rca cable?
<wolfspraul>
how do I connect camera gnd to m1 gnd?
<wpwrak>
(register) yeah. (just catching up with what you wrrote)
<lekernel>
yes, just touch RCA plugs together
<lekernel>
just with the shell
<lekernel>
i'm pretty disappointed with this ADI product
<wolfspraul>
I'm still puzzled that I always had this before, but not now
<lekernel>
the joy of PVT-dependent bugs
<wolfspraul>
unfortunately the camera power supply I used before was just part of a big cleanup, 2 days ago! argh
<wpwrak>
lekernel: where did you see the 33 pF ? anyway, the load cap is a function of the crystal. you could also check the exact xo frequency and adjust it
<wolfspraul>
also, I always had that side of the acrylic open, to access jtag-serial
<wolfspraul>
now it's closed
<wolfspraul>
I will reopen it now, I probably touched the rca connector differently on insertions than I do now
<lekernel>
in fact, 33pF is in the ADV7181 (not B) datasheet
<lekernel>
that might just be the problem...
<lekernel>
the board has 33
<wpwrak>
lekernel: check e.g., with a frequency counter or make a clock counter and read it over a large time interval
<lekernel>
Load capacitance affects loop gain since the feedback voltage is obtained in both configurations from the
<lekernel>
voltage divider formed by C1
<lekernel>
and the crystal, so it is very important to account for stray capacitance when
<lekernel>
calculating the value of C1
<lekernel>
and C2
<lekernel>
. In the Pierce configuration, adding load capacitance will reduce loop
<lekernel>
gain in some cases.
<lekernel>
...and with insufficient loop gain comes poor noise immunity, which is probably what we are seeing now
<lekernel>
i'll throw in smaller caps
<wpwrak>
C=2*(Cload-Cs)-Cph    Cload = 18pF, Cs="2pF to -3pF" whatever that means, and Cph=4-10pF. so if we take roughly the median value, we get C=2*(18-0)-7 pF = 29 pF. close enough :)
<lekernel>
wolfspraul, do you have the datasheet of that new crystal we are planning for rc3?
<wpwrak>
lekernel: does connecting camera ground also upset the M1 if you ground it ? if yes, then you could watch the power rails relative to M1 ground with a scope
<lekernel>
no, it only the video chip that has the problem
<wpwrak>
lekernel: what i mean is: if you connect a scope to your M1, which implicitly grounds the M1 (unless you have a portable or exotic scope), does touching the camera ground still cause the problem ?
<lekernel>
ok load capacitance 20pF, that should be close enough
<lekernel>
you mean earth?
<wpwrak>
yes
<lekernel>
I don't have a functional earth connection here
<wpwrak>
;-)
<wpwrak>
alright. when you connect your scope, in this case with "floating earth", does that alter the behaviour ?
<lekernel>
interestingly enough, no
<wpwrak>
good so far. to which ground did you connect it ? fpga digital or analog ground ? (assuming you've split them, as the data sheet tells you to)
<lekernel>
but that's probably just because that old 50Hz transformer powered scope produces less electric noise than the switching PSU of the camera
<lekernel>
just scope ground to RCA shell - like with the camera, when it creates the problem
<wpwrak>
ah no, i was thinking of connecting the scope to the M1
<wpwrak>
preferably to the largest/"best" ground you have there
<lekernel>
RCA shell is the ground
<wpwrak>
ah, okay. M1 RCA. got it
<wpwrak>
is the crystal referenced to digital or analog ground ?
<wpwrak>
or does it have a separate ground section ?
<wpwrak>
ah, i see it. separate ground.
<wpwrak>
and rca would be analog ground
<wpwrak>
lekernel: hmm, you implemented what the pictire (figure 41, adv7181B data sheet) says but not what the text recommends.
<wpwrak>
but besides that, i can't see any ground issues. i.e., all your GND pins seem to go to the respective ground
<wpwrak>
of course, if a surge ripples through the chip, that may still be enough to upset it
<wpwrak>
lekernel: i would look (with the scope) for a difference of potential between agnd and dgnd when you touch that camera ground to rca. you'll need a low-noise probe, though.
<wpwrak>
lekernel: then you could try just adding bridges between agnd and dgnd, i.e., make them look more like the single ground plane AD recommend in the text
<lekernel>
wpwrak, what's the difference you spotted between picture and text?
<lekernel>
or just short L19?
<wpwrak>
lekernel: that is, unless there are other reasons that make you strongly want a split ground plane
<lekernel>
actually shorting L19 is a good idea
<wpwrak>
L19 looks nice and fat, yes :)
<wpwrak>
(difference) "It is also recommended to use a single ground plane for the entire board." and then they show gap plus a relatively wide bridge under the chip.
<lekernel>
well, large voltage spikes or even continuous AC between AGND and DGND look like a good candidate for the issues we're seeing
<wpwrak>
yeah, it'a actually consistent. but you don't have the bridge
<wpwrak>
(spikes) yes
<lekernel>
we'll know soon. soldering iron warming up...
<wpwrak>
i would suspect the whole chip just goes into some locked-up state. the xo failure may just be a symptom of the collapse.
<lekernel>
I haven't directly measured xo failure yet
<lekernel>
the clock I'm talking about is the LLC output
<wpwrak>
ah. maybe just that one got turned off
<lekernel>
no, another symptom is that the I2C reset (and other commands) become unresponsive
<lekernel>
basically, the whole I2C thing becomes a SRAM
<wpwrak>
okay. some bigger upet then
<wpwrak>
upSet
<lekernel_>
problem fixed without L19. thanks wpwrak :)
<lekernel_>
this thing works perfectly now
<wpwrak>
kewl ;-)
<lekernel_>
wolfspraul, so just replace L19 with 0 ohm on RC3
<wpwrak>
i think the proper solution would be to connect the two ground underneath the chip
<wpwrak>
the AD data sheet is confusing in this regard. first they say you should have one ground plane, then they tell you to split it. looks like two different engineers, one from the "one ground place to rule them all" camp, the other from the "one ground plane per current loop" camp wrote this. but that they agree on is that there should be a connection of some kind under the chip.
<wpwrak>
s/place/plaNe/
<wpwrak>
s/that/what/
<wpwrak>
needs more coffee
<wolfspraul>
lekernel_: looks like I don't need to do anything anymore on this?
<wolfspraul>
I was about to test with the acrylic side open, as I had it before
<wolfspraul>
also during dinner I realized on rc3 we have added a surge protection in that area, no? just thought about it
<wolfspraul>
anyway, L19 = 0ohm is the solution...
<wolfspraul>
so that's a schematics change? we need to tell Adam
<lekernel_>
short L19 and the video input should be rock solid
<wolfspraul>
I guess L19 can also be fixed on rc2 with 0ohm?
<lekernel_>
on rc3 it will be possible to implement the change by using 0 ohm, without any PCB layout change
<lekernel_>
yes
<lekernel_>
I have a blob of solder instead atm
<wolfspraul>
understood. so that needs to be added to the rc2 known issues list as well
<wolfspraul>
in that case I think we can forego the monitor-in-software idea
<lekernel_>
the protection we added is between signal and analog ground
<wolfspraul>
since a) there is a workaround (reboot) b) people (or us) can relatively easily fix any rc2 board
<wolfspraul>
no need to clutter our software imho
<lekernel_>
the issue we just fixed is between analogue and digital grounds
<lekernel_>
and probably third party supply adapters, mains, etc.
<wolfspraul>
lekernel_: ok, so just to confirm:
<wolfspraul>
a) add L19 = 0ohm to rc2 known issues list
<wolfspraul>
b) no need for software monitor/chip reset, because workaround and easily fixed on any rc2 board
<lekernel_>
yes
<wolfspraul>
c) in rc3, put 0ohm on L19
<wolfspraul>
that's all
<wolfspraul>
right?
<lekernel_>
yes
<wolfspraul>
great
<wolfspraul>
very nice. thanks Werner!
<wpwrak>
no problem. it's fun to play EE :)
<GitHub142>
[llvm-lm32] jpbonn pushed 1 new commit to master: http://bit.ly/kOBoCQ
<lekernel>
and infer memories, it works most of the times
<fpgaminer>
yeah, but for large chucks I prefer to be explicit
<lekernel>
?
<fpgaminer>
I prefer to use vender specific instances for large chunks of memory
<lekernel>
why?
<lekernel>
optimization usually doesn't have anything to do with size, but whether the synthesis tool is able to extract particular memory features, like dual ports, byte enables, etc.
<fpgaminer>
Well, on Altera for example, it's a lot easier to enable their memory editor if you've used their megafunction
<fpgaminer>
Trying to get live memory editting enabled for inferred memory requires strange voodoo magic I never could nail down
<lekernel>
...and then you end up spending a lot of time porting your design from one fpga vendor to another, don't you? :-)
<fpgaminer>
Naw, I just stay on my comfortable island of Altera :P
<lekernel>
for me, "comfortable" means being able to write a portable behavioral model of a wishbone block ram in less than 5 minutes
<lekernel>
not getting locked in that megafunction clickodrom
<Fallenou>
Does someone know how many bytes I must remove from a .bit header to obtain the .bin ?
<Fallenou>
I don't have any bitgen nearby
<lekernel>
until you reach the sync word
<lekernel>
ffff .... aa995566
<lekernel>
(or the same with bits reversed)
<Fallenou>
ok so I strip until 55 66, and leave 30 00 80 01 etc ...
<Fallenou>
oh no, I leave them ?
<Fallenou>
so I strip until I reach ff ff ff ff, I leave those ff intact, right ?
<Fallenou>
so that the .bin begins with ff ff ff ff aa 99 55 66
<GitHub4>
[llvm-lm32] jpbonn pushed 1 new commit to master: http://bit.ly/iwfv5N
<GitHub4>
[llvm-lm32/master] Updates for new LLVM head.  Fixed function attributes, removed tests removed from other targets, switch malloc to alloca. - JP Bonn