#milkymist IRC log for Saturday, 2011-07-16

aw_updated: applied xiangfu's new reflash_m1.sh, now..rendering...:-) data partitions exists there. :-)04:01
aw_thanks xiangfu!04:03
aw_be noticed that this script enables 'verify' settings, although this is too long to speed up.04:04
aw_but xiangfu and sebastien was discussing about planing if do 'verify' tasks in test program to reduce time. this is good idea from sebastien. :-)04:05
aw_so well...i can enable or disable while testing rc3 board when i need to speed up on testing the same board to investigate. :-)04:06
aw_so with 'verify' setting is good to reflash a fully NEW mounted board. :-)04:07
aw_now re-test in test program to see if still all works well too.04:08
nixfreakwhat would be a good way to be to have an embedded device rip , transcode,and play video  but then operation be very fast04:08
nixfreakbut then execute very fast especially ripping and transcoding04:09
wolfspraulI don't understand what you wrote about verify...04:10
wolfspraulnixfreak: transcode in which way?04:11
wolfspraulsounds like the Milkymist One could do it, no? video-in, transcode, vga-out? but depending on what you want to do exactly a lot of programming may be needed :-)04:11
aw_wolfspraul, just forwarded their discussions in email. :-) you will know.04:13
kristianpaulwolfspraul: i tought same, thats why i point nixfreak to join channel and confirm it by it self :)04:13
aw_new reflash_m1.sh script: http://pastebin.com/tstnwy9E04:15
wolfspraulnixfreak: get a Milkymist One, start hacking :-)04:15
wolfspraulaw_: remember the audio_white_noise ogv you created yesterday? Will you upload it into the wiki or shoudl I do it?04:18
wolfspraulwe should collect the various testing documents and materials, and that's a nice one...04:18
nixfreakbasically wanna a create a device that can rip optical medium and then encode to say x264 with a very simple UI04:18
wolfspraulcan you be more precise? what do you mean with 'rip optical medium'?04:19
wolfspraulwhat do you want to do with the encoded x264 stream? save somewhere? stream over the internet?04:19
nixfreakfor consumers that are sick of dvd players but also want to archive the video04:20
nixfreakand be able to view the video in what ever resolution the tv / monitor is set to04:20
aw_wolfspraul, hi you can, pls. actually i wanted to make a page to show those two ogv that can show up how difference they are. :-)04:20
wolfspraulis there a wiki page already that collects rc3 tests?04:21
wolfspraulI will add it there04:21
aw_i am working others... :-)04:21
wolfspraulnixfreak: sounds possible, but I still don't fully understand what you want. You want to buy such a device? You want to manufacture one? You want to hack Milkymist One to be such a device?04:22
wolfspraulor you just want to tell us that you think you have a cool idea? :-)04:22
aw_wolfspraul, you could creat a subtitle under http://en.qi-hardware.com/wiki/Milkymist_One_run_3_schedule04:22
wolfspraulI'll check04:22
aw_then later I link them all. :-)04:22
wolfspraulah yes, I'll just throw it in there for now04:23
wolfspraullet's not create too many pages, rather a few and longer pages04:23
nixfreakI was thinking of FPGA to design/ create this project then was told to try this  channel04:23
wolfspraulyes you are definitely in the right place04:24
wolfspraulbut what do you want to do now?04:24
nixfreakI guess ask some advice what would be good way to implement this04:24
wolfspraulwhat do you mean with 'implement'?04:25
wolfspraulone way to set this up would be just to take a notebook and some software, no?04:25
wolfspraulare you trying to do this for yourself at your home, and then you are done. or do you want to learn about FPGA hacking? or are you trying to manufacture and sell a dedicated embedded device to perform this function?04:26
nixfreakbut in the end it should be embedded and small as possible04:26
wolfspraulcan you just get to the bottom line04:26
nixfreakyes learn and create04:26
wolfspraulmany things 'should' be this or that way04:26
wolfspraultell kristianpaul :-)04:26
wolfspraulGPS 'should' work by now, no?04:26
wolfspraulwhat is your background?04:27
wolfspraullearning? what?04:27
nixfreaknot a student ,self taught on many things04:27
wolfspraulhave you done FPGA and Verilog programming before?04:27
wolfspraulhow much time do you want to invest in this?04:27
nixfreakas much as it takes04:28
wolfspraulit sounds like get a notebook, set it up, and enjoy :-)04:28
wolfspraulor... get a Milkymist One and start hacking04:28
wolfspraulbut those two paths are very different04:28
nixfreakI like hacking code to learn04:29
wolfspraulMilkymist One costs 499 USD + shipping, you can buy it in a few weeks, if you like04:29
wolfspraulbut then you will need _a lot_ of hacking, months, maybe years04:29
wolfsprauljust saying...04:29
nixfreakdid say I was going to create this over night (:04:30
wolfspraulwhy do you want to embard on this project?04:30
nixfreakcause I would like to see a cheap price for media implementation especially for older folk that get frustrated with complex controls04:32
kristianpaul(GPS) yes it will04:32
wolfspraul"cheap price", ok. slowly you are telling us more about your motivations.04:33
wolfspraulcheap price will require big investment04:33
wolfspraulyou can make such a device for 20 USD, I'm sure. but only if someone invests millions of USD or more.04:33
wolfspraulthat's why most users tend to use standardized mass-market hardware, because even though it is overpowered, it is still cheaper and quicker to apply to a particular problem.04:34
wolfspraulat least someone has invested billions of USD to drive performance up in those devices04:34
wolfspraulso if you look for "cheap price", that's a big question you have to answer first. cheap for whom? for yourself? for the world? who invests? why? why not use existing devices? etc.04:35
nixfreakcheap as in $100.0004:36
wolfspraulso far my feeling is milkymist one is not the right thing for you, but I could be wrong. and of course I will happily sell you one :-)04:36
wolfspraulyes, someone has to invest millions of USD04:36
wolfspraul100 USD retail price itself is no problem04:36
nixfreakjust looking at my options04:36
wolfsprauland I try to give you free consulting :-)04:36
wolfspraulif it's just for yourself, get a notebook and try to set it up that way. problem solved.04:37
nixfreaki appreciate it04:37
wolfspraulif you are serious about learning Verilog and FPGA hacking, fine, get a Milkymist One and start04:37
wolfspraulthe 500 USD will be nothing compared to the thousands of hours you will sink into that over the next years04:37
nixfreakyep I understand04:38
aw_lunch time here, back soon.04:38
wolfspraulif you are hoping that you somehow can contribute to such a device on the market for 100 USD, you still need to find financially strong partners at some point that invest millions in this, and don't mind doing that (i.e. they have no better alternative for their money, called 'opportunity costs')04:38
wolfspraulinvestments in technology are hard because there is such tough competition04:38
wolfspraulso, given what I currently understand about you, I would think you should categorize that option under "not very likely to actually happen"04:39
wolfspraulyou need a very thorough market understanding (sales trends etc) to make such an investment decision04:40
wolfspraulunless you have a lot of industry experience already, and speak as an insider (which you are clearly not :-)), I'd say don't do it, forget it, it's not an option04:40
wolfspraulyou will never get that 100 USD device unless Samsung or LG or whoever one day decide to make one, for whatever reason04:41
nixfreakonly if I don't try04:43
nixfreakhave a good one thx for the advice04:43
wolfspraultoo much realidad maybe. I was just looking up a nice Wikipedia link...04:44
wolfspraulthere is something about hardware that attracts people to do stupid things.04:44
wolfspraulI'm wondering which percentage of sparkfun sales (for example) ends up in failed projects.04:44
wolfspraul'failed' is hard to define probably, maybe the learning experience from the failure is all that matters04:45
wolfspraulkristianpaul: this was the link I wanted to send him :-) http://en.wikipedia.org/wiki/Sysiphus04:47
wolfspraulkristianpaul: sorry in case I wasn't friendly enough to this guy, since you brought him here...04:47
kristianpaulno no, i just pointed to milkymist because he asked about video related stuff with fpgas in #fpga04:48
wolfspraulI doubt he will buy an m1, I doubt he will ever contribute 1 line of code anywhere, and I doubt he will ever get that 100 USD x.264 encoder made. Now he can proove me wrong...04:48
wolfspraulI know people hate it when someone says "you will never" :-)04:48
wolfspraulhe he. being nasty.04:48
kristianpaulrealidad, is nasty anyway04:51
wolfspraulI think it's fun. don't fight mother nature.04:53
wolfspraulwithout reality problems, thinking would be easy, we could all just get drunk and dream.04:54
wolfspraulbut once reality hits, and you still want your idea to come true, that's hard04:54
wolfspraul1000 people want to build an airplane, 1 makes one that can actually fly. no?04:54
kristianpaul404 http://www.milkymist.org/snapshots/latest/reflash_m1.sh ...05:34
wolfspraulthe whole snapshots is gone, maybe they cleaned up05:37
wolfspraul'snapshots' is not a good name05:37
wolfspraulwe need one name, and a clear testing and release process05:37
wolfspraulso we don't push out broken updates to users05:37
awupdate: http://downloads.qi-hardware.com/hardware/milkymist_one/production/rc3/test_results/2f-results05:37
wolfspraullooks good05:40
wolfspraulwhat's next?05:40
awbtw we can cancel the test about Press [0] in test program, since the new remote control doesn't have [0] push key. I'll let xiangfu know this.05:41
awnext to capture full screen05:42
wolfspraulno '0' on remote?05:43
awat the left up corner of remote control is hex code '0'05:44
kristianpaularghh, second time something happen with rtems, and all get stucj in I: Booting...05:44
wolfspraulI don't think in the test we need to press that many buttons anyway.05:44
awso i used my old to push '005:44
wolfspraultwo or three is enough. If those work I cannot imagine what other things we test, unless we press each button on the remote (then we test the remote), but that's a waste imo.05:45
wolfspraulok, we need to fix that '0' test then, something is wrong there05:45
awyeah...can reduce some to 5 keys, well... i pressed quickly though. not bit deal.05:45
wolfspraulbut it's still stupid and unfocused05:45
wolfspraultwo or three is enough, then we know the numbers are correctly getting across and we test the wires, transceiver, even rc-5 implementation in the fpga05:46
wolfspraulif we want to test the remote control itself (which I think we don't need to), then we need to press each button on the remote05:46
wolfspraulanyway, small detail05:47
wolfspraulok, full screen test now. and then D16, the one I'm waiting for :-)05:47
kristianpaullekernel: the right way of sync a core with a lower clock than m1 soc using wishbone is,  re-use wishbone handshake but sync the control signals. right? like in page 5 of this pdf http://www.edn.com/file/17561-310388.pdf?force=true05:53
awdo i need to always type IP address/Netmask/Gateway/DNS ?05:57
awbtw, i entered m1 by 'ftp' now. :-)05:58
awbackground is my living room. :-)06:05
wolfspraulscreenshot-02 reminds me that it would be cool if we had better brightness defaults, or auto-brightness...06:36
wolfspraulbut I like that we have brightness and contrast adjustment on the keyboard now, I think I saw that somewhere. maybe remote next...06:36
wolfspraulaw: I uploaded the audio noise videos, see http://en.qi-hardware.com/wiki/Milkymist_One_run_3_schedule#Audio_Noise06:39
wolfspraulunder the rc3 video, I document it was measured between C21 and R18. Was that how you measured the rc2 video as well? I have no information about that under the RC2 video. If you don't remember where you measured, no big deal... I think the key point is documented.06:40
awwolfspraul, yeah...good video in one column. tks.06:40
wolfspraulone row06:40
wolfsprauldo you remember the test points for the rc2 video?06:40
awyeah..i should set my brightness firstly...06:41
awyou can write the same06:41
awthe audio signals acts alternatively so that it doesn't matter on which C21 pad though. :-)06:42
awyes, good that i just checked the video I took on rc2 is the same on C21. :-)06:44
awi modified. :-)06:48
wolfspraulok great06:49
GitHub171[extras-m1] yizhangsh pushed 1 new commit to master: http://bit.ly/ozVVMY06:49
GitHub171[extras-m1/master] modified box die-cutting files and added size markers - Yi Zhang06:49
awsoldered three wires relevantly on TP36 (PROGRAM_B), TP35 (Done), TP37(RP#) to get ready to scope.07:35
aw_now I uploaded two waveforms without D16:08:34
aw_channels: what is what as file name.08:35
aw_next steps: I am going to scope with D16. moments...08:36
aw_i found it: yes. the diode D16 was reversed when I stayed in factory. I must be nervous and calm yesterday. hehe...stupid adam & smart werner, yes, there's exact a bar marked cathode on diode's body. and also I trained factory to see footprint's bar mark as anode. then we got in this results.09:01
aw_but...also bad thing is now that : I tested 10 times, i got 5 random NO-reconfiguration too. now go to scope again though.09:02
aw_didn't keep calm yesterday. :(09:03
wolfspraulso wait. now you are saying D16 'works', but now you still get the boot error it was supposed to fix?09:03
wolfspraulso it doesn't work?09:03
aw_sorry that again , i changed my words about NO-reconfigurations. keep calm again.09:05
wolfspraulI'm calm, just trying to understand :-)09:06
wolfspraulfor importance - the "no-reconfiguration" bug is a critical bug. Basically it means that m1 will not boot, right?09:06
wolfspraulthat is very important to be properly fixed, 100% of the time. So when you see this bug, that's a serious issue.09:06
aw_now: D16 soldered correctly. D2 ON slightly when power-on and OFF.09:06
wolfspraulyes but that's wrong09:07
aw_no no...wait ..let me finish my words. :-)09:07
wolfspraulok :-)09:07
wolfspraulthat's one of the most important bugs fixed with rc3... (together with audio noise)09:07
aw_1. D16 soldered correctly. D2 ON slightly when power-on and OFF.09:08
aw_2. I powered-on ten times, D2 ON slightly and goes OFF well.09:09
wolfspraulI don't understand09:09
wolfspraulcan we focus on product behavior, either correct product behavior, or incorrect product behavior09:09
wolfsprauldo you see incorrect product behavior?09:09
aw_3. among those ten times, I pressed SW2 to try to boot and enter gui, then 5 / 10 times D2 didn't ON.09:11
wolfspraulthat's a very serious bug09:11
wolfspraulso D16 has the right polarity now, but you say that basically the reset IC + diode does not fix the boot bug?09:12
aw_let me scope finished again firstly. :-)09:12
wolfspraulok but focus on understanding product behavior: 1) correct 2) incorrect09:12
wolfspraulotherwise we collect data points that are meaningless09:12
wolfspraulit sounds like you have D16 back on now, and you believe it's correct (polarity), but the product behavior is still INCORRECT09:13
wolfspraulthat is, the boot bug is not fixed09:13
xiangfuupload them there: http://milkymist.org/updates/2011-07-13/for-rc3/, include the new IR test. only needs 1,3,509:13
wolfspraulbut with our rc2 when we tested the reset IC+diode, the bug was fixed. What is the difference now?09:14
wolfspraulthat's my thinking...09:14
aw_wait...later the new waveforms I can know if the "forward voltage" of D16 is too high. or too margin.09:15
wolfspraulfrom your #1-#3 above, you seem to say that in 5/10 times, you cannot boot even though the D2 is not lit dimly before?09:15
wolfspraulfrom before I only know that basically whenever the D2 was dimly lit after power-on, it would not boot. but whenever it was clearly off, it would boot.09:16
wolfspraulif your description is accurate and I understand it correct, we have a third case now?09:16
wolfspraulD2 goes off entirely, but m1 still doesn't boot?09:16
GitHub109[autotest-m1] xiangfu pushed 1 new commit to master: http://bit.ly/rcNar109:16
GitHub109[autotest-m1/master] tests_ir: reduce test buttons to 3 - Xiangfu Liu09:16
wolfspraulaw_: to guide your work, focus on correct/incorrect behavior of rc3. rc3 must always boot into the GUI after power-on and button press, 100% of the time.09:17
wolfspraulnot 99% or anything, 100% of the time09:17
wolfspraulso the moment you have an rc3 not booting once, something is wrong09:17
wolfspraulso yesterday in the factory it didn't boot at all because the D16 polarity was wrong? will D16 have the correct polarity on the other 89 boards?09:19
aw_xiangfu, thanks.09:26
aw_first sum up a little from yesterday until now: (noticed that reset ic is always there on rc3)10:32
aw_1. without D16, m1 rc3 can boot up successfully at least more than 20 times10:34
aw_1.1 but not intensively to power up10:36
aw_2. without D16, after I scoped with a prober stuck on PROGRAM_B, it still can boot up 10 times.10:38
aw_3. with D16 (soldered), I didn't scope a prober stuck on PROGRAM_B, it got 5 / 10 times failed on boot up, so i still10:41
aw_4. with D16, scoped with a prober stuck on PROGRAM_B again, it can still boot up until my 26th power up, then got D2 keeps ON.10:44
aw_now m1 can't reconfigure. :(10:46
aw_item 3, made me remembered last time I did 1000 times to reconfigure successfully but forgot to test also 1000 times to boot up.10:47
aw_we indeedly didn't do boot up 1000 times. now I have no idea...later to see if m1 can restore.10:49
aw_i 'feel' an equivalent capacitance in scope's prober (which connected to PROGRAM_B) will easily let m1 get into NO reconfiguration status. But not proved.10:53
lekernelif the initial configuration works, this is certainly something which is fixable in software11:01
lekernelso that's extremely pesky, but not a big worry11:02
wolfspraulok that's messy, we need to clear this up11:15
wolfspraulif we are unsure whether the way we tested this on rc2 actually was good, then we need to repeat the test on the rc2 board, including full bootup11:15
wolfspraulmaybe not 1000 times, but 100 or 200 should be enough11:15
wolfspraulthen I'm surprised that I guess rc3 booted fine without D16. that makes me wonder why we added D16 in the first place and whether the problem is fixed if we simply remove it.11:16
wolfspraulwhich is something we can also verify on the rc2 board, after the full bootup test, by removing the diode there...11:16
wolfspraulafter that, we need to stop testing irrelevant cases on rc3, we should only focus on testing the one and only design we plan to manufacture and sell11:16
wolfspraulthat means we don't need to find out that the behavior is different when we keep the scope connected, because our users will not keep a scope connected :-)11:17
wolfspraulbut if we don't even know which design we actually think will fix the bug, then that introduces some uncertainty that makes us keep the scope connected all the time, I guess11:17
wolfspraulfinally, it's surprising that the rc3 board is now in a 'dead' state, hopefully we can find out which state this exactly is and recover11:18
wolfspraulaw_: does this all make sense?11:18
aw_wolfspraul, yeah...i stop and slow a bit. need to think steps on rc2 test again.11:22
wolfspraulgood. and also see my other points - why do we need D16 at all? why did rc3 boot without D16? stop testing irrelevant cases. how to recover rc3 board now.11:23
wolfspraulseems those are all valid questions, at least to me... and without answering them we are just producing something we don't really understand.11:24
wpwrak_aw_: (D16  reversed) that was an easy guess ;-)11:31
lekernelif it's the same problem as I had twice, reflash11:34
aw_wpwrak_, yeah :(11:36
aw_lekernel, what did you mean about last sentence? :-)11:37
lekernelto recover your board that no longer boots, reflash it11:37
wolfspraullekernel: why did we add D16 in the first place? we believe the circuit is incorrect without it? How come Adam had no booting problems while he had D16 removed?11:38
lekernela funny thing I noticed is that reflashing only the standby bitstream doesn't seem to help11:38
aw_lekernel, yeah11:38
lekernelI suspect some weird behaviour of the xilinx silicon11:38
lekerneltry reflashing standby only first, to confirm11:38
lekernelthen if it still doesn't boot (D2 dimly lit) reflash the rest11:39
lekernelI'll use altera next time, I'm tired of this kind of things11:39
wpwrak_wolfspraul: documenting behaviour with and without scope can be quite relevant, particularly while hunting for a problem that's not fully understood yet11:40
wolfspraulI'm not against it, but we will run into Altera specific bugs for sure.11:40
lekerneli've heard a lot less negative comments and errata entries about any altera chip than about the spartan6...11:41
wolfspraulwpwrak_: yes, that's why we first need to define what we are workign on here. do we have doubts about the design/schematic? or the particular rc3 board under test?11:41
wpwrak_wolfspraul: does adam have enough boards yet to even make this distinction ?11:43
wolfspraul(that's unrelated to this particular run here) I am open minded about Altera, we just need to keep in mind that between Altera and Xilinx, over time the 'leadership position' will probably bounce back and forth between them. So we may end up with bad timing and always regret our switch later...11:44
wolfspraulanother thing to consider is that once we sold a board, we have to support it for good, in software updates. So our build and test/release process will get more difficult, if we build up a trail of chip changes in our product history.11:44
lekernelwith D16 present and with the correct polarity, does the initial configuration always work? (i.e. D2 is totally off)11:45
wolfspraulother than that I'm cool about Altera, it proves the portability point, may lower barriers for some contributors, and gets us better chips11:45
wpwrak_lekernel: the art of reading errata ;-) here's one i came across recently: http://www.cypress.com/?docID=27429  lovely items, particularly the very last one (#14) should warm the heart of any connoisseur of USB. and the "we won't fix any of these" isn't very encouraging either. particularly in a chip that something like 8 years on the market. (context: i heard of that one in a discussion on how to bring USB host to the ben)11:46
wolfspraullekernel: I think adam's tests are inconclusive to answer that11:46
lekernelthat's the one and only thing to test about the reset IC and D1611:47
wolfspraulyes I know11:47
wolfspraullike I said - lots of irrelevant tests11:47
wolfspraulwithout D16, with probe connected11:47
wolfspraulbut what would help is if we build upon solid assumptions, for example it turns out when we did the test on rc2, we forgot to actually boot11:48
wolfspraulyou say even if there is a problem there it can be fixed in software, but that's speculative at this point11:48
lekernelthen there might be other layers of peskiness that randomly and rarely corrupt the flash, prevent booting after pushbutton press, etc. but those are highly unlikely to be related to the reset IC11:48
wolfspraulok, but let's collect hard data points, then we are not swimming in an ocean of uncertainty11:49
wolfspraulmaybe it just becomes a little lake of uncertainty :-)11:49
wolfspraullekernel: did you see my question above - why did we put D16 in in the first place? why did rc3 boot fine without it?11:50
lekernelsee mailing list archives11:51
lekernelit's to make sure the flash is in reset at power up and doesn't register wrong commands11:51
lekerneland all boards boot fine without it in 99% of the cases ...11:52
Vaati_oh whats this?11:53
wolfspraullekernel: you mean boot fine without the entire reset_ic+diode fix?11:54
wolfspraultotally wrong.11:54
wolfspraulyou have seen how many boards?11:54
wolfspraulI saw the other 38, each one of them11:55
wolfspraulif you want I can make a little survey of the few active users :-)11:55
wolfspraulI have this problem all the time11:55
wolfspraulxiangfu has it, Jon has it11:55
wolfspraulto turn on my m1, I always need to try to plug the power supply in several times, it's normal for me11:55
lekernelyes, I have it as well, but it's still rare - on my board at least11:55
wolfspraulfine but please don't say "all boards fine in 99%" if you actually have such little visibility11:56
wolfsprauljust trust me as your manufacturer telling you that it's a serious problem and I'm very happy and optimistic that we will fully fix it in rc311:56
lekernelok, then some boards boot fine without it in 99% of the cases ...11:56
wpwrak_Vaati_: at the moment, it's a bunch of people trying to figure out what's wrong with the ~90 boards that are just going through SMT :) boards with FPGA, video, and such.11:56
wolfspraulmaybe you got a lucky 2 of the 40 :-)11:56
wolfspraulif there is any value I can provide, it's solid testing across the entire run11:57
Vaati_hmmm  milkymist sounds familiar -- I think I came across it once while googling for some stuff11:57
Vaati_but I havent really ever looked into it11:57
wolfspraulkristianpaul: do you have this problem sometimes? that you need to plug in the power of your m1 multiple times before you can boot?11:57
Vaati_oh wow11:57
wpwrak_wolfspraul: it's not luck. the guy who's in the best position to fix a problem always gets the boards that don't have it. one of the many corollaries of murphy's law :)11:57
wpwrak_wolfspraul: isn't reliable boot more the domain of the reset chip ? D16 sounds more like preventing flash corruption (?)11:59
lekernelone of the problem we can have if the flash reset isn't asserted at power up is that the flash register a command and sends status info instead of data12:00
lekernelthis would make the fpga unable to read its bitstream, so no configuration, d2 dimly lit, etc.12:00
lekerneld16 is here to assert the flash reset at power up12:01
lekernelis that clear?12:01
wolfspraulwpwrak_: I am pretty sure we are very close to fixing this bug once and for all. But I guess the bug doesn't want to go without some drama... a nasty bug indeed.12:01
wolfspraulAdam's testing was a little unfortunate/unfocused, but in the next round we'll narrow it down and then it's done, I'm sure.12:02
wolfsprauladam has only 1 rc3 right now, the only one that is fully soldered12:02
wpwrak_lekernel: okay, makes sense. is this also possibly connected to the obscure flash corruption problem you had a while ago ? or is that one already off the table12:02
lekernelyes, if the flash happens to register a write or erase command at power up (unlikely but who knows...), that might well corrupt it.12:03
lekerneld16 is meant to prevent that as well ...12:04
wolfspraulok so we should focus on getting things to work with D16, because we believe D16 is what fixes the underlying bug12:07
wolfspraultogether with the reset ic12:07
lekernelwe also connected the reset IC to PROGRAM_B to make sure the FPGA doesn't attempt to read the flash while it's still in reset12:08
wolfspraulmaybe Adam's next quick test should be the old rc2 board, unmodified (with reset+diode), and test the complete bootup, 100 times or so12:08
lekernelthat's all this reset circuit is about.12:08
lekerneldo you get it now?12:08
lekernelI have explained it several times already :p12:09
wpwrak_lekernel: perfect. now the question is just why it doesn't to that. pity you used a diode and not a 74xxx1G logic gate. the be wary of diodes is one of the lessons we learned in the early GTA02 days at openmoko. there we also had such a reset "mixer" with a diode that caused all sorts of fun. (there, the problem was the reverse current)12:09
lekernelreverse current? mh12:09
lekernelimpedance is some 10k there12:10
lekernelyeah, 10K12:11
lekernelthe diode pulls down a 10K pull-up resistor to 3.3V12:11
wpwrak_lekernel: the diode we had back then was a grotesquely ill-fitting choice. so the chance that you fell into that trap is small :)12:11
wpwrak_lemme find the schematics ....12:11
lekerneland on the other side it's 4.7K12:11
wpwrak_gaah. too many pictures on that page :)12:12
lekernelleakage current should make a totally negligible voltage drop across 4.7K12:12
lekernelunless that's a very, very bad diode12:12
wpwrak_PROGRAM_B_2 some sort of a nWAIT signal ?12:14
lekernelthen forward voltage is 0.33V at 0.1A for that diode12:15
lekernelwpwrak_, no, it's like a reset signal that clears FPGA configuration and prevents configuration attempts when asserted12:15
lekerneland for the flash, any voltage below 0.6V is treated as logic low... so no problem there either12:16
lekernelpfff ...12:17
lekernelthere's a note in the flash datasheet says "Sampled, not 100% tested." for the logic low voltage specification, whatever that means12:18
wolfspraulthat means there is a small change that they will later withdraw from claiming this feature12:19
wolfsprauleither the documentation hasn't been updated saying that it was 100% tested, or the feature is not reliable and should be removed from documentation12:19
wpwrak_hmm, FLASH_RESET_N comes from the FPGA and goes back into it again (via PROGRAM_B_2)12:19
wolfsprauls/small change/small chance/12:19
lekernelwpwrak_, no, the diode D16 blocks that path12:19
lekernelso when the FPGA asserts the flash reset, it only resets the flash (and not itself)12:20
lekernelboth are active low signals12:20
wpwrak_ah yes, got it.12:20
wpwrak_is the FLASH_RESET_N output open-drain ? (IO_L48N_MIDQ9_1)12:22
lekernelbefore FPGA configuration it is high impedance with weak pull up resistor (inside the fpga)12:24
wpwrak_wolfspraul: (sampled and other weasle words) data sheets usually keep a lot of things rather vague. nothing new there at all :)12:25
lekernelafter FPGA configuration it is push pull... can be made open drain, but shouldn't matter12:25
lekerneltheoretically, we should be able to remove R60, since it is already present in the FPGA12:28
wpwrak_i'm not sure if i'm reading the A4809 data sheet correctly, but the output current seems to be extremely low12:45
wpwrak_well, in some cases. now looking at the graphs on page 7, and things look fairly normal there (i.e. several mA instead of uA)12:47
lekernelah, indeed...12:48
lekernelthat could well be the problem12:49
lekernelyeah 0.05mA12:54
lekernelthat has to pull low a parallel combination of 4.7k and 10k resistor (neglecting the diode impedance)12:55
wpwrak_at low Vdd, though12:55
lekernelwe get low Vdd during power the power ramp that is causing our headaches12:55
wpwrak_ah, i see. yes, then that would be bad12:56
lekernelthat's an equivalent resistor of roughly 3.2k... 0.05mA drops 160mV (!) there12:56
lekernelok we need larger resistor values12:57
lekernelthough the fpga's built-in resistor might cause us some trouble... argh12:57
lekernelor, there's a P-channel version of the reset IC, with 2mA output12:58
wpwrak_would be good to see the signals on a scope. let's hope adam's has at least three working channels :)12:58
lekernelmaybe when Vdd is low enough the flash wouldn't register any command at all anyway13:00
lekerneland if we are lucky we could get away by removing R60 and using a higher R30 value13:00
lekernelfrom the reset IC datasheet: "The value of R0 need to be selected in different application, typical value is 470K&"13:02
lekernelwe are 100 times below that13:02
lekernelnice catch ...13:03
wpwrak_oopsie. 2 orders of magnitude off isn't so nice13:04
lekernelthe FPGA pull up resistor sources 200 to 500 uamp according to datasheet13:05
lekernelthere's still a chance we could get those boards to work :)13:05
lekernelremove R60, use a large R30... might do the trick13:05
wpwrak_worst case, replace U2413:06
lekernelassuming we could find a footprint compatible replacement with the right characteristics13:06
wpwrak_the resistor swapping game is a bit complicated by having a diode there. for rc4, you may want to consider some 74xxx1G logic gate. they're nice and clean :)13:07
lekernelthere's also the option of cutting the FPGA trace to insert a diode to block the on-chip pull-up, but that would be messy13:07
wpwrak_oh there's tons of them ...13:07
lekernelthe logic gate may not work when the power supply voltage is too low13:07
wpwrak_yuo can pick one that goes pretty low. lower than a D+R circuit :)13:08
lekernelwon't they have output current problems too?13:09
lekernelalso, the FPGA pull up resistor only gives 12 to 100 uamp at 1.2V13:09
lekernelthere's a good chance this could work, heh13:10
lekernelaw, remove R60 and use 470K for R3013:10
lekernelthis should hopefully fix all power up issues13:10
lekernel(see IRC log)13:10
awsounds have good news. :-) oaky...let me read them completely first. :-)13:11
wpwrak_lekernel: not so quick ... what's the input leakage current of the FPGA ? (PROGRAM_B_2, to be precise)13:13
wpwrak_(let's hope did something sane there. not like samsung ...)13:14
lekerneloh, it has a pull up too13:22
lekernelso you can remove R3013:22
wpwrak_for similar chips, on digi-key, search for reset, then pick category "PMIC - Supervisors", then type "Simple Reset/Power-On Reset", then narrow down by package and voltage13:22
wpwrak_kewl. it's getting simpler all the time :)13:22
lekernelit's the same pull up as the other pins +/- 20 uamp13:23
wpwrak_and the NOR has some input leakage as well13:24
lekernelaw, so just remove R30 + R6013:24
lekernelNOR has 1 uamp leakage13:25
wpwrak_good. that won't cause problems. neither up nor down.13:25
awlekernel, second..i read very slow. sorry. not completely finished read. :-)13:25
wpwrak_lekernel: and for single gates, the 74AUP1G family is quite nice. works from 0.8 V to 3.6 V13:33
wolfspraullekernel: the R30/R60 change is in addition to keeping the original reset ic + D16 diode, right?13:33
wolfspraulaw: one more thing we are sure about now (lekernel and wpwrak_ please speak up if I'm wrong): we do not need to test any case without D1613:41
wolfspraulD16 is an essential part of the circuit we have in mind, removing it makes no sense at all. we do not need to test that.13:42
wolfspraulalways keep D16 there (in correct polarity of course)13:42
awgood catchs on current driven between fpga inside and reset ic's output analysis. As well as the parallel equivalent resistors(R60//R30), nice analysis!13:42
wolfspraulif the R30/R60 removal works now (for rc3), do we still want another (cleaner?) solution for rc4, or can we keep this solution?13:45
awfirstly, do i just reflash firstly standby image to restore after I replace a R30(470K) and remove(R60)?13:45
wpwrak_wolfspraul: (keeping D16) yes, you want to keep D16 or the rc2 gremlins come back.13:46
lekernelaw, yes, you can test the reflashing first13:47
awor just replace R30 and remove R60 to directly check if rc3 works back well?13:47
wpwrak_wolfspraul: (rc4) i would recommend considering a 74AUP1G08 or 09 instead of the diode-based "wired and". that would provide a cleaner barrier than the diode does.13:48
lekernel1) reflash standby image, check if it works13:48
lekernel2) if it didn't work reflash all the rest13:48
lekernel3) remove R30/60 and check it works _reliably_, i.e. power cycle a few hundred times13:48
wolfsprauland boot13:48
wpwrak_wolfspraul: (rc4) of course, if things work perfectly now, you may not want to take the risk.13:49
wolfsprauland put D16 back in, and no scope13:49
kristianpaulwolfspraul: (cant boot rtems) is not too often, but so far happened two times, at least that i'm aware of13:51
wolfspraulkristianpaul: ok so from your feeling that's in 5% of power on attempts? (that it won't power on)13:51
wolfspraulor 10% or 1%? (just roughly)13:52
wolfspraulin my board maybe 30%, I have a feeling it's a bit higher when the board is warm/hot13:52
wolfspraulI'm not worried if I go somewhere that I won't be able to power it up, but I'm fully prepared that I may have to replug the power a few times. With that in mind it's bearable for me.13:53
awlekernel, wait. you wrote 'remove R30/60'. but i read back above is to 'remove R60 and use 470K for R30'. :-)13:54
lekernelno, remove R30 and R60, do not put 470K back in13:54
lekernelwe figured out later that R30 is already included in the FPGA13:54
awokay. got it. an equivalent resistance as to be R30 role.13:55
wpwrak_lekernel: oh, speaking of the diode's reverse current: it should be about 2 uA at 25 C, 2 mA at 100 C (fig. 4). so on a hot day, you could in fact replace it with a 0R ;-)13:57
lekernelmh, crap14:00
wpwrak_lekernel: since you already have a wired-AND, even without the diode, it may not be much trouble14:00
awlekernel, i just modified xiangfu's script, let me if it's okay for reflash standby only >> http://pastebin.com/J0DPhHxk14:02
lekernelyeah should be ok14:06
kristianpaulwolfspraul: not power on, thats different issue, i meant it load bitstream but wont load rtems.. or stay loading, as is flash we're corrupted,14:07
wolfspraulhow about power on?14:07
kristianpaulits hard to tell, a guess will be unfair, but yes i remenber having this issue, but the no the last month..14:09
wolfspraulok, makes sense14:11
kristianpaulmay be not since jtag let me on a state in wich M1 is electrically power on, is not needed, as just fpga get in a standby state after i flash somthing new on it14:11
wolfspraulI think every board will show it, percentage I am not clear (and never cared much because whether it's 1% or 80%, it needed to be fixed fully anyway)14:11
kristianpauli think there are two issues here, for making product behavior incorrect14:12
wolfspraulwe hope both are 100% fixed in rc3 :-)14:12
kristianpaulthe electrically power on problem, that you're tryin to fix delaying fpga14:12
wolfspraulbut please keep describing14:12
kristianpauland the booting in to rtems problem that also happen !14:12
kristianpauland for end user will be just a booting issue as well14:13
wolfspraulfrom now on Adam will test with a complete boot all the way to rendering14:13
kristianpaulyes, please,14:13
kristianpauli'm sorry i dint describe rtems booting issue before, so fat i tought was a nornmal error percentage after flashing m1 more than 10 times a day...14:14
kristianpaulor may be because a partial reflhash of nor? so if you dont reflash the whole thing it may lead to corruption somwehere?..14:15
kristianpaulwell, just a few guesses14:15
awstep 1):  good, now m1 reconfigure normally, let me see if boot up. :-)14:16
awyeah...can't boot up now...go to remove R30/R60. :-)14:16
wolfspraulkristianpaul: there may be multiple bugs, that's why we need to calmly fix them one by one14:20
wolfspraulotherwise we are a remote group of people, communication is never perfect, and we are all confused by different reports and different things we mean when we report something14:20
wolfspraulfor example in lekernel's list earlier he wrote about 'check that it works', but now Adam is writing about "cannot boot". Do they mean the same thing? works == boots? not sure.14:24
wolfspraullet's see what Adam finds next :-)14:25
wolfspraulwith 'boot' I mean all the way to gui or rendering14:25
wolfspraulbut others may mean different things, or even different things depending on context14:26
wolfspraulwhat do we have? power-on -> fpga reconfigure (?) -> D2 goes off -> middle button -> D2 goes on -> boot -> gui/render14:27
wolfspraulright or wrong?14:27
wolfspraulkristianpaul: the first step after power-on is called 'reconfigure'?14:27
wolfspraulI'm a bit confused about the 're' since it's the first thing after power-on...14:28
awwhen i said 'reconfigure' means D2 dimly lit short time then OFF, when i said that 'boot up' yes i meant the way to gui and D2/D3 is all ON. :-)14:28
wolfspraulok so we use roughly the same terminology14:28
wolfspraulwpwrak_: will R30/R60 impact anything after reconfigure?14:29
wolfspraulmy understanding was that any impact of the R30/R60 change is for reconfigure itself, not after it14:30
kristianpaulyeah, well reconfigure is okay, at least you sort the bitstream is loaded :)14:32
awokay..removed. let's check if reconfigure normally first after power up.14:33
kristianpaullekernel: standy bitstream reconfigure fpga with soc bistream after middle button pressed right?14:33
awgood on reconfiguration stage, but D2/D3 only keeps ON when I pressing SW2. then both D2/D3 is OFF. :(14:35
awthe go both LEDs OFF.14:36
wolfspraulaw: did you reflash only the standby image, or everything?14:36
awi stop now. :-)14:36
wolfspraulI think you should reflash everything.14:36
awi have to reflash everything?14:37
wolfspraulsure I would do that14:37
wolfspraulno point in trying to fix 3 bugs at once14:37
wolfspraulget everything back to the best state we can imagine now14:39
wolfsprauland then test. first power-on, then middle-button, then boot, then render.14:39
awi set 'NOVERIFY="noverify"' , so speed up. :-)14:41
wolfspraulafter reflash, unplug the power from the board entirely, so we start from a known state14:43
awreflash done. power off > power on > can reconfigure > press SW2 > D2 doesn't keep ON....not success on boot14:45
awyes, i plugged off adapter power.14:45
wolfspraulD16 is there and with correct polarity?14:46
awyes, soldered there14:46
awpolarity correctly.14:46
wolfspraulso that's exactly the same as you reported at the beginning14:47
wolfspraulbut this may not be related to R30/R60 anyway, because it's a problem after reconfigure14:48
wolfspraulit's strange though that booting doesn't work because of the diode? maybe it loaded a corrupt bitstream?14:48
wolfspraulif the bitstream is correct, then I wouldn't know how the diode could affect the chances of booting14:49
wolfspraulwe need to wait for lekernel for more input and ideas :-)14:49
wpwrak_(r30/r60 after reconfigure) dunno. i wouldn't think it should, but then i don't know these things too well14:49
wpwrak_i wonder if the flash reset output could glitch during configuration14:50
wolfspraulmaybe looking at the serial console could give us clues?14:50
awwpwrak_, but indeedly your discussion above with lekernel was good and reasonable in tech knowledge well...14:51
wpwrak_aw: you should be able to see glitches on FLASH_RESET_N by probing TP37, with a falling or rising edge trigger14:51
wolfspraulaw: can you press the middle button multiple times?14:51
wpwrak_aw: (see glitches) that is, if there are any :)14:51
wolfspraulbasically now the D2 goes off, and pressing the middle button does nothing, right?14:51
awD2 will show ON in a short time that time is that when I press middle buttun(SW2), then D2 goes to OFF14:53
wolfspraulmaybe it actually boots? how long do you wait?14:53
wolfspraulah no, I think D2 should stay on during the boot, and finally D3 will go on as well14:54
wolfspraulaw: when you press the middle button again (second time), will D2 go on again? or stay off14:54
awD2 will always go ON then OFF after I press SW2.14:55
awit's not right. :-)14:55
wolfspraulbut it does that every time14:56
wolfspraulI think that means it's still running14:56
wolfspraulok, last test14:57
awwpwrak_, yeah..maybe the D16's forwarding voltage doesn't make a good low enough.14:57
wolfspraultry to power cycle, reconfigure, press middle button14:57
wolfspraulsay 5 times, should be enough14:58
wolfspraulI want to see whether it ever boots to gui/rendering14:58
awhmm? no. i stop. :-) it should not like this. :-)14:59
awbad adam. :-)14:59
wolfspraulbut I think the behavior sounds stable now14:59
wolfspraulof course we still don't have a solution15:00
awi need to see like werner's said on glitches later. :-)15:00
wolfspraulmaybe also compare to our earlier rc2 results?15:00
wolfspraulwe tested this circuit before and found it working, or our test back then was completely wrong?15:01
awTP37 should have something to discover. :-)15:01
wolfspraulthen there is werners 74AUP1G08/09 idea, I don't know how hard it is to try that. sounds like that is not an option for rc3.15:01
wolfspraulor a different D16 diode with other specs?15:02
lekernelaw, you completely reflashed your board?15:03
wolfspraulwhat he sees now is that it seems to reconfigure fine (D2 goes off), but then when pressing the middle-button D2 will go on briefly then back off15:04
wolfspraulrepeatedly, so if he presses the middle button again, D2 will come on again briefly and go off again15:04
lekernelyes, it should do that15:04
awwolfspraul, i feel discussions from werner and lekernel is good, just don't know once a corrupt occurred, does flash's rest pin internal or fpga itself doesn't nver restore back more? don't know15:04
lekernelthen turn hard on15:04
wolfspraulno, that doesn't happen15:04
wolfspraulit stays off15:04
lekernelok, leakage current of the diode causing problems i'd guess15:04
wolfspraulaw: if the circuit is stable, there should be no corruptions ever, I'm sure.15:05
wolfspraulso we don't need to worry that much how to recover from a corrupted nor, I think. because that just won't happen in normal use.15:05
lekernelaw, can you try with a 470k R30?15:05
awi can try reflashing all image again to see. second15:06
lekernelno, don't waste time on reflashing15:06
awbefore I try 470K 30, try again. :-)15:06
lekerneldo you have anything on the serial console btw?15:06
awhmm..no time no use serial console. please let me know the baud ratio setting.15:07
awsorry that, long time no use. :-)15:11
wolfspraulgot disconnected15:18
awflow control? 8 bits 1 bit stop15:22
lekernelno flow control15:23
awokay, no parity?15:23
lekernelhave you soldered r30 already?15:24
lekernelserial console is unimportant15:24
awwant to at the same time if you want to see. :-)15:25
wpwrak_lekernel: btw, could FLASH_RESET_N glitch between the start of (re)configuration and when the system should start running ? or is there maybe even an intentional flash reset at the end of configuration ?15:32
wpwrak_lekernel: also, are there any checksums or such in configuration ? i.e., when configuration completes, do we have any knowledge of whether things were loaded correctly ?15:35
awlekernel, can reconfigure but no boot after 470K R30.15:43
wolfspraulaw: I think this is a stable condition now, not bad.15:46
wolfspraulhere is my current understanding:15:46
wolfspraulour best bet circuit right now is with reset_ic, diode, both R30 and R60 removed15:46
wolfspraulbut in this case, for some reason after reconfiguration (successful reconfiguration?), the m1 doesn't boot15:47
wolfspraulfrom here we could go in a number of directions - we could go back to the rc2 and understand why it worked there15:47
wolfspraulyou could dig into suspected glitches15:47
wolfspraulwe could come up with changes beyond r30/r6015:48
wolfspraulwe can go back and remove d16 (which makes it boot), but probably that will expose us to the old reconfigure problem15:48
wpwrak_aw: when will you get more boards ?15:48
wolfspraulwe could see whether the serial console holds any clues15:49
wolfspraulor lekernel or wpwrak_ could come up with any other idea :-)15:49
awguess i need to go there to solder myself to get 2 ~ 3 pcs next Monday15:49
wolfspraulwhich way to go?15:49
wolfspraulaw: I think you should definitely go back to the old rc2 you had with reset ic + diode, and see whether that one fully boots15:50
awmrt or scooter15:50
wpwrak_wolfspraul: first, i'd like to understand a little better how all the signals are supposed to behave15:50
wolfspraulno no, not 'which way to go to the factory' :-)15:50
wpwrak_hehe ;-))15:50
wolfspraulwhich way to go in our analysis & fix15:50
wolfspraulI definitely want to know whether the old rc2+reset_ic+diode boots or not15:50
wolfspraulthat was the basis for our design decision, but we may have overlooked several issues there, I guess15:51
wolfspraulthen we should also connect the serial console on the rc3 adam has now, just to see if we are lucky and anything comes up there15:51
lekernelaw, record flash reset and fpga program_b with a 2-channel scope, at 1) power up 2) boot time. use 1:10 probes if you are worried about capacitance.15:51
lekernelwpwrak_, there is a flash reset after configuration with the soc bitstream15:52
lekerneland after each soft reboot15:53
wpwrak_lekernel: at such low currents, i'd be VERY worried about capacitance :)15:53
awlekernel, alright...I'll do this tomorrow morning and links given here.15:53
wpwrak_lekernel: (reset) perfect15:53
wpwrak_lekernel: does PROGRAM_B_2 do anything after the configuration ?15:53
lekernelno, it should not15:53
wpwrak_lekernel: also good. will it become push-pull after configuration ?15:54
awlekernel, is this descibe more? http://en.qi-hardware.com/wiki/File:Configuration_sequence.png15:55
lekernelprogram_b is a dedicated input with no change when the fpga is configured15:55
lekernelno this has nothing to do here15:55
wpwrak_lekernel: (program_b_2 input only) hmm, then the reverse leakage current shouldn't matter15:55
lekernelwpwrak_, what can happen is that when the soc boots, it resets the flash, then the leakage diode current pulls program_b low and clears the fpga15:56
lekernelaw, scope traces first15:56
lekernelthen we will know15:56
lekernelinstead of just guessing ...15:56
wpwrak_agrees. scope next :)15:57
wpwrak_lekernel: (clear the fpga) so there are no checksums or such in configuration ?15:58
lekernelwpwrak_, what does it have to do with checksums?15:58
lekernelwhen program_b is pulsed, the fpga is cleared, period15:59
wpwrak_oh, like that. i see.15:59
lekernelthis has absolutely nothing to do with checksums15:59
awalright...let me measure now...then i sleep. :-) :-)15:59
lekernelaw, how many channels does your scope have?15:59
awso before I scope, should i remove 470K R30?15:59
lekernelcan you measure flash_reset_n, program_b and 3v3 at the same time?15:59
awtwo only15:59
lekernelno, leave it there15:59
wpwrak_lekernel: yes, then we would have a reverse current scenario indeed16:00
lekernelok then skip 3v316:00
kristianpaulwhy serial console is unimportant?, it could tell if flickernoise loaded or not16:00
wpwrak_wolfspraul: when you come across some money, get adam a 4 channel scope :)16:00
wolfspraulthe other 2 channels are in Buga :-)16:01
wpwrak_wolfspraul: ideally, one with lots of memory. alas, the good ones are expensive. 10+ kUSD16:01
wpwrak_kristianpaul: seems that lekernel it pretty sure there's nothing alive in the fpga. if the reverse current scenario is what's happening, that would indeed be the case.16:02
kristianpaulokay,so... lets asume that :)16:03
wpwrak_hmm, 26 C in taipei. leakage should be around 2-4 uA then. still sub-critical, at least in theory. one thing to keep in mind: if it suddenly starts to work, that may be because it gets colder for the next ~4-5 hours.16:05
wolfspraulwhat if m1 runs at a nightclub in 45 degree Bangalore?16:07
wolfspraul(just joking... we don't need to discuss this now :-))16:07
wpwrak_wolfspraul: you should let an M1 roast out in the sun for a bit and then see how well it works ;)16:08
awhi, interesting things happens again. once my prober connected to TP then m1 get boot up!16:15
wpwrak_i was afraid something like that would happen ...16:16
wpwrak_aw: can you identify if a single probe already makes a difference ?16:16
awfrom my views seeing flash reset and program_b, they are both synchronized at the same rising pulse @ 2.5ms :-)16:17
wpwrak_aw: note: please try a few times. i'd say at least 5 times, better 10. this can easily be a statistical problem now, and we'll need a reasonably large sample size.16:17
awyeah...yes..try program_b or flash reset pin caused that..second. :-)16:17
wpwrak_(same pulse) @2.5 ms = the pulse duration ? or the time after powering up ?16:18
wpwrak_if both show a relatively fast pulse, that would be the diode's evil work16:19
awthe time after powerin g up. they both are the same. :-)16:19
wpwrak_how long is the pulse ?16:19
wpwrak_maybe just post a screenshot16:20
awplease see this firstly , the CH1 is program_b16:20
lekernelaw, are you using a 10:1 probe?16:20
awafter a rest ic's delay time (~= 200ms) , program_b goes from LOW to HIGH.16:21
wpwrak_kristianpaul: do you have a script that downloads a screenshot from the scope and puts it on downloads.qi-hardware.com/people ? might be useful for adam16:21
lekernelaw, why is there a glitch on PROGRAM_B in the beginning?16:21
wpwrak_aw: ah, you;'re already there. great :)16:21
kristianpaulwpwrak_: nope i dont, i just visit by web16:21
lekernelthe first pulse16:22
lekernelwhere you put the cursor btw16:22
awwpwrak_, that DONE(CH2) is initalize after power on then goes LOW...then once fpga reconfigure works done, that DONE pins goes high to tell it's done. :-)16:23
wpwrak_kristianpaul: ah, he's got a TDS1012. that one may not even have ethernet. i thought he had a scope similar to yours16:23
awlekernel, yeah..moment...let me change. ;-)16:24
wpwrak_interesting ... 200 ms load time (to DONE), and 200 ms reset delay by the reset chip16:25
wpwrak_lekernel: do PROGRAM_B_2 is edge-triggered, not level-triggered ?16:26
lekernelit's level triggered16:26
awdo you want me to level triggered? guess 200ms, they should be the same.16:27
wpwrak_then i don't understand what i'm seeing. looks as if PROGRAM_B_2 was low all the time, thus constantly resetting, yet the FPGA thinks it finishes configuration (indicated by DONE)16:27
wpwrak_something doesn't compute :)16:27
wpwrak_aw: (level triggered) that was about how the FPGA works, not your scope setup16:27
lekernelaw, on your scope, the first is PROGRAM_B and the other one DONE?16:28
awlekernel, yes. sorry that ...now i changed to 1:10, then can't boot more. :(16:28
lekernelaw, ok, no, this is good!16:28
awlekernel, yes, CH1 is program_b, CH2 is DONE pin.16:29
lekernelat least the measurement is not making that ultrapesky bug disappear16:29
lekernelok, then wpwrak_ is right, DONE shouldn't go high when PROGRAM_B is low16:29
wpwrak_aw: just to check, can you please tell us the TP numbers you connected to ?16:29
awwpwrak_, program_b(TP36), DONE(TP35), flash Reset(TP37)16:30
awbe noticed this http://downloads.qi-hardware.com/people/adam/m1/pic/rc3_2f_ch1-PROGRAM-B_ch2-DONE_no_D16.JPG was scoped this afternoon. not now. :-)16:31
wpwrak_so CH1 is on TP36 and CH2 is on TP35 ? trigger is ... on CH116:31
wpwrak_ah, no D16 !16:32
wpwrak_now, please do all this again, but with D16 in place :)16:32
awwpwrak_, exactly16:32
awyes, no D16.16:32
lekernelno more tests without d16 please16:32
awi show this just let you know program_b & done relationship.16:32
wpwrak_lekernel: of course, even without D16, the pattern looks weird, with PROGRAM_B_2 low and things still (apparently) completing16:34
lekernelrhaa... apparently the s6 needs INIT_B to be driven low as well to delay configuration16:34
lekernelthe amount of peskiness that lies into this configuration process is incredible16:35
wpwrak_lekernel: so the whole contraption around D16 won't work ?16:36
lekernelit can fail if the fpga attempts to read the flash while it's still in reset16:36
lekernelaw, add a second diode between the output of the reset IC and INIT_B (accessible through R157)16:37
Action: wpwrak_ searches for INIT_B ...16:37
lekerneloh, and it'd be much better if we could get a reset IC with more current sink capabilities and/or diodes with less leakage current16:38
wpwrak_lekernel: reset ic should be no problem. for the diodes, you'd likely have to trade Vf for Irev. the only "clean" way out of this is probably a 1G gate16:39
lekernelbtw, that init_b vs. program_b discovery explains why adding a capacitor (instead of the reset ic) didn't work either...16:43
lekernelit's amazing the time we spend on small issues like that16:43
lekerneland extremely frustrating16:44
lekernelaw, all further tests must be done with a diode to INIT_B16:44
wpwrak_lekernel: 74AUG1G have nice features like an input leakage of max. +/- 0.75 uA, and even at Vcc = 1.1 V, they can sink some 1.1 mA. they're nice chips to know. they lack the coolness of just solving a tricky problem with a few passive elements, but they do a lot to make things more predictable.16:45
lekernelas your scope trace shows, holding PROGRAM_B low does nothing ...16:45
wpwrak_(trace) good. same result as without D16. so D16 may be off the hook for now.16:46
lekernelwpwrak_, if that stupid reset IC was able to sink more than a ridiculous 500 uamp, the diodes (with additional external pull ups) would work just fine16:46
wpwrak_lekernel: you could still run into trouble with the reverse current16:47
lekernelon a ~5K impedance, the reverse current wouldn't be able to cause much trouble, would it?16:48
lekernelaw, so 1st one is program_b and the other flash reset?16:49
lekernelor is it the other way around?16:49
awscoped after power up16:50
wpwrak_lekernel: okay, with a 5 k pull-up, you can probably kill it :)16:50
awso you can use program_b as reference base16:50
wpwrak_aw: btw, it may be good to set the scope's acquisition to peak detect16:51
lekernelaw, now one problem. program_b does nothing. we must use init_b instead16:51
lekerneland another problem - init_b becomes active after configuration, so we must use another diode16:51
awall you both talks is like this http://en.qi-hardware.com/wiki/Milkymist_One_Power_On_Off_Sequence#Power-On_Sequence_Precautions_for_FPGA[5].16:52
lekernelwpwrak_, I also have heard horror stories about FPGAs not configuring correctly because of rise time too slow on their external control signals. I don't know if Xilinx improved this, but because of that I'm for small pullup values.16:53
wpwrak_lekernel: still haven't found INIT_B or R157 :-( on which sheet are they ?16:53
lekernelwith the fpga schematics, on bank 216:53
lekernelat the top right of bank 216:54
awwell...i get to sleep though, guys ;-)16:55
wolfspraulsure, 'night16:55
lekernelwpwrak_, the xilinx reference designs have 4.7k external pullups on program_b and init_b16:55
wpwrak_aah, got it. thanks ! nicely hidden :)16:55
awlet me know if somethings i can help tomorrow. cu16:55
lekernelI'm for trying to keep those pullups, and having a reset IC that has some serious current sink capability16:56
wpwrak_sounds reasonable16:56
lekernelany reset ic you could recommend off the top of your head?16:57
lekernelit's in sot-2316:57
wpwrak_you'll need at least 1 mA, right ?16:57
wpwrak_let's first check if the one you have isn't good enough after all16:58
lekernelso, this thing is going to drive: flash reset (10k), program_b (4.7k) unless we manage to cut the trace when reworking the board and init_b (4.7k)16:58
wpwrak_i haven't used reset chips yet, so there's none i "like from experience". but there's a ton of choice at digi-key. so i'm not worried about finding something decent, if necessary16:58
wpwrak_if i interpret the A4809 data sheet correctly, the sink current is very low at low Vdd, but gets reasonable when Vdd increases17:00
lekernelthat's 1.9k equivalent resistance, which needs at least 1.7mA at 3.3V17:00
wpwrak_okay, with tolerances that's 2 mA absolute minimum17:01
lekernelyeah and we must also account the fpga internal pullups btw17:01
lekernelthose will add 0.2 to 0.5 mA/pin at 3.3V17:02
lekernelso worst case 1.5mA total17:02
wpwrak_4 mA then17:02
lekernelwhich brings that minimum current for the reset ic to 3.5mA17:02
lekernelor 4 if you want extra safety17:03
wpwrak_i totally love extra safety ;-)17:03
lekernelworst case we will use a relay instead lol17:03
wpwrak_i'm not sure we really need to worry about the early ramp. as long as we get a proper reset when we approach 3.3 V, we should still be fine, right ? maybe with the possible exception of freak flash corruption17:04
wpwrak_(relay) naw, they bounce :)17:04
wpwrak_the flash corruption scenario would be that we have Vdd high enough for the FPGA to try to talk to the flash, and Vdd high enough for the flash to be able to change its content, and Vdd too low for the reset chip to pull enough17:06
lekernelyeah, the output current of our reset ic approaches 10mA17:06
lekernelthough what the heck is VDS?17:06
wpwrak_figure 10 ?17:06
wpwrak_VDS is the voltage on the output17:07
wpwrak_oh wait. relative to Vdd :)17:07
wpwrak_err no, to ground17:07
wpwrak_page 11, figure 317:07
wpwrak_hmm. still looks suckish.17:08
lekernelI'm looking at this atm: http://www.technorise.ne.jp/doc/ait/A4809-v10.pdf17:08
lekernelah, page 12 :)17:09
wpwrak_a have rev 1.3 (found by google)17:10
wpwrak_for Vdd = 3.3 V, the closest approximation seems to be figure 12 on page 7 (of rev 1.3): Vdd = 3.0 V17:14
wpwrak_if we assume Vds = 0.5 V (you said Vil(max) = 0.6 V, right ?), then we get about ... 8 mA17:15
lekernelVds should be lower than that17:16
lekernelwe have to take into account the drop of the diode17:16
wpwrak_urgh. right.17:16
lekernelalso 0.6V is for the flash, I'm trying to find what the FPGA needs17:16
lekernelshould be somewhere in that17:16
lekernelfor PROGRAM_B and INIT_B17:17
wpwrak_hmm, what diode current shall we assume ? 2-3 mA ?17:18
wpwrak_let's say 3 mA. then Vf should be < 200 mV17:18
wpwrak_so we get Vds = 0.3 V17:19
lekernelhave you found the maximum low level voltage for the fpga?17:19
lekerneli'm still searching through this big datasheet17:19
wpwrak_no, i hope you're quicker than me ;-)17:19
wpwrak_besides, i don't think FPGA.Vil(max) will be higher than NOR.Vil(max)-200 mV. but i'm sure you'll set me straight if my guess wasn't right ;)17:20
lekernelwpwrak_, INIT_B will need to be connected through a diode17:21
wpwrak_okay, then it matters. darn.17:21
lekernelok, Vil is either 0.8V or 0.7V... can't figure out, but the flash is the limiting factor anyway17:21
lekernelthose are the numbers for the LVCMOS33 and LVCMOS25 I/O standards17:22
lekernelso let's assume Vds = 0.3V17:23
wpwrak_good. i was just about to ask which of the gazillion I/O standards it was ;-))17:23
lekernelI'm not actually sure17:23
wpwrak_okay. 0.3 V ... A4809 data sheet rev 1.3, page 717:23
lekernelthose are for the configurable I/O pins, not for the fixed function pins17:23
lekernelbut it'd make sense to assume the fixed function pins use either LVCMOS33 or LVCMOS2517:24
wpwrak_figure 12 says that, with VDD = 3.0 V, we can expect something like 5-6 mA17:24
lekernelno, we are using Detector Threshold=2.7V17:24
lekernelso figure 10 (not 12) is relevant17:24
wpwrak_fig. 10 only goes up to VDD = 2.0 V17:25
wpwrak_for VDD = 2.0 V, fig 10 and fig 12 are similar. so i would assume the characteristics of the output transistor are comparable17:26
wpwrak_i.e., i'm currently looking at the performance in the 200 ms after crossing the threshold17:26
wpwrak_so i think the chip should be barely adequate. you don't have a lot of headroom, but it should be sufficient.17:28
lekernelif we used 10k pullups (instead of 4.7k) the minimum current for the reset IC would be 2.5mA ... this should give more margin on the reset IC side17:28
lekernelso what would you think of:17:29
lekernel1) we keep the current reset IC17:29
wpwrak_right now we have 4.7 k plus 10 k, so it's already a bit friendlier17:29
lekernel2) we use a 10k pullup on INIT_B and PROGRAM_B (instead of 4.7k)17:29
wpwrak_ah, you mean R157, okay17:30
lekernel3) we add a diode between the output of the reset IC and INIT_B17:30
lekernel4) we remove R60 (the pullup on the flash reset) since diode leakage and fast rise time do not matter here17:30
wpwrak_what are the functions of PRORGAM_B_2 and INIT_B ? you said INIT_B becomes an output after configuration ?17:31
lekernelyes, it becomes an open drain output17:31
lekernelwhich might pull low17:31
wpwrak_under what conditions does it pull low ?17:31
lekernelBefore the Mode pins are sampled, INIT_B is an17:31
lekernelinput that can be held Low to delay configuration.17:31
lekernelAfter the Mode pins are sampled, INIT_B is an17:31
lekernelopen-drain active-Low output indicating whether17:31
lekernela CRC error occurred during configuration:17:31
lekernel0 = CRC error17:31
lekernel1 = No CRC error17:32
wpwrak_aah !17:32
lekernelalso this doesn't say what happens while the configuration take place. are there glitches on INIT_B?17:33
wpwrak_what would happen if you connected INIT_B to PROGRAM_B_2 ?17:33
lekernelI don't really want to know :) diode is safer, no?17:33
lekernelplus it'd hold the flash in reset17:33
lekerneland I'm not sure we could later deassert INIT_B e.g. from JTAG17:34
lekernelso not using the diode looks like murphy bait17:34
Vaati_what chip are you discussing?  is it something in the milkymist itself ?17:35
lekernelVaati_, fpga, flash and reset ic17:35
Vaati_lekernel: whats the manufacturer of the fpga17:35
lekerneland yes, those are giving us inordinate amounts of trouble to get the milkymist devices to work reliably17:35
kristianpaulVaati_: you can see http://en.qi-hardware.com/wiki/Milkymist_One_RC3_BOM17:36
wpwrak_(JTAG) yeah, that's the big question. PROGRAM_B_2 = INIT_B looks vaguely useful for recovering from glitches causing a CRC error. but of course, if you then can't fix the flash via jtag, that would suck more than anything else.17:36
lekernelwpwrak_, for rework, I think it should be easy to use a non-SMD diode between the output of the reset IC and the R157 pins17:36
lekernelwpwrak_, I have read somewhere (it seems) the FPGA should already contain logic to retry configuration after failed CRCs17:37
lekernelI don't really want to mess with it17:37
lekernelwpwrak_, what would you think of keeping R60 and adding a capacitor between flash reset and ground?17:39
lekernelor not keeping R60 and still having the capacitor, which would charge through the fpga17:40
lekernelit should keep reset low during the very early stages of power up, before the reset IC takes over17:40
wpwrak_(retry logic) very good !17:40
lekernelbut at the same time it should be small enough not to delay the flash too much, otherwise the fpga will attempt to read from it when it's not ready ...17:41
wpwrak_(no mess with it) yeah, feels unsafe17:41
lekernelbut maybe that's overkill and cause more problems than it solves17:41
wpwrak_le't check the diode .. at 25 C, Irev would be about 2.5 uA. at 100 C more like 2.5 mA. now, how to interpolate ?17:42
wpwrak_the cap would also make the reset voltage crawl very slowly from a clean low to a clean high.17:44
lekernelyeah, let's try without first17:45
lekerneland without R6017:45
roh 17:47
lekernelroh, ?17:47
wolfspraulso we have a new plan?17:47
wpwrak_hmm, for Irev, we'd mainly work against R30 = 10 kOhm. to stay on the safe side of Vih(min), we shouldn't drop more than 100 uA17:47
wolfspraulI am curious about one thing - why did we not notice this in our rc2 tests? I mean the need for those additional improvements.17:48
wpwrak_that's 40 x the T = 25 C and 1/25 x the T = 100 C value. tricky.17:48
Action: wpwrak_ goes looking for a Irev vs. T curve17:49
lekernelwolfspraul, I guess because a consequence of Murphy's law was that the flash we used for the test was fast to come out of reset and the FPGA was slow to begin reading from it17:49
wolfsprauljust want to make sure we have at least a theory for everything we see :-)17:49
lekernelor... did we use the exact same reset IC?17:49
lekernelor something with less delay?17:49
wolfspraulI don't want to do too much history digging, I just asked to make sure our new theories are still in line with old discoveries.17:50
wolfspraulbut it seems you are not worried about that, so whatever we saw in rc2 is still in sync with the new realizations17:50
wolfspraulthat's good then!17:50
wolfspraulso reset ic stays, D16 stays, and now a few more things on top17:51
wpwrak_(T vs. Irev) we're probably good up to 75 C (according to The Circuit Designer's Companion, giving 1N4148 characteristics)17:51
lekernel1N4148 is a PN pure silicon junction, does such a curve also apply to a Schottky junction?17:52
wpwrak_lekernel: i checked the schottky section and he didn't warn of any perversions there17:52
wolfspraulok I try to summarize, see whether I followed the discussion correctly17:56
wolfspraul1) 10k pullup on init_b and program_b (instead of 4.7k now)17:56
wolfspraul2) add diode between output of reset_ic and init_b17:56
wolfspraul3) remove r6017:57
lekernel(2) with negative terminal towards the reset IC17:57
wolfspraulwhat about R30?17:57
wpwrak_(list) that's what i have too17:57
lekernelR30 is the pullup on PROGRAM_B, so you already mentioned what should be done to it17:58
wpwrak_R30 needs to stay. else D16.Irev may cause FLASH_RESET_N to PROGRAM_B_2 contamination17:58
lekernelwolfspraul, ok for your 3 points. do you mail Adam and the list?17:59
wpwrak_(stay) changed a little, to 10 kOhm. but not higher. and not removed.17:59
wolfspraulAdam will check the backlog17:59
wpwrak_better write a mail with the final verdict :)17:59
wolfspraullekernel: you mentioned earlier that it is frustrating and depressing we spend so much time on these little things18:01
wolfspraulbut in my experience it is totally normal, not much at all, and not a hopeless case or anything18:01
wolfspraulI'm not making gloom or doom predictions, but these things pop up, and they need to be addressed. it should not be frustrating.18:02
wpwrak_plus, i wouldn't call ~1 day "so much time" ;-)18:02
wolfspraulit's a complex board and nearly impossible to get the hundreds (maybe thousands) of details right immediately18:02
wolfspraulno not at all18:02
wpwrak_wolfspraul: we've seen worse, haven't we ? (-:C18:02
wolfspraulI'm just speaking from my experience and comparing with successful and failed projects.18:03
wolfspraulrc1 set the bar very high, it was an _excellent_ first shot18:03
wolfspraulfrom there on it continued very well, with rc2 (I believe 0 regressions from rc1), now rc3 (again so far it seems no regressions, and many improvements)18:03
wpwrak_(complex board) indeed. it's a little PC. i also like that the resolution makes sense. it's not just a shot in the dark.18:04
wolfspraulI still do expect some more issues to pop up on rc3, I have to say18:04
wolfspraulI'm not saying this to annoy people or to be the wise guy doing nothing.18:04
wolfspraulit's just realistic to expect that, next week when we test all 90 boards18:04
wolfspraulthere will be something18:04
wolfspraulso... with the latest great of very good ideas for the bootup problem, let's see what Adam reports tomorrow18:05
wpwrak_have things like DMX and MIDI seen any major testing yet ?18:05
wolfspraullatest round18:05
wolfspraul'major' is hard to define18:05
wolfspraulAdam did a number of electrical tests, got some very long cables, got loopback cables, etc.18:06
wolfspraulSebastien has been using DMX for performances18:06
wolfspraul'major' as in hundreds of people having used it with hundreds of devices - no18:06
wpwrak_(performances) okay, very good18:06
wolfspraul'major' as in we tried to do a good job internally - yes18:06
wolfspraulso yes, there could be surprises in midi and dmx, but right now I'd say what we have is not bad18:07
wolfspraulwe need more customer feedback before committing resources on tracking something specific down18:07
wpwrak_one customer issue you'll likely hit is MIDI-over-USB. this seems to be quite popular these days, also with people attaching things to their iGadgets.18:08
wolfsprauldon't mention USB in the presence of Sebastien18:08
wolfspraulrealistically those things have to wait18:08
wolfspraulI'm just being realistic18:08
wolfspraulI will throw myself behind marketing and selling the product on what it can do today, its strengths18:09
wolfsprauland then we invest every penny back to make it better18:09
wolfspraulso realistically - do not expect midi over usb to work in the next few months18:09
wolfspraulSebastien will correct me if I'm wrong...18:09
wpwrak_so what's the plan when those things come up ? just an excuse ? an ETA for a solution ? a work-around ?18:10
wolfspraulthat's why I keep jtag-serial in every unit, I am hoping to attract some serious new contributors, at least I will try18:10
wolfspraulwe are collecting feature challenges here http://en.qi-hardware.com/wiki/Milkymist_One_marketing#Feature_Challenges18:10
wolfspraulI can add midi over usb :-)18:11
wpwrak_(plan) ah, or hope for someone else to come up with an answer :)18:11
wolfspraulno it's fine, I think we need to communicate effectively18:11
Action: roh has a plan. barbecue. (actually i am getting pulled away to one. bbl)18:12
wolfspraulthere is no point in getting stuck on things that don't work18:12
wolfspraulso I'm very frank in the "does not work list"18:12
wolfspraulinstead, I want to focus on what works18:12
wolfspraulroh: enjoy barbecue!18:12
wpwrak_i think something along the lines of "we don't support MIDI-over-USB yet, but you could use the following low-cost/widely-available true MIDI keyboard/whatever ..." would help18:12
wpwrak_at least it would remove a blocker for people who are serious18:13
wolfspraulrefresh the wiki :-)18:14
wolfspraulmy main concern on a run like rc3 are regressions18:15
wolfsprauland it seems so far we have zero, which is how it should be but which is also great18:15
wolfspraulI'm not so worried whether all our improvements are a hit, or whether we discover new problems18:16
wolfspraulthis is my success gauge18:16
wolfspraulwhen a project starts to accumulate regressions, then it's really serious18:16
wpwrak_yeah. that's a sign of loss of control.18:17
wolfspraulat least then I may quickly not know how to continue, because obviously the foundations of the engineering work are flawed somehow18:17
wolfspraulwpwrak_: thanks a lot for lending us a helping hand on the bootup problems! very appreciated!18:20
wolfspraulI'm anxious to see Adam's new reports tomorrow :-)18:20
wpwrak_you're welcome. always fun to stick my nose into something tricky :)18:20
wolfspraulunfortunately Adam cannot follow at this speed on understanding the thought process and reasoning for the changes, but that's OK18:21
wolfspraulso he will just try it all tomorrow and give us new input data points...18:21
wolfspraulwe are a team after all, so the most important for me again is that he is in an excellent position to do a good testing job for the 89 boards that will soon flood his apartment18:22
wolfspraulthat's going to be a mess :-)18:22
wpwrak_let's hope the inputs are all along the lines of "it works now" :) else, it's back to the drawing board18:22
wpwrak_(89 boards) yeah, i don't envy him ;-)18:23
wolfspraulJon is in Taipei soon, and I suggested to Adam I send him for help18:23
wolfspraulthat was kindly rejected :-)18:23
wpwrak_and tuxbrain can probably share the sentiment :)18:23
wpwrak_hehe ;-)))18:23
wolfspraulwhich I can understand18:23
wolfspraulI wouldn't want to send myself for help either18:24
wpwrak_who rejected ? adam or rejon ?18:24
wolfspraulat 40 it was still OK, but with 90 boards that's going to be quite some stress18:24
wolfspraulno Adam18:24
wolfspraulbecause of course Jon will not be a great help18:24
wolfsprauljust sitting around piles of stuff. then Adam has two problems. the boards & Jon.18:24
wpwrak_yeah. by the time he'd be properly trained, most of the boards would be tested already18:25
wolfspraul90 is really tough already. if this is all successful and sells well, and the next run is 160, then we may have to rethink his home office setup.18:25
wpwrak_he knows his M1 reasonably well, though. also managed to solve all his flashing issues at fisl. all he really needed from me was my mouse ;-)18:26
wolfspraulbut step by step, now is this run of 90/80 first18:26
wolfspraulI dont' know exactly when Jon arrives in Taipei18:26
wolfspraulif it is after Adam has most of the chaos under control, the visit may still make sense18:26
wolfspraulit depends on how many reworks are needed, and how the tests are going18:27
wolfspraulthe problem is not to think through the process if everything goes smooth18:27
wpwrak_he could finally get that L19 (?) rework, too18:27
wolfspraulthe problem is to think through the process if there are massive problems with the first 20 boards18:27
wolfsprauland different problems, so there is one pile here, one pile there, etc.18:27
wolfspraulso when things go bad, that's when you know whether your testing setup was robust or not18:28
wolfspraulI spare everyone the stories from the famous Openmoko production lines...18:28
wpwrak_does adam live alone ? or will have have to declare some restricted areas ? :)18:28
wolfsprauldon't know exactly, last time he had a sub-tenant renting a room, his apartment is quite big actually18:29
wolfspraulthere are enough options18:29
wolfspraullet's hope things go smooth18:29
wolfspraulI'm sure Adam hopes so too :-)18:29
wpwrak_oh, openmoko production. so much fun. first, the suspense ... when will they produce ? have they already ? who knows the results ?18:29
wolfspraulotherwise his apartment will quickly turn into a moon landscape18:29
wpwrak_then the sherlock-holmes-like discovery of what exactly happened18:30
wolfspraulthis rework so far still sounds manageable, let's hope it works18:30
wolfspraulI mean the new diode & pullup18:30
wolfspraulif he can completely verify it tomorrow he may even tell the factory to do it on the other 89 boards18:31
wpwrak_then the chaotic struggle with somehow patching up the bugs. some with sequels and sequels of sequels. remember how long it too to finally find out what LED and transistor configuration our freerunners has ? was it half a year ? a year ? longer ? :)18:31
wolfspraulso that's an important thing actually18:31
wolfspraulwell the project was out of control18:31
wolfspraulthat's what I try to avoid here18:31
wolfspraulonce you are in that situation you can only pray that one day you will be back in control18:32
wolfspraulnot fun18:32
wolfspraulso, back to us. in a perfect world adam can confirm the final solution tomorrow, and enlist the smt factory's help in the rework on the other 89 boards.18:32
wolfspraulthat would be ideal18:32
wolfspraulif we are not that fast, the boards go back to his place and then most likely he will manually rework whatever we eventually come up with18:33
wolfspraulunless the rework is so difficult that it would better be done at the factory, which means ship back and forth, etc.18:33
wpwrak_(diode & pullup) so far, everything very civilized, yes. we had one wrong try, but then sebastien found INIT_B, and we now have a good consistent theory for the next try. and all fairly quickly and with swift, useful feedback. not days of puzzlement.18:33
wolfspraulthose kids at the factory are also unbeatably fast and precise, of course. another thing to consider.18:34
wolfspraulso getting this settled tomorrow would be awesome18:34
wpwrak_dunno how hard it is to find a diode. if adam has some of the D16, an option would be to just add that, plus a wire18:35
wpwrak_else, he needs to find some suitable replacement on short notice (i.e., go to the electronics mall and just buy a few diodes). shouldn't be horribly difficult, but needs review to make sure they don't add funny surprises.18:37
wolfspraulsure. Taipei is not Shenzhen, but it should be no problem.18:37
wpwrak_(funny surprises) like that monster we had in GTA02. i think you were already there when that happened, weren't you ? the XXXL diode for the USB reset.18:38
wolfsprauldon't remember18:38
wpwrak_(taipei) i think i could even find the shops ;-)18:38
wpwrak_wolfspraul: (gta02 diode) it was a similar circuit to the one we have in M1: the system reset (shared by various components) was fed with a diode to the USB side, to make sure the pull-up was disabled while the CPU was in reset.18:39
wpwrak_wolfspraul: now, the diode was something to behold. it was also a schottky. but designed for high-current use. i think it could handle something like 10 A. what we really needed was maybe 1 mA or even less. that power diode was HUGE. plus, it has a completely insane reverse current. several mA even under favourable conditions.18:41
wpwrak_wolfspraul: so what happened was that the system reset was pulled down via the reverse current going though this diode and the board never made it out of reset. that is, unless you remove the monster.18:42
wpwrak_wolfspraul: so a lot of finicky rework was done. this story has a sequel. we then redesigned the whole mess. a proposed a solution with a pair of 74xxx1G gates.18:44
wpwrak_wolfspraul: that solution worked beautifully. shortly thereafter, i moved to HXD8. there, we found the need for something similar (not entirely sure if it was really necessary or whether we just thought it was). so we just copied the solution from GTA02, which we already knew was good. so far, so good.18:45
wpwrak_wolfspraul: then the day of making our first prototype run after the death of fiwin and the repatriation of HXD8 to FIC+Openmoko approached. a few days before, i thought i'd ask our hw team for the BOM. not quite sure why ... maybe i needed some information, or maybe i just thought i hadn't heard enough mentioning of the BOM.18:48
kristianpaulah, Dash Express, now i see from where some ideas came from :-)18:48
wpwrak_wolfspraul: the answer was "just a moment". then the team developed a level of activity reminiscent of a termite hill being peed upon.18:49
wpwrak_wolfspraul: after politely inquiring after a while how things were going, i got the truth: so far, no BOM had existed. but there were bits and pieces scattered all over the place. much later that night, i got a first draft of a consolidated bom.18:50
wpwrak_wolfspraul: i think i also asked then whether we had the parts :) well, to make a long story short, soon thereafter, the help of FIC sourcing was enlisted, to get us the things we didn't have yet18:51
wolfspraulnow we know what a well run organization we have today...18:52
wpwrak_wolfspraul: we then had two parts of the BOM - the one where we had the parts or were certain we'd have them, and the one with the parts that were still unknown18:53
wpwrak_wolfspraul: then, i think less than a week before SMT, the bomb dropped.18:53
wpwrak_wolfspraul: there were several components with a lead time measured in weeks if not months. they included some filters, the LCMs, and ... those 74xxx1G chips.18:54
wpwrak_wolfspraul: now, back when i had designed that reset circuit, rookie that i was, i had used digi-key stock as my guide for what are "safe" components (in terms of sourcing)18:55
wpwrak_wolfspraul: so i found it a little surprising that these things would all of a sudden be so terribly hard to get. had i made a grave mistake ?18:55
wpwrak_wolfspraul: well, i went back to my cubicle, chased the bugs away (FIC HQ was crawling with vermin), and checked at digi-key. lo and behold, they had thousands of these chips in stock. i also found some of the other "impossible" items, or very similar replacements.18:57
wolfspraulyou can discard that sourcing input (as you know by now)18:59
wpwrak_wolfspraul: in the end, i got sean's credit card and did a bit of shopping. two days later we had those items with a supposed lead time of months. we also got the lcms. from mouser, at the cost of a small car. all on liane's credit card :)18:59
wolfspraulit was more due to incompetencies within the company and parent company, not a real outside problem18:59
wolfsprauldigikey is a good guide, first of all18:59
wolfspraulbut sourcing is a long story, as you know modules are very tough, some things like LCM are tough, rf baseband chips, etc. etc.19:00
wolfspraulI feel pretty good now about the simple 'availability' part of sourcing, I am more worried about iqc nowadays (incoming quality control)19:00
wpwrak_wolfspraul: yeah, eventually i found out what had happened: FIC sourcing has been specifically ordered not to go to digi-key, because there were too expensive, but to try to get things from the official distributors, if possible, free samples19:00
wpwrak_wolfspraul: that little stunt with bypassing FIC sourcing apparently caused some bad blood inside FIC :) so we weren't supposed to repeat this19:01
wpwrak_wolfspraul: but sourcing also got a bit more agile afterwards :)19:01
wolfspraulcalling it a day, 3 am here19:03
wolfspraulI'm getting old, I guess :-)19:03
wpwrak_wolfspraul: (lcm) that was the Sony PSP display. so there were actually lots of them at distributors. i don't quite sure what had happened to our supply there - either we forgot to order or the supplier had let us down. hence the (super-expensive19:04
wpwrak_oops. s/quite sure/quite remember/19:04
wpwrak_s/$/) order from mouser/19:04
wpwrak_wolfspraul: untroubled dreams then ! ;-)19:06
wolfspraulI will digest on diodes and forward voltages19:07
kristianpaulhey, this project have same spartant6 also a flash prom,, ah20:35
kristianpaulflash PROM for multiboot FPGA po20:35
kristianpaulwell, SPI flash..20:37
kristianpaulafaik, i don have altium to check schematics20:40
--- Sun Jul 17 201100:00

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