#milkymist IRC log for Friday, 2011-06-17

lekernelroh, 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 perfect06:58
lekerneljust make 80 (or whatever quantity wolfspraul ordered) of the previous design06:59
wolfspraul80, yes. but I'm sure roh is already on this.07:00
wolfspraulthe engraving is a separate workstep, I don't think whether we do engraving or not will delay the making of cases themselves.07:00
lekernelwe can engrave with the laser, but it looks complicated for roh, so leave it07:01
wolfspraulas for roh trying to find timeslots to work on this job (80 m1 cases) in parallel with other jobs, I fully understand that07:01
wolfspraulwe 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 reality07:02
wolfspraulmaybe 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).07:02
GitHub193[extras-m1] adamwang pushed 2 new commits to master: http://bit.ly/j2Ly3M07:25
GitHub193[extras-m1/master] 1, moved some silk screen texts to better view... - adamwang07:25
GitHub193[extras-m1/master] 1, generate drill with suppress leading zeros - adamwang07:25
GitHub174[flickernoise] sbourdeauducq pushed 1 new commit to master: http://bit.ly/lM9ruE08:14
GitHub174[flickernoise/master] Missing include - Sebastien Bourdeauducq08:14
lekernelDear customer,09:09
lekernelDue to an unforeseen situation in our Support Team we are unable to support you for the ADV Video Products.09:09
lekernelthey make crap silicon, and won't stand behind it09:09
wolfspraulthat sounds unusual indeed, but at least honest09:12
wolfspraulmaybe someone quit?09:12
lekernelI can definitely track down the video input "no more signal acquisition" problem to a silicon issue, unless we really messed up the M1 PCB09:13
wolfspraulhow would we rule out the "really mseed up the m1 pcb" possibility?09:14
lekernelthe chip won't respond to an I2C reset when the condition appears09:14
wolfspraulmessed up09:14
lekernelthe 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 happens09:15
wolfspraulok how can we rule out a pcb problem?09:15
lekernelwe went over that schematics many times already, and no one noticed any error09:16
lekerneland what could cause that?09:16
lekernelpower supply issues?09:16
wolfspraulwhat 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?09:16
lekernelincorrect power supply voltage or failing oscillator09:17
wolfspraulhow would either of those be related to a unplug/replug event?09:18
wolfspraulthe 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)09:18
wolfsprauland if not at boot time, I believe it also always, or almost always, it detected on the first insertion09:19
wolfspraulthe problem starts with the first unplugging from a running system, I believe09:19
wolfspraulat least from what I've seen so far, without exhaustive testing around this issue though09:19
lekernelcircuit just at the brink of failing, and having to re-detect the signal triggers the complete bug09:19
lekernelthat being said, if ADI's silicon is the same quality of their technical support, this might not be our fault09:20
wolfspraulit doesn't matter whose fault it is, for the user this is quite a nasty little problem09:20
wolfspraulbasically we have to tell people to always plug their camera in before booting, and not unplug/replug in a running system09:20
lekernelthere 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 happens09:21
lekernelmaybe there's a symptom that is easy to spot, like the video clock stopping09:21
wolfspraulif you believe the circuit is not stable (voltage or oscillator?), how would we test that, or proove it, or fix it?09:21
wolfspraulI 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?09:22
lekerneluse an oscilloscope09:22
lekernelyes, but the chip still responds to a hard reset (not I2C, but with the pin)09:23
lekerneleven though the datasheet says the two should have exactly the same action09:23
wolfspraulaw: have you seen this 'cannot detect camera signal' bug before?09:25
wolfspraulI think you can try this sequence: 1. boot your m1, without camera connected09:26
wolfspraul2. go to the video-in dialog09:26
wolfspraul3. plug in the running obk-2010cw, the signal should be detected and live preview comes up09:26
wolfspraul4. unplug camera09:27
wolfspraul5. replug camera09:27
awwolfspraul, no, maybe i've not let m1 worked on too long time.09:27
wolfspraulaw: ok, try that sequence09:27
wolfspraulI'm trying here too...09:27
awwolfspraul, surely, but have u met it?09:27
lekernelif you wait a bit between #4 and #5, the problem has more chances of appearing it seems09:28
lekernele.g. a few seconds09:28
lekernelif you interrupt the signal for < 1s, the adv7181 doesn't go into "unlocked" state and doesn't bug09:29
awbefore i test, pls let me know what version of s/w you're testing now.09:30
awwhich one: http://www.milkymist.org/snapshots/09:31
wolfspraulaw: I'm pretty sure you will see that problem with any version09:31
wolfsprauljust test with whatever version is on your m1 now09:32
awthe lastest or 0603?09:32
wolfspraultest first, then we can compare versions09:32
wolfspraulI'm testing now, one sec...09:32
wolfspraulhe, I've had it so many times before, but now that I try a systematic test I can't reproduce it.09:36
wolfspraulunplug/replug 10 times in video-in dialog, all fine09:36
wolfspraulunpug/replug in full-screen video-in patch, also worked a few times in a row09:36
lekernelfunny, for me it breaks 90% of the time when waiting a 1-2 seconds between unplug and replug09:36
wolfspraulyes that's what I remember too09:37
wolfspraulbut just now I cannot reproduce it09:37
lekernelthis is the kind of bugs I love most :(09:37
awlekernel, just a second, do you want me stop the fedex pak and also send you my smd xtal?09:37
lekernelapparently I agree with the ADI support on that09:37
wolfspraulwait wait, one by one09:38
wolfspraulthe ADI response is quite honest actually, we should not jump to conclusions so fast.09:38
wolfspraulaw: oh right, we have a new video-in xtal, right?09:39
awi am not jumpp to conclusion since i just sent remoter to lekernel , i believe that i can call fedex pak back.09:39
awi just want to provide that smd xtal to lekernel , how do you guys think?09:40
awalthough I've not tested about video input though09:40
lekernelwell... we're going to switch to the adv7180 in rc4 anyway09:41
lekernelhopefully they would have fixed that bug09:41
lekernelwith the 7181, there is the solution of making the FPGA reset the video chip when it fails09:41
wolfspraulone by one09:43
wolfspraulit seems lekernel does not want the xtal right now09:43
wolfspraulaw: let's try to test the procedure above09:43
lekernelthe ugly workaround solution also has the advantage of making existing boards work09:44
wolfspraulif we sell something, we have to support it09:44
wolfspraulbut we know too little know, I need to collect some more data09:45
wolfspraulit's good that you can reproduce it so easily now09:45
awwolfspraul, sure..my h/w patch is not same with you both. stay tuned for tests.09:45
wolfsprauldoesn't matter, test first then we see09:45
wolfsprauljust the above sequence, whatever sw you have on it09:45
wolfspraullekernel: for your ideas about unstable supply voltage or oscillator problems, how/where could Adam check for those?09:49
wolfspraulmaybe this is already clear to Adam, but not to me :-) if it's clear, then no need to spell it out...09:49
wolfspraulmy camera detection is rock solid right now :-)09:49
lekernelmeasure with oscilloscope09:49
wolfspraulyou mean the supply voltage for the ADV chip is not stable?09:50
lekernelif possible (DSO memory), check for glitches, particularly when the problem happens09:50
lekernelit could be glitched, eg from insufficient decoupling09:50
awhi 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?09:51
wolfspraulafter 5, did you see the live video-in again?09:51
wolfsprauldid it detect the signal?09:51
wolfspraulif so, repeat 4 and 509:51
wolfspraulunplug, wait 3 seconds, replug09:51
wolfspraulthe bug would be if after replugging, the signal is not detected anymore09:51
wolfspraullekernel: why and how would those glitches be connected to plugging in the camera though?09:52
wolfspraulI would think that must narrow it down to some very specific places/wires, no?09:52
wolfspraulotherwise it could happen at any time, not just when unplugging/replugging09:52
wolfspraulbut I have never seen the camera suddenly loose signal in operation09:52
wolfspraulI have only ever seen this problem on conjunction with unplugging/replugging09:53
lekernelwhen 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 state09:53
wolfspraulah ok09:53
wolfspraulthat makes sense to me :-)09:53
lekernelmaybe this could even be fixed simply by installing larger caps09:54
wolfspraulit could also come from the unplugging side09:54
wolfspraulwell, I can't reproduce it now :-)09:55
wolfspraulI'm using 1.0rc1 built June 6 201109:56
awmy tests result: 10 times, steps 1 -> ... 3 (pluging 5 seconds)-> 4 (unplug 5 seconds) -> 3(plug 5 seconds), no err no fails.09:56
wolfspraulaw: so it always picks up the signal after you replug the camera?09:56
wolfspraulwell, 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 does09:57
awwolfspraul, yes09:57
awlekernel, does your board a rc2 or rc1?09:58
lekernelI never got video in to work on rc109:58
awokay...let me take my h/w patch pictures. :-)09:58
GitHub13[rtems-milkymist] sbourdeauducq pushed 1 new commit to master: http://bit.ly/kSP5gr10:00
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 Bourdeauducq10:00
wolfspraulaw: for now I think it's ok. you cannot reproduce it, no need to waste time.10:03
wolfspraulI cannot reproduce it either right now.10:03
wolfspraulthe only thing I want to avoid is that we are missing a good chance to catch a pcb/routing problem10:03
wolfspraulbut it seems there are many workarounds and potential fixes anyway, and we just have to take the risk and move forward10:04
wolfspraulwhat's better than taking some risks, no? :-)10:04
awwolfspraul, sure10:05
awjust let you all know my patch http://downloads.qi-hardware.com/people/adam/m1/pic/Y2_at_rc2_bottom_side.JPG10:05
awwolfspraul, i believe pcb is under making, some sort of taking risks already though.10:08
wolfspraulalways, no risk no fun10:09
wolfspraulaw: thanks for the quick test10:09
wolfspraulif we find out more, we will alert you again :-)10:09
awwolfspraul, sure :-)10:09
wolfspraulaw: you saw lekernel's theory above, right? the adv chip drawing too much current, leading to a voltage dip...10:10
wolfspraulI don't think we need to investigate this now, but maybe remember...10:11
wolfspraulit's really surprising that I totally cannot reproduce this now10:11
wolfspraullekernel: which version are you using?10:11
wolfspraulI am probably using one of xiangfu's builds. is it possible that the bug only shows up with particular builds?10:12
awwolfspraul, well...but i heard here senior engineers before, just heard, the RCA connector was developed very bad though.10:12
wolfspraulyou mean RCA in general?10:13
lekernelgit head10:14
awcause 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.10:14
lekernelbut I haven't touched the video-in stuff since several releases10:15
lekernelwell, lots and lots of stuff in CVBS are developed very bad :p10:15
lekernelthat'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 details10:15
lekernelit's like the USB of the 70s10:16
awyeah..just heard before. yeah..CVBS, but mostly video chips handle that collision very well. :-)10:16
wolfspraulalright. bottom line: adam cannot reproduce it, we continue with production as before.10:16
awum..got it.10:16
wolfspraulif lekernel has any further ideas (since you can currently reproduce the bug), please let us know right away10:16
wolfspraulif that bug manifests itself, it's quite a nasty little thing for users, although there are workarounds (worst case reboot with cam inserted)10:16
lekerneli'll try to implement the "watchdog" in the software anyway10:17
wolfspraulbut 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 work10:17
lekernelit'll do nothing on correctly working boards, and get intermittently failing boards to work reliably10:17
wolfspraulthat'd be great10:17
lekernelADI 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."10:26
lekernelunderstands who can10:26
awwe all know this but sometime it may not meet for all decoupling caps while routing.10:34
lekernelhmm... shorting L9 has improved things it seems10:54
lekernelnow failure mode is a lot more rare10:54
lekernelbut since it's rare on wolfspraul 's board as well (and with L9) I'm not sure it's meaningful10:55
lekernelmh, probably not.10:59
lekernelsome news: https://github.com/milkymist/bugs/issues/1311:35
lekernelthe video clock should be running all the time - even without any video signal connected11:36
wolfspraulinteresting comments there11:43
wolfspraulEMI problem - that means we could fix it with better EMI protection too?11:44
wolfspraulor you just leave the clock on all the time and that fixes it?11:44
wolfsprauldon't quite understand how things connect together...11:44
lekernelI'd think this has to do with the crystal oscillator11:47
lekernelthe clock is generated by the video chip, not the fpga11:47
lekernelactually, if it were generated with the fpga that would have been one problem less...11:48
wolfspraulstill don't understand11:48
lekernelsee e.g. http://www.freescale.com/files/microcontrollers/doc/app_note/AN3208.pdf 10 Noise Immunity11:48
wolfspraulthe bug is fixed now? do you propose any changes on the board?11:48
wolfspraulwe are changing that crystal already, hope this won't cause new problems but if we are lucky it helps?11:49
lekernelsimple. 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.11:49
lekernelnow one the most sensitive part of the video input circuit wrt electrical noise is the crystal oscillator11:50
wolfspraulyou think electrical noise is picked up on the wires from the crystal to the video chip?11:51
lekernelor the wires within the crystal itself, etc.11:52
lekerneldo you have a photo flash ?11:52
wolfspraulyou mean a camera with flash?11:52
lekernelyes, or better, just a powerful separate flash unit11:52
lekerneltry flashing it close to the M111:53
wolfsprauldon't have that11:53
lekerneli'd bet this would cause the video chip to fail as well11:53
wolfspraulnice test :-)11:53
wolfspraulwhat do you propose to do now?11:53
lekernelfirst, there's some chance it works nicely with the new crystal11:53
lekerneladam's board has the new crystal, right?11:54
wolfspraulyes, I think so11:54
wolfspraulat the bottom though, which will be moved back to the top side in rc311:54
lekerneland he never managed to reproduce the problem?11:54
wolfspraul'never managed' may be a slight exaggeration, since he never ever tested in that direction11:55
wolfspraulbut no, he never saw it, neither before nor now11:55
wolfspraulaw: do you have another m1 board with the old video-in crystal like on the rc2 we sold?11:55
lekernelmaybe it's just that the load capacitors should be adjusted11:56
awwolfspraul, no, my current workable rc2 board is only one. :-)12:00
wolfspraulaw: and it has the new crystal already, on the bottom, right?12:03
wolfspraulaw: you saw what lekernel found out about the clock disappearing?12:04
awwolfspraul, yes, on the bottom12:04
wolfspraullekernel: 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.12:05
awwolfspraul, not clear on how lekernel found or solved?12:05
wolfspraulnot solved I think, just better understood now12:05
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."12:06
lekernelmaybe it's just that the crystal has too large load capacitors12:06
awwell...if this being to be that, we should be easily get the same condition in someone's board though.12:07
lekernelyeah, but heavily depending on PVT12:07
awhow about xiangfu's one?12:07
lekernelas good pesky bugs do12:07
awwolfspraul, have u checked xiangfu's rc2?12:07
awlekernel, yeah...maybe the load capacitors, but now the data is few12:08
awso i'd like to test steps 1 ~ 5 while producing rc3 to monitor if that load capacitors influence this bug.12:09
awso far now, too few hard data.12:09
awfor 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?12:11
wolfspraulI'm already waiting for xiangfu to come back online, to ask him to test12:12
wolfspraulaw: 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...12:12
wolfspraulI'm using a different power supply on my camera now, compared to earlier tests12:13
awwolfspraul, 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.12:14
wolfspraulneed to see whether I can find the one I used before...12:14
wolfspraulyes, sure12:14
wolfspraulaw: we are collecting more data & knowledge now :-)12:14
wolfspraullekernel: should Adam try the grounding test you described, instad of unplug/replug?12:16
awalso 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.12:17
lekernelthis hasn't to do with digital noise from the M1 itself, but with external noise12:19
wolfspraultoo bad, the power supply I used earlier was just shipped to Germany a few days ago :-)12:20
wolfspraulso I cannot go back to that right now (not sure it's even related)12:20
wpwraklekernel: 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.12:23
wpwraklekernel: the metal that you have to touch to make the problem happen, would that be shield or signal ?12:24
awwolfspraul lekernel , any idea let me know to if can help. i'd go offline now.12:26
lekerneljust connect the camera ground with the M1 ground12:26
lekernelboth being powered from mains12:27
wpwraklekernel: eww.12:27
lekernelwithout earth and with double insulation transformers (e.g. floating potentials)12:27
lekernelyeah well12:27
lekernela frustratingly high amount of work in this project is dealing with this kind of issues12:28
wpwraklekernel: so one of your power supplies is leaking12:28
lekernelall power supplies are leaking12:28
wpwraklekernel: you can probably feel it if you touch the barrel while being grounded12:28
wpwraksome more, some less :)12:28
lekernelno, I don't. that's one of the first things I tried when I noticed this.12:29
lekernelinterestingly enough, those crap ADI datasheet give a lot of contradictory information about the crystal oscillator12:30
lekernelpick a combination of those: 27MHz crystal vs. 28.63636MHz, 1M shunt resistor vs. without, 33pF load capacitance vs. 47pF load capacitance12:30
wpwrakfor different crystals ?12:31
lekernelsee for yourself http://www.analog.com/static/imported-files/data_sheets/ADV7181B.pdf12:31
wpwrakor do they specify exactly one product ?12:31
lekernelp. 96: "Use the correct frequency crystal, which is 28.63636 MHz."12:31
lekernelp.1: "Clocked from a single 27 MHz crystal"12:31
lekernelactually I think I got this one right. there is a I2C register that selects between 27 and 2812:32
lekernelthe board has 28.6..., and when I select 28 it works12:32
lekernelwhen I select 27, the video jumps12:32
lekernelthat's at least one thing which is clear12:32
wpwraki'm reading it. are they in china ? ;-)12:32
wolfspraulcan we still implement a monitor in software to hard-reset the chip when the condition occurs?12:33
wolfspraulthat's kind of a fall-back that will help everybody, even people who have boards now12:33
wpwrakah. there's a flag. subaddress 0x1d, EN28XTAL12:33
wolfspraul[connect camera gnd to m1 gnd] isn't that what happens when I plug in the rca cable?12:34
wolfspraulhow do I connect camera gnd to m1 gnd?12:34
wpwrak(register) yeah. (just catching up with what you wrrote)12:34
lekernelyes, just touch RCA plugs together12:34
lekerneljust with the shell12:35
lekerneli'm pretty disappointed with this ADI product12:36
wolfspraulI'm still puzzled that I always had this before, but not now12:37
lekernelthe joy of PVT-dependent bugs12:37
wolfspraulunfortunately the camera power supply I used before was just part of a big cleanup, 2 days ago! argh12:37
wpwraklekernel: 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 it12:37
wolfspraulalso, I always had that side of the acrylic open, to access jtag-serial12:37
wolfspraulnow it's closed12:37
wolfspraulI will reopen it now, I probably touched the rca connector differently on insertions than I do now12:37
lekernelin fact, 33pF is in the ADV7181 (not B) datasheet12:37
lekernelthat might just be the problem...12:38
lekernelthe board has 3312:38
wpwraklekernel: check e.g., with a frequency counter or make a clock counter and read it over a large time interval12:38
lekerneland the B datasheet says 4712:38
wpwraklekernel: what does your crystal say ?12:38
wolfsprauloh I need to get some food first, bbiab12:39
lekernelthat's the crystal I have on my board (others have different models): http://www.farnell.com/datasheets/9026.pdf12:39
wpwrak33pF sounds good then12:40
wpwrakin any case, if you get the load cap a little wrong, it will just make the clock imprecise12:42
lekernelmore like 14-2612:42
lekernelit can make the oscillator unstable I'd guess12:43
lekernelLoad capacitance affects loop gain since the feedback voltage is obtained in both configurations from the12:43
lekernelvoltage divider formed by C112:43
lekernel and the crystal, so it is very important to account for stray capacitance when12:43
lekernelcalculating the value of C112:43
lekernel and C212:43
lekernel. In the Pierce configuration, adding load capacitance will reduce loop12:43
lekernelgain in some cases.12:43
lekernel...and with insufficient loop gain comes poor noise immunity, which is probably what we are seeing now12:44
lekerneli'll throw in smaller caps12:44
wpwrakC=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 :)12:44
lekernelwolfspraul, do you have the datasheet of that new crystal we are planning for rc3?12:46
wpwraklekernel: 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 scope12:48
lekernelno, it only the video chip that has the problem12:48
wolfspraulY2, right?12:49
lekernelyes y212:49
wolfspraulcould be this one http://downloads.qi-hardware.com/hardware/milkymist_one/datasheet/VideoIn/Qi%20R49SSA-028636-F20-YYY-YQA.pdf12:49
wpwraklekernel: 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 ?12:50
lekernelok load capacitance 20pF, that should be close enough12:50
lekernelyou mean earth?12:51
lekernelI don't have a functional earth connection here12:52
wpwrakalright. when you connect your scope, in this case with "floating earth", does that alter the behaviour ?12:53
lekernelinterestingly enough, no12:54
wpwrakgood 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)12:55
lekernelbut that's probably just because that old 50Hz transformer powered scope produces less electric noise than the switching PSU of the camera12:55
lekerneljust scope ground to RCA shell - like with the camera, when it creates the problem12:56
wpwrakah no, i was thinking of connecting the scope to the M112:56
wpwrakpreferably to the largest/"best" ground you have there12:56
lekernelRCA shell is the ground12:56
wpwrakah, okay. M1 RCA. got it12:57
wpwrakis the crystal referenced to digital or analog ground ?12:57
wpwrakor does it have a separate ground section ?12:58
wpwrakah, i see it. separate ground.13:02
wpwrakand rca would be analog ground13:03
wpwraklekernel: hmm, you implemented what the pictire (figure 41, adv7181B data sheet) says but not what the text recommends.13:05
wpwrakbut besides that, i can't see any ground issues. i.e., all your GND pins seem to go to the respective ground13:08
wpwrakof course, if a surge ripples through the chip, that may still be enough to upset it13:09
wpwraklekernel: 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.13:16
wpwraklekernel: 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 text13:17
lekernelwpwrak, what's the difference you spotted between picture and text?13:18
lekernelor just short L19?13:18
wpwraklekernel: that is, unless there are other reasons that make you strongly want a split ground plane13:18
lekernelactually shorting L19 is a good idea13:18
wpwrakL19 looks nice and fat, yes :)13:19
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.13:20
lekernelwell, large voltage spikes or even continuous AC between AGND and DGND look like a good candidate for the issues we're seeing13:20
wpwrakyeah, it'a actually consistent. but you don't have the bridge13:20
wpwrak(spikes) yes13:21
lekernelwe'll know soon. soldering iron warming up...13:21
wpwraki would suspect the whole chip just goes into some locked-up state. the xo failure may just be a symptom of the collapse.13:22
lekernelI haven't directly measured xo failure yet13:22
lekernelthe clock I'm talking about is the LLC output13:22
wpwrakah. maybe just that one got turned off13:23
lekernelno, another symptom is that the I2C reset (and other commands) become unresponsive13:23
lekernelbasically, the whole I2C thing becomes a SRAM13:23
wpwrakokay. some bigger upet then13:24
lekernel_problem fixed without L19. thanks wpwrak :)13:29
lekernel_this thing works perfectly now13:29
wpwrakkewl ;-)13:29
lekernel_wolfspraul, so just replace L19 with 0 ohm on RC313:29
wpwraki think the proper solution would be to connect the two ground underneath the chip13:30
wpwrakthe 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.13:32
Action: wpwrak needs more coffee13:32
wolfspraullekernel_: looks like I don't need to do anything anymore on this?13:40
wolfspraulI was about to test with the acrylic side open, as I had it before13:40
wolfspraulalso during dinner I realized on rc3 we have added a surge protection in that area, no? just thought about it13:40
wolfspraulanyway, L19 = 0ohm is the solution...13:40
wolfspraulso that's a schematics change? we need to tell Adam13:41
lekernel_short L19 and the video input should be rock solid13:41
wolfspraulI guess L19 can also be fixed on rc2 with 0ohm?13:41
lekernel_on rc3 it will be possible to implement the change by using 0 ohm, without any PCB layout change13:41
lekernel_I have a blob of solder instead atm13:41
wolfspraulunderstood. so that needs to be added to the rc2 known issues list as well13:42
wolfspraulin that case I think we can forego the monitor-in-software idea13:42
lekernel_the protection we added is between signal and analog ground13:42
wolfspraulsince a) there is a workaround (reboot) b) people (or us) can relatively easily fix any rc2 board13:42
wolfspraulno need to clutter our software imho13:42
lekernel_the issue we just fixed is between analogue and digital grounds13:43
lekernel_and probably third party supply adapters, mains, etc.13:43
wolfspraullekernel_: ok, so just to confirm:13:43
wolfspraula) add L19 = 0ohm to rc2 known issues list13:43
wolfspraulb) no need for software monitor/chip reset, because workaround and easily fixed on any rc2 board13:44
wolfspraulc) in rc3, put 0ohm on L1913:44
wolfspraulthat's all13:44
wolfspraulvery nice. thanks Werner!13:44
wpwrakno problem. it's fun to play EE :)13:45
GitHub142[llvm-lm32] jpbonn pushed 1 new commit to master: http://bit.ly/kOBoCQ17:43
GitHub142[llvm-lm32/master] Fixed jump tables. - JP Bonn17:43
GitHub20[llvm-lm32] jpbonn pushed 1 new commit to master: http://bit.ly/ifrRmc17:44
GitHub20[llvm-lm32/master] Removed invalid target architecture. - JP Bonn17:44
GitHub44[llvm-lm32] jpbonn pushed 1 new commit to master: http://bit.ly/k6imGV17:51
GitHub44[llvm-lm32/master] Fixed invalid use of add on floats (use fadd). - JP Bonn17:51
lekernelah, jump tables working would probably get the remaining demo firmware stuff to compile :-)18:14
lekernelhey, yes. only 2 files among those without inline asm do not compile18:18
lekernelboth give clang-3.0: /home/lekernel/Milkymist/llvm-lm32/lib/Target/Mico32/Mico32RegisterInfo.cpp:163: virtual void llvm::Mico32RegisterInfo::eliminateFrameIndex(llvm::MachineBasicBlock::iterator, int, llvm::RegScavenger*) const: Assertion `Offset%4 == 0 && "Object has misaligned stack offset"' failed18:18
GitHub162[llvm-lm32] jpbonn pushed 4 new commits to master: http://bit.ly/jvnNGi18:40
GitHub162[llvm-lm32/master] remove bitcode reader support for LLVM 2.7 metadata encoding.... - Chris Lattner18:40
GitHub162[llvm-lm32/master] Remove some "2" suffixes from the metadata enums now that "1" is gone.... - Chris Lattner18:40
GitHub162[llvm-lm32/master] missed a file.... - Chris Lattner18:40
GitHub43[mtk] sbourdeauducq pushed 1 new commit to master: http://bit.ly/k4rpIZ18:50
GitHub43[mtk/master] i18n: only rename widgets when language really changed - Sebastien Bourdeauducq18:50
GitHub42[flickernoise] sbourdeauducq pushed 1 new commit to master: http://bit.ly/kVU4PX19:04
GitHub42[flickernoise/master] guirender: simplify render stop - Sebastien Bourdeauducq19:04
GitHub31[scripts] sbourdeauducq pushed 1 new commit to master: http://bit.ly/jrvwxS19:19
GitHub31[scripts/master] typos - Sebastien Bourdeauducq19:19
Fallenouahah lekernel I was there, "VJing with arduinos ... err Milkymist"20:15
kristianpaulis that a graffiti? :)20:16
Fallenoukristianpaul: someone saying at the microphone "later on tonight you will have a performance of VJing with arduinos ... err Milkymist"20:17
Fallenouat an event in paris20:17
lekernelhi Hoagies2go21:48
fpgaminerFirst attempt run of LM32 on Altera .... failed :P22:01
fpgaminerGuess I gotta check what timing the memory module was expecting. I wans't sure if the Q on altsyncram should have been registered or not22:02
fpgamineryay for no documentation!22:02
lekernelthey have behavioral models22:03
lekernelreading the code should answer that type of question22:03
fpgaminerEasier said than done22:04
fpgaminerbut yeah, I'm doing that now22:04
lekernelor just run that behavioral model through the synthesis. quartus supports ram extraction.22:04
fpgaminerfor wb_ebr_ctrl.v?22:05
fpgaminerWell I've already overwritten it with patches, so not sure if it had a behavioral model in it originally22:05
lekernelwhat's wb_ebr_ctrl.v?22:05
fpgaminerIt's what their IDE produced for an On-Chip Memory22:06
lekerneljust use this22:06
fpgaminerbasically just a memory->Wishbone bridge/controller22:06
lekernelah, a wishbone block ram?22:07
lekerneldon't bother with the ide for that22:07
fpgamineraltsyncram in my case ;)22:07
lekerneland infer memories, it works most of the times22:07
fpgamineryeah, but for large chucks I prefer to be explicit22:07
fpgaminerI prefer to use vender specific instances for large chunks of memory22:08
lekerneloptimization 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.22:09
fpgaminerWell, on Altera for example, it's a lot easier to enable their memory editor if you've used their megafunction22:10
fpgaminerTrying to get live memory editting enabled for inferred memory requires strange voodoo magic I never could nail down22:10
lekernel...and then you end up spending a lot of time porting your design from one fpga vendor to another, don't you? :-)22:11
fpgaminerNaw, I just stay on my comfortable island of Altera :P22:11
lekernelfor me, "comfortable" means being able to write a portable behavioral model of a wishbone block ram in less than 5 minutes22:13
lekernelnot getting locked in that megafunction clickodrom22:13
FallenouDoes someone know how many bytes I must remove from a .bit header to obtain the .bin ?22:32
FallenouI don't have any bitgen nearby22:33
lekerneluntil you reach the sync word22:39
lekernelffff .... aa99556622:40
lekernel(or the same with bits reversed)22:40
Fallenouok so I strip until 55 66, and leave 30 00 80 01 etc ...22:50
Fallenouoh no, I leave them ?22:50
Fallenouso I strip until I reach ff ff ff ff, I leave those ff intact, right ?22:51
Fallenouso that the .bin begins with ff ff ff ff aa 99 55 6622:51
GitHub4[llvm-lm32] jpbonn pushed 1 new commit to master: http://bit.ly/iwfv5N22:56
GitHub4[llvm-lm32/master] Updates for new LLVM head.  Fixed function attributes, removed tests removed from other targets, switch malloc to alloca. - JP Bonn22:56
--- Sat Jun 18 201100:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!