**** BEGIN LOGGING AT Sun Mar 06 02:59:58 2016 Mar 06 03:00:26 ^^^^ Mar 06 12:57:28 Hi I'd like to ask why I cannot get LCD working. I'm issuing commands accordingly to http://www.protostack.com/blog/2010/03/character-lcd-displays-part-1/ and It doesn't work (doesn't change anything, only backlight is working. Connection method: https://translate.google.com/translate?sl=pl&tl=en&js=y&prev=_t&hl=pl&ie=UTF-8&u=http%3A%2F%2Fkaktusa.pl%2Flcd-cob-kaktusa-zabawy%2F%23more-1635&edit-text= My code: Mar 06 12:57:35 https://bitbucket.org/duga/i2c-training/src/551e0cf7d65823b91321834c01112e45d0284441/i2c.c?fileviewer=file-view-default Mar 06 12:58:40 p[4-7] = d[4-7] Mar 06 12:59:00 p3 - backlight, p2 -e, p1 - rw, p0 -rs Mar 06 14:13:23 huh, what a bizarre way to connect a display Mar 06 14:13:35 the am335x has a built-in controller for hitachi-style displays Mar 06 14:14:52 I also know someone recently made a driver for them that uses gpios Mar 06 14:23:23 note that according to this page some versions of that module use a different i2c address https://arduino-info.wikispaces.com/LCD-Blue-I2C Mar 06 17:27:39 Hello, I have to update two BeagleBoards C4 to new ubuntu version. However Ubuntu fails to boot. Is C4 version still supported with latest Ubuntu images? Mar 06 17:39:35 Zealot: where do you download that image from? Mar 06 17:40:27 I have followed the guide http://elinux.org/BeagleBoardUbuntu#Method_1:_Download_a_Complete_Pre-Configured_Image Mar 06 17:41:02 The problem I have seem to be unique, at least I can't google it Mar 06 17:41:35 Startup fails within uboot. Just before kernel start Mar 06 17:45:35 looks like rcn-ee tests at least on a BBxm Mar 06 17:45:43 do you get any serial port output? Mar 06 17:46:59 Yes. All before the freeze. But it is quite uninformative. Mar 06 17:47:04 Should I post it here? Mar 06 17:47:29 use a pastebin please Mar 06 17:47:39 Just a second Mar 06 17:48:33 Ah... I need to reflash the card. It will take a while. Sorry 5min Mar 06 17:50:33 np Mar 06 17:52:34 And if you don't mind I will use the login from the xchat instead of the web version. Mar 06 17:59:09 Here I'm back. I changed a nick from Zealot. Mar 06 17:59:15 So here is a pastebin Mar 06 17:59:16 http://pastebin.com/T6nnx1QP Mar 06 17:59:28 It basically fails to start the kernel Mar 06 17:59:53 Seem, like platform dependant configs don't match the C4 beagle Mar 06 18:00:29 uboot config Mar 06 18:02:00 you'd need to talk to rcn-ee Mar 06 18:03:48 you meen Robert C Nelson himself? How can I contact him? Here or on github? Mar 06 18:06:27 he's sometimes here, but you could also post on the beagleboard google group Mar 06 18:08:14 thank you very much! Mar 06 18:08:20 I'll try it Mar 06 21:33:00 zmatt: did you see the final on the usb babble problem? wondering what you think about it. Mar 06 21:44:01 is there a client app that will allow a device on a local network to be accessed like a "virtual" ssh/scp? sorta like the logmein service, but textual/openssh only? Mar 06 21:45:56 yates: yeah I read the page. nice catch! power supply going into PFM mode making it unable to deal adequately with rapid current spikes Mar 06 21:47:13 still damn high noise levels! but this is still with the crappy pcb layout with a split ground plane right? Mar 06 21:52:27 and I'm a bit lost about what you mean with that last question... Mar 06 22:13:42 http://paste.fedoraproject.org/334905/45730241/ -> http://paste.fedoraproject.org/334905/45730241 Mar 06 22:14:15 zmatt: i wish i could take credit for the catch. Mar 06 22:15:39 i took the board to a small group in a neighboring city. they knew a lot about regulators and specifically this type of mode, plus they had a nice lab with air flow, microscopes, etc., and folks who could use them. Mar 06 22:15:50 ah, that sort of construction... I've done that once too, and yeah there's gotto be a better way but I haven't looked into it myself yet Mar 06 22:16:20 they actually lifted the TPS63060 and "rewired" pin 4 to disable power-save Mar 06 22:16:32 the noise difference was like night-and-day. Mar 06 22:16:40 yeah. (ssh) Mar 06 22:18:24 good thing it has such a pin. I did mention the power supply as something that needs careful attention due to bursty power consumption of wireless stuff, but I hadn't thought of the possibility it might switch into PFM mode Mar 06 22:18:26 the place was about 2 hours away. i put the board in my trunk and accidently left the battery connected. it ran and stayed connected to the cloud the whole time, IN THE TRUNK! Mar 06 22:18:36 heh Mar 06 22:18:40 PFM? Mar 06 22:18:47 pulse frequency mode Mar 06 22:18:50 the powersave mode Mar 06 22:18:53 ah. Mar 06 22:19:05 i saw that in the datasheet but couldn't see where it was defined. Mar 06 22:19:27 basically where you run the pwm for a short time, then let the voltage droop? Mar 06 22:21:29 what really, really, really (did I mention really?) gets my goat is that I had a very strong suspicion this was a hw problem 4+ weeks ago, but the hw and project manager thought they knew better and that it HAD to be a sw problem. Mar 06 22:22:05 even after being informed they violated design guidelines all over the place? :P Mar 06 22:22:10 this presumption cost the project a missed demo date with the customer and about a month delay. Mar 06 22:22:15 yea, that too. Mar 06 22:22:49 and I was the one who ended up pushing through to the fix since i took it upon myself to go up to this lab and have the hw checked out. Mar 06 22:23:20 the guys at the lab also were very helpful - they deserve a lot of credit. Mar 06 22:24:30 and PFM basically means it just tops up the output cap with a short pulse whenever output voltage drops below some comparison point (which in PFM mode is normally set slightly higher than the target voltage) Mar 06 22:25:03 yeah, 2.5 to 3.5 percent range above the output setpoint. see the datasheet, especially figure 6. Mar 06 22:25:39 but what really is the problem is it going in and out of PFM Mar 06 22:25:41 which is quite a bit actually.. the pmic on the bbb (tps65217) sets it at +1% Mar 06 22:26:10 yeah in PFM mode it can't react fast enough to a sudden increase in current Mar 06 22:26:13 this is the 5VDC running into the TPS65217C Mar 06 22:26:44 zmatt: why not? Mar 06 22:27:07 seems like a great opportunity for design improvement.. Mar 06 22:27:46 not sure, I'm not that deeply into the subject matter either, but that's why they set the voltage slightly higher in PFM mode in the first place Mar 06 22:27:46 inside the chip, that is Mar 06 22:28:30 note that PFM can be disabled in the TPS65217 also (via I2C) to reduce noise at the expense of power consumption Mar 06 22:28:51 i also had the board running for 25+ hours. before then the best we could do (at high-speed USB) was 3 hours, and that was just once. typically it was 5 to 30 or 40 minutes Mar 06 22:29:49 the crash was ALWAYS due to a usb disconnect (at 12~MHz) Mar 06 22:30:00 of course that still shouldn't crash Mar 06 22:30:20 the processor stayed up, the but usb disconnected. Mar 06 22:30:31 crash is a poor choice of word Mar 06 22:30:49 well, even a disconnect is still odd... Mar 06 22:30:54 i meant the board came disconnected from the cell network. Mar 06 22:30:56 especially if it doesn't reappear Mar 06 22:33:03 as i stated in that write-up, it appears the disconnect was a consequence of a TX fifo flush problem in the musb driver, which (and i'm going a little out on a limb here) was due to simply too much data backing up to go to the le910 at 12 MHz Mar 06 22:33:23 at certain times. Mar 06 22:34:14 the burstiness and peak datarate reported to the cloud can vary quite a bit due to other asynchronous properties of the system. Mar 06 22:34:21 which would still be a driver bug Mar 06 22:34:56 (or one in the usb controller) Mar 06 22:35:08 what's supposed to happen? something bad is going to happen somewhere if output datarate < input datarate and your buffering is not sufficient for the transient. Mar 06 22:39:21 with networking you normally get backpressure all the way to the application that's sending data Mar 06 22:39:57 in some other cases packets might be dropped Mar 06 22:40:47 causing the whole device to fail is however definitely not a normal way to react to such a situation Mar 06 22:41:00 also, RAM has plenty of space for buffering Mar 06 22:48:02 ah, that's why the regulator is sluggish to respond in powersave mode.. it's simply because it then enters a sleep mode of some sort to reduce idle current (at the expense of some wakeup latency when the voltage comparator triggers) Mar 07 01:13:52 zmatt: perhaps you're right and my theory is completely bogus. that doesn't mean it is a stack (or generally, a software) problem, though. it could still be the noise invoking some invalid state of the hardware. Mar 07 01:14:34 wait, no, that last statement isn't correct. Mar 07 01:15:48 we were still getting this "usb disconnect at a random time" AFTER fixing the regulator. but it only happened when running at 12 MHz. running at 480 MHz was flawless: no disconnects, no babble. Mar 07 01:15:55 at least for 25 hours. Mar 07 01:18:50 i still suspect it has SOMETHING to do with mis-operating the le910 at 12 MHz versus 480 MHz. **** ENDING LOGGING AT Mon Mar 07 02:59:58 2016