| 00:19.32 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 00:52.22 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 01:10.07 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 01:46.25 | qi-bot | [commit] Werner Almesberger: dsv/dsv (flush): sanitize name of local data sheet copy (master) http://qi-hw.com/p/eda-tools/006940d |
| 01:55.21 | *** join/#qi-hardware archang (~archang@111.198.29.53) |
| 02:17.52 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 02:25.24 | *** join/#qi-hardware archang (~archang@111.198.29.53) |
| 02:40.36 | *** join/#qi-hardware sandeepkr (~sandeep@111.235.64.4) |
| 02:54.29 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 04:13.53 | *** join/#qi-hardware sandeepkr (~sandeep@111.235.64.4) |
| 04:53.43 | *** join/#qi-hardware DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 05:16.02 | *** join/#qi-hardware rjeffries (~rjeffries@pool-74-106-217-43.snloca.dsl-w.verizon.net) |
| 05:33.32 | *** join/#qi-hardware sandeepkr (~sandeep@111.235.64.4) |
| 07:45.31 | *** join/#qi-hardware sandeepkr (~sandeep@111.235.64.4) |
| 08:27.10 | *** join/#qi-hardware pcercuei (~paul@137.71.226.54) |
| 08:55.50 | *** join/#qi-hardware sb0 (~lekernel@101.78.234.124) |
| 09:52.00 | *** join/#qi-hardware dandon (~dandon@185.16.53.65) |
| 10:15.24 | kyak | just discovered the NO_ACT option in irssi's ignore settings. How did i live without it? |
| 10:16.10 | kyak | for example, it can be set so that the [commit] messages from qi-bot are not ignored, but simply don't mark the channel as "Act:" |
| 10:16.53 | kyak | this way, i don't have to switch to the channel unless somebody actually said something :) |
| 10:18.48 | larsc | so basically never |
| 10:19.07 | kyak | no, i just had to switch because of your message! :) |
| 10:20.21 | kyak | but basically, yes -\ |
| 11:14.50 | *** join/#qi-hardware sb0 (~lekernel@101.78.234.124) |
| 11:48.14 | *** join/#qi-hardware sandeepkr (~sandeep@111.235.64.4) |
| 12:28.53 | *** join/#qi-hardware fdcx (357@ceata/consiliu/FDCX) |
| 12:33.44 | *** join/#qi-hardware fdcx (357@ceata/consiliu/FDCX) |
| 13:37.02 | *** join/#qi-hardware sb0 (~lekernel@123202036228.ctinets.com) |
| 13:52.20 | *** join/#qi-hardware fdcx (357@ceata/consiliu/FDCX) |
| 14:45.28 | *** join/#qi-hardware aimg (~aim@125.16.18.198) |
| 15:15.52 | *** join/#qi-hardware kristian1aul (~kristianp@49.90.154.104.bc.googleusercontent.com) |
| 15:44.22 | *** join/#qi-hardware kristianpaul (~kristianp@ec2-52-3-242-38.compute-1.amazonaws.com) |
| 15:44.22 | *** join/#qi-hardware kristianpaul (~kristianp@unaffiliated/kristianpaul) |
| 16:52.00 | *** join/#qi-hardware dandon (~dandon@185.16.53.65) |
| 18:15.38 | *** join/#qi-hardware pcercuei (~pcercuei@185.13.202.239) |
| 18:19.17 | wpwrak | hmm, i could bemoan the injustice that all those well-paid quantum mechanics still haven't figured out how to make a decent ideal FET. e.g. with Rds(on) = 0 Ohm, very low Vgs(th), infinite Vgs(max) and Id, and of course no leakage whatsoever |
| 18:31.47 | DocScrutinizer51 | well, they are pretty close |
| 18:32.26 | DocScrutinizer51 | Rds_on of 5mOhm id alresdy reality |
| 18:32.55 | DocScrutinizer51 | is* |
| 18:33.47 | DocScrutinizer51 | ugh |
| 18:34.02 | DocScrutinizer51 | Rds_on of 5mOhm is alresdy reality |
| 18:36.27 | DocScrutinizer51 | low quiescent and creep currents are also normal, and voltages up to 50 are standard, more available |
| 18:37.07 | DocScrutinizer51 | silego has some nice stuff with integrated charge pump |
| 18:49.51 | *** join/#qi-hardware infobot (ibot@rikers.org) |
| 18:49.51 | *** topic/#qi-hardware is Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben/atusb 802.15.4 wireless, anelok and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs and http://irclog.whitequark.org/qi-hardware |
| 18:49.51 | *** mode/#qi-hardware [+v infobot] by ChanServ |
| 18:50.06 | DocScrutinizer05 | ~+chaninfo |
| 18:50.06 | infobot | 125/125 channels, 4460 users, 3424 unique: #debian/1554, #kde/446, #gsoc/344, #asterisk/184, #maemo/169, #wowuidev/130, #oe/128, #neo900/89, #wowace/89, #utah/81, #cubieboard/71, #harmattan/58, #wowhead/55, #meego/50, #qi-hardware/49, #openmoko/48, #bzflag/46, #openmoko-cdevel/42, #asterisk-dev/41, #arm-netbook/41, #webos-internals/41, #curseforge/40, #maemo-ssu/40, #elinux/32, #uphpu/27, #slug/24, #brlcad/24, #debianppc/21, #sc2mapster/20, ... |
| 18:50.33 | DocScrutinizer05 | ~+chanset purl |
| 18:50.33 | infobot | Showing purl values on all channels... |
| 18:50.33 | infobot | <PROTECTED> |
| 18:50.33 | infobot | End of list. |
| 18:51.09 | DocScrutinizer05 | ~+chanset ##bz-inc |
| 18:51.09 | infobot | chan: ##bz-inc (see _default also) |
| 18:51.09 | infobot | <PROTECTED> |
| 18:51.44 | DocScrutinizer05 | god! purl_ |
| 18:51.48 | wpwrak | Vgs often tends to be pretty low. e.g., i see a lot of FETs (mainly from vishay) that only tolerate 5 V |
| 18:52.10 | DocScrutinizer05 | Vgs is not that relevant |
| 18:52.30 | wpwrak | it is if you connect this to VBUS ;-) |
| 18:52.40 | DocScrutinizer05 | ohwell |
| 18:52.58 | DocScrutinizer05 | then you need a p-fet instead a n-fet (or vice versa) |
| 18:54.02 | DocScrutinizer05 | so you can connect source source to VBUS |
| 18:54.19 | wpwrak | well, that could get another volt or so, but adds operational constraints to the equation. better to pick a FET with enough headroom |
| 18:54.26 | DocScrutinizer05 | on gate you do VBus || Vbus - 2V then |
| 18:55.12 | wpwrak | it's for suppressing the battery when USB is present, and for making VBUS compatible with logic levels for detection |
| 18:55.47 | DocScrutinizer05 | check out the silego greenFET stuff, they have pretty nice chips |
| 18:55.55 | wpwrak | alas, the voltage ranges are such that i can't just tweak things with resistors |
| 18:57.12 | DocScrutinizer05 | MOQ 10, iirc |
| 18:57.21 | DocScrutinizer05 | < 100ct |
| 19:09.55 | wpwrak | more like MDQ 100. but way too greedy. as soon as you need a charge pump, you lose |
| 19:10.50 | wpwrak | (just checked the silego parts. alas, nothing that sticks out as being much better than the rest of the switches i've looked at.) |
| 19:11.23 | DocScrutinizer05 | hmm :-/ |
| 19:11.48 | wpwrak | well, just a question of finding the right FET ... and then two more, for 2nd and 3rd source, just in case |
| 19:12.01 | DocScrutinizer05 | isn't that chargepump only drawing power when you have the FET open anyway? |
| 19:12.17 | DocScrutinizer05 | oooh that's your problem, I see :-) |
| 19:12.53 | DocScrutinizer05 | you'd need a chip that activates chargepump to go into switch-off state |
| 19:14.16 | DocScrutinizer05 | you have no voltage regulation, right? How about an ideal diode in battery power? |
| 19:14.40 | wpwrak | (pump) yup :) in switch-off, i have all the power i want :) |
| 19:14.58 | DocScrutinizer05 | yet another spider, grrrrrrr |
| 19:15.14 | DocScrutinizer05 | fetches the glass from freezer |
| 19:16.33 | DocScrutinizer05 | 30s and they are hybernating, those critters. HEHE |
| 19:17.06 | DocScrutinizer05 | pretty convenient to throw then outa the glas when they don't move |
| 19:17.56 | wpwrak | this is the circuit (WIP, ignore the component specs or part values. only the overall design goals make sense): http://downloads.qi-hardware.com/people/werner/anelok/tmp/power1-Power1.pdf |
| 19:18.13 | wpwrak | Q1 is for battery reveral |
| 19:19.13 | wpwrak | Q2 is for cutting the battery when USB is on |
| 19:19.52 | wpwrak | Q3 is for bringing the VBUS voltage to logic level |
| 19:20.24 | DocScrutinizer05 | sooo, what for cut battery with Q2 at all? |
| 19:21.09 | wpwrak | to prevent U1 from thinking it should top off 3.3V by a few more mV, and suck the battery dry |
| 19:21.46 | wpwrak | alas, the USB regulator has a fairly wide output range, so it may very well end up below U1's regulation threshold |
| 19:22.26 | wpwrak | also, reverse-charging may be an issue |
| 19:22.58 | DocScrutinizer05 | I don't get ot |
| 19:23.12 | DocScrutinizer05 | where's VBus to POWER? |
| 19:23.19 | wpwrak | ah wait, that's why i should connect Q1.gate to USB_PRESENT. i know i had that before for a reason :) |
| 19:23.43 | wpwrak | that's done by the LDO in one of the MCUs |
| 19:24.44 | DocScrutinizer05 | Rds(on)<=100mR should be Rds(on)<=10mR |
| 19:24.52 | DocScrutinizer05 | maybe 20 |
| 19:24.56 | *** join/#qi-hardware pcercuei (~pcercuei@185.13.202.239) |
| 19:25.21 | wpwrak | with low Vgs(th) ? :) |
| 19:25.44 | DocScrutinizer05 | dunno |
| 19:25.46 | wpwrak | 100 mOhm should be sufficient. worst-case, we lose 100 mV |
| 19:25.55 | DocScrutinizer05 | per FET, yes |
| 19:26.04 | DocScrutinizer05 | 130mV |
| 19:26.16 | wpwrak | ah, don't look at these parameters |
| 19:26.22 | wpwrak | only at the block above |
| 19:26.36 | wpwrak | it's 200 mOhm in total, for Q1+Q2+L1 |
| 19:26.58 | wpwrak | (well, plus Rds(on) of the FET in U1. lemme see how much that is ...) |
| 19:27.54 | DocScrutinizer05 | ok 500mA @ 200mR is 100mV aka 10% of 1V |
| 19:28.02 | DocScrutinizer05 | sounds good enough |
| 19:28.49 | DocScrutinizer05 | I still don't get why you switch off a battery when you have USB connected |
| 19:28.53 | wpwrak | hmm, the boost converter is actually a bit on the weak side. need to revisit that. |
| 19:29.56 | DocScrutinizer05 | when [POWERED] grets - say - 5V from USB VBus, you have Q1 anyway. Don't need anything more |
| 19:30.24 | wpwrak | if i don't switch it off, it will still feed the boost converter. if the system voltage is below the boost converter's threshold, it will continue topping it up |
| 19:30.42 | DocScrutinizer05 | ooh |
| 19:30.44 | DocScrutinizer05 | I see |
| 19:31.03 | DocScrutinizer05 | heck, you got an EN input on the boost converter ;-D |
| 19:31.19 | wpwrak | yes, with the wrong polarity :( |
| 19:31.29 | *** join/#qi-hardware __20h__ (~some_one@r-36.net) |
| 19:31.29 | *** join/#qi-hardware _whitelogger (whitelogge@fehu.whitequark.org) |
| 19:31.29 | *** join/#qi-hardware enyc (~enyc@muddle.enyc.org.uk) |
| 19:31.29 | *** join/#qi-hardware paulburton (paulburton@gateway/shell/firrre/x-nxzdplmdzaxmlcaj) |
| 19:31.29 | *** mode/#qi-hardware [+v _whitelogger] by holmes.freenode.net |
| 19:31.33 | DocScrutinizer05 | so what? :-) |
| 19:31.44 | DocScrutinizer05 | wb _whitelogger |
| 19:32.21 | wpwrak | well, could save some mOhm by putting in an inverter |
| 19:32.40 | DocScrutinizer05 | yep, exactly |
| 19:32.55 | DocScrutinizer05 | or even control the EN by MCU GPIO |
| 19:33.02 | DocScrutinizer05 | if you got a spare one |
| 19:33.14 | wpwrak | i'd rather not have the MCU control its own power ;-) |
| 19:33.26 | DocScrutinizer05 | you gotta detect USB VBus anyway, somehow |
| 19:33.55 | DocScrutinizer05 | how do you do that? |
| 19:33.58 | wpwrak | i only have a valid USB_nSENSE if the MCU is up and has enabled a pull-up |
| 19:34.25 | DocScrutinizer05 | well, then connect the EN in a way so it's active when MCU is down |
| 19:35.01 | wpwrak | tricky. what if the MCU gets confused while ramping up or down ? |
| 19:36.37 | DocScrutinizer05 | gets confused? |
| 19:37.01 | DocScrutinizer05 | btw we had same power control in that wikireader thing :-) |
| 19:37.05 | wpwrak | glitches, etc. |
| 19:37.14 | DocScrutinizer05 | add a capacitor |
| 19:37.28 | wpwrak | yeah, in GTA01, too. and it produced very interesting effects ;-) |
| 19:37.43 | DocScrutinizer05 | in wikireader it worked great |
| 19:37.49 | wpwrak | luck :) |
| 19:37.58 | DocScrutinizer05 | nah, JR-design |
| 19:38.09 | DocScrutinizer05 | ;-) |
| 19:39.18 | DocScrutinizer05 | know your CPU, add deglitching as needed, have a mech switch to bridge all the electronict to power up (MCU will be stable before you release that button anyway) |
| 19:40.00 | wpwrak | naw, let's keep things simple |
| 19:40.09 | DocScrutinizer05 | how simple? |
| 19:40.19 | DocScrutinizer05 | suspend mode for CPU? |
| 19:41.05 | DocScrutinizer05 | there's hardly anything simpler than a pushbutton with a CPU GPIO controlled parallel FET |
| 19:41.45 | DocScrutinizer05 | and you can expect <1uA quescent current, for sure |
| 19:42.04 | DocScrutinizer05 | possibly rather in the low nA range |
| 19:42.42 | wpwrak | adding mechanical components is messy as far as i'm concerned |
| 19:43.01 | wpwrak | well, electromechanical |
| 19:43.14 | DocScrutinizer05 | pushbutton switch from EN to VBAT, capacitor on EN to GND, resistor from EN to GPIO. Done |
| 19:44.02 | DocScrutinizer05 | as long as you keep the pushbutton pressed, no worries about any glitches whatsoever |
| 19:44.56 | wpwrak | naw, let's design it such that it works without such patches |
| 19:46.14 | DocScrutinizer05 | hmmm, when you hate that little hole for the switch button, how about using sth leete like e.g a spring+mass based g-meter - you whirl the dongle to switch on :-) |
| 19:46.31 | DocScrutinizer05 | (I.E. >2g for long enough) |
| 19:46.49 | wpwrak | btw, you'll probably like the way i provide standby power: with silo caps next to the MCU, and an MCU-controlled FET before them, to isolate the MCU from the system voltage. power-up is still assured, irrespective of what the CPU tells the FET, through the body diode :) |
| 19:47.20 | wpwrak | (adding junk) anelok is a cost-conscious project :) |
| 19:47.21 | DocScrutinizer05 | o.O nifty |
| 19:47.44 | DocScrutinizer05 | sure, that's why I suggest to eliminate Q2 |
| 19:48.19 | DocScrutinizer05 | you prolly can eliminate a lot more of cruft when you switch complete power via EN |
| 19:48.36 | wpwrak | would be great if i can, yes. problem is a) polarity and b) possible voltage domain. |
| 19:48.58 | DocScrutinizer05 | please elaborate, I'm thick |
| 19:49.13 | wpwrak | naw, i need Q1 in any case. especially since most boost converters don't block reverse current |
| 19:49.31 | DocScrutinizer05 | I need a complete schematics |
| 19:50.06 | DocScrutinizer05 | (don't block reverse) good point |
| 19:50.10 | wpwrak | yeah, update is still WIP. changing a bunch of things. and also drawing a nicer power tree |
| 19:50.41 | DocScrutinizer05 | oh such fun to do a 20min real EE every 6 months |
| 19:51.20 | DocScrutinizer05 | wish I could forget all the other mess with UG and do some for my device |
| 19:51.55 | wpwrak | hehe ;-) |
| 19:52.10 | DocScrutinizer05 | how do you feed USB VBus? |
| 19:52.24 | DocScrutinizer05 | directly to [powered]? |
| 19:52.26 | wpwrak | the joy to be "industriekapitaen" :) |
| 19:52.35 | DocScrutinizer05 | FSCK!!! |
| 19:52.54 | DocScrutinizer05 | Kapitaen of a dingi |
| 19:52.56 | wpwrak | [powered] is just an annotation, has no physical function |
| 19:53.28 | DocScrutinizer05 | so to VBOOST then? |
| 19:53.50 | wpwrak | no, VBUS -> ESD -> VBUS_RAW |
| 19:53.53 | DocScrutinizer05 | (makes more sense anyway) |
| 19:54.12 | wpwrak | then VBUS_RAW -> diode (to block reverse leakage from the regulator) -> LDO -> 3.3 V rail |
| 19:54.32 | wpwrak | ah yes, which is then = VBOOST |
| 19:54.51 | DocScrutinizer05 | sure sure, VBUS_RAW fine, but where gets VBUS(_RAW) ... ahh wait you answered |
| 19:54.54 | wpwrak | before, i had something between 3.3 V and VBOOST. deleting the VBOOST label ... |
| 19:55.18 | *** join/#qi-hardware pcercuei (~pcercuei@185.13.202.239) |
| 19:55.51 | DocScrutinizer05 | so 3V3 is your main power rail, right? |
| 19:55.58 | wpwrak | yes |
| 19:56.09 | DocScrutinizer05 | and how's battery -> 3V3? |
| 19:57.33 | DocScrutinizer05 | it looks a tad ... complicated |
| 19:58.31 | wpwrak | battery -> stuff under discussion -> boost -> 3V3 |
| 19:58.44 | DocScrutinizer05 | a second booster? |
| 19:58.54 | wpwrak | no, U1 |
| 19:59.32 | DocScrutinizer05 | ooh, I gathered U1 is for USB VBOOST aka 5V0 |
| 20:00.11 | wpwrak | noo ! |
| 20:00.30 | wpwrak | i have an AAA primary cell. i need to boost it to 3.3 V |
| 20:00.39 | DocScrutinizer05 | so VBOOST = 3V3 rail? |
| 20:00.44 | wpwrak | i don't supply USB host power. if you want USB host, welcome to the Y-cable |
| 20:00.47 | wpwrak | yes |
| 20:01.18 | DocScrutinizer05 | please don't call it VBOOST :-) maybe it's just me, but VBOOST sounds like USB VBus hostmode |
| 20:01.40 | DocScrutinizer05 | just call it 3V3 |
| 20:02.26 | wpwrak | the label is already earmarked for deletion :) as i said, there was a FET after it (from an older design, with different characteristics), so it made sense to label the net. but now it's just 3V3. |
| 20:03.21 | DocScrutinizer05 | oooookay. So let me suggest to use connect that 3V(3) LDO for VBus to VBat_safe |
| 20:03.43 | DocScrutinizer05 | -use |
| 20:04.36 | wpwrak | that LDO output should be at ~3.3 V since this also supplies some 3.3 V domain items in the chip |
| 20:05.08 | DocScrutinizer05 | mhm, well, the booster should still work fine with Vin==Vout |
| 20:05.10 | wpwrak | (says the documentation. not entirely sure how much abuse would be possible there.) |
| 20:05.33 | wpwrak | yes, but the MCU might hate having its 3.3 V items at VBAT ;-) |
| 20:05.44 | DocScrutinizer05 | o.O |
| 20:05.50 | DocScrutinizer05 | ooh# |
| 20:05.55 | wpwrak | besides, there may be non-negligible current between that and its real 3.3 V supply pins |
| 20:06.08 | wpwrak | yet another experiment i'd rather stay away from :) |
| 20:06.31 | DocScrutinizer05 | add a FET like Q1 for VBus |
| 20:06.51 | wpwrak | i could of course add a dedicated LDO. might do that if i get really desperate ... |
| 20:07.05 | DocScrutinizer05 | yet another one? |
| 20:07.19 | wpwrak | instead of the one in the MCU, so that it comes without strings attached |
| 20:07.48 | DocScrutinizer05 | I already wonder if you could use a buck-boost converter instead of U1 and you'd not need any LDO |
| 20:08.52 | DocScrutinizer05 | you know, a step-up/down that allows Vin<Vout<Vin |
| 20:09.45 | DocScrutinizer05 | of course such a critter shouldn't be enabled 24/7 |
| 20:10.20 | wpwrak | hast to be on all the time. the system can't run at battery voltage |
| 20:10.20 | DocScrutinizer05 | you prolly couldn't find one that works at almost zero power consumption in low-load/idle |
| 20:10.46 | DocScrutinizer05 | the system doesn't need to run all the time |
| 20:11.03 | DocScrutinizer05 | which brings us back to the pushbutton |
| 20:11.23 | wpwrak | well, i could switch it in and out of battery change mode ... |
| 20:11.44 | wpwrak | but that adds a burden to an already tricky part |
| 20:12.10 | DocScrutinizer05 | battery change mode? |
| 20:12.33 | wpwrak | when the MCU isolates itself and runs off silo caps |
| 20:13.10 | DocScrutinizer05 | ohmy, wouldn't it suffice to write an instruction manual that says: "battery change only while attached to USB"? |
| 20:13.22 | wpwrak | ;-) |
| 20:13.36 | wpwrak | might as well call it an iphone then :) |
| 20:13.48 | DocScrutinizer05 | ummm |
| 20:14.13 | DocScrutinizer05 | I don't get it why you must keep RAM content |
| 20:14.32 | DocScrutinizer05 | or is there another reason to never power down the MCU? |
| 20:15.06 | wpwrak | yes, it's for the RTC |
| 20:15.11 | DocScrutinizer05 | oooh |
| 20:15.40 | wpwrak | might also be nice to keep RAM, but i don't have a requirement for that at the time |
| 20:15.45 | DocScrutinizer05 | well, as long as RTC is the only trouble, and that trouble is only during battery charge.... |
| 20:15.56 | DocScrutinizer05 | change, even |
| 20:16.40 | DocScrutinizer05 | does the MCU have a real RTC, or is that a sw RTC? |
| 20:16.48 | wpwrak | loss of rtc can be painful. e.g., if using some time-based protocol |
| 20:17.28 | wpwrak | depends on the definition of "real" :) but there's a piece of silicon that says "RTC" |
| 20:17.48 | DocScrutinizer05 | sure, your sw can detect loss of correct time, and make time setting mandatory on power-up then |
| 20:18.13 | wpwrak | eek |
| 20:18.33 | wpwrak | blinking 00:00, VCR-style ? :) |
| 20:18.53 | DocScrutinizer05 | I'd consider that good enough when somebody really fails to change battery with USB attached, as recommended in manual |
| 20:19.50 | DocScrutinizer05 | anyway, the RTC also needs 3N3 to keep time? |
| 20:19.56 | DocScrutinizer05 | 3V3 even |
| 20:21.00 | DocScrutinizer05 | or does it have a proper BupBat input for a RTC-backup power supply? |
| 20:21.01 | wpwrak | no, that's why i can use the silo cap trick (or at least i hope it works, still to be tested) |
| 20:21.12 | wpwrak | nope, no separate power input |
| 20:21.22 | wpwrak | but the whole MCU can run at < 3.3 V |
| 20:21.46 | DocScrutinizer05 | hmm, but you could use Vbat (1V) during normal device power-down |
| 20:22.18 | wpwrak | i need >= 1.71 V |
| 20:22.23 | DocScrutinizer05 | :-( |
| 20:22.39 | wpwrak | it's always those little details :) |
| 20:22.41 | DocScrutinizer05 | ffs |
| 20:22.59 | DocScrutinizer05 | sorry, all fun has to end. I need dinner |
| 20:23.10 | wpwrak | hmm yes, me soonish, too |
| 20:24.49 | wpwrak | ah, now i remember what the problem in gta01 was. system power was controlled by the modem. cpu has a signal to the modem for the "power button". during cpu power-down, that signal became uncontrolled, causing the "power button" to be "pressed", which in turn told the modem to power up again ... |
| 20:38.47 | DocScrutinizer05 | yeah, great¡ ;-D |
| 21:44.15 | enyc | funfun |
| 22:03.46 | roh | i remember some loop in i think gta02... where the suspend on the cpu glitched all gpios for reasons of not available versions of the pmu, which was fine for most of them besides the one line connecting to a transistor 'pressing' the 'test' button on the pmu of the modem. there were 2 of those transistors. one for the power button, one for test. |
| 22:04.54 | roh | so as soon as the cpu went asleep, the glitch happend and on the power button it was filtered out by hw debouncing, the test pin had none... ooops... so the modem woke up the cpu again via irq line |
| 22:17.14 | roh | i think the fix was to label the test-button-pressing-transistor 'dnp' ;) |
| 23:08.21 | *** join/#qi-hardware jwhitmore (~jwhitmore@109.77.186.223) |