**** BEGIN LOGGING AT Thu Jun 15 03:00:03 2017 Jun 15 07:15:13 morning all Jun 15 07:16:55 started last night (for me at least was night) a small topic on the fact that i can't find documentation on how to work with PRU on a standard oficial image for a beaglebone black Jun 15 07:17:38 there is some documentation, but outdated, since thigs are not the same for the latest image with kernel 4.4-beagle Jun 15 07:17:57 zmatt was kind enough to help, but had to go to sleep Jun 15 07:18:44 ... so if anyone has an idea on how to work with the PRU please share Jun 15 07:18:55 thank you in advance Jun 15 07:22:15 hi! is it possible to change the debug console to another uart? i'm designing a base board for the bbbw and would like to avoid the debug header. Jun 15 07:22:41 it has to work with u-boot as well Jun 15 07:24:09 Hi friends I made one mistake that is I shorted 3.3v and gbd Jun 15 07:25:06 Sorry gnd in beagleboardx15 is there is any problem Jun 15 07:25:55 After that beagleboard x15 work properly as like that Jun 15 07:33:05 Hi, I cannot wake up from suspend to ram using GPIO0. No wakeup sources are listed when I suspend. I was wondering if this message in dmesg is the problem "PM: Cannot get wkup_m3_ipc handle". Jun 15 07:33:20 Using latest IOT image with kernel 4.4.68 Jun 15 07:35:56 Beaglebone black rev C Jun 15 07:37:02 I'm not sure if suspend works at all. Jun 15 07:37:32 Hi Jun 15 07:37:34 zmatt: do you know? I seem to remember thinkfat was working on something related to suspend Jun 15 07:38:19 I have an application that need the Beaglebone Black to run 24 hours/7days Jun 15 07:38:37 But I have have a little bit concern on its reliability. Jun 15 07:39:04 Is this Beaglebone Black suitable for my application? Jun 15 07:39:36 if you only look at that narrow aspect, yes. I'd recommend an up to date kernel. Jun 15 07:39:56 Thanks zmatt, I've run the update kernel script. Jun 15 07:40:33 I also tried compiling a 4.9 kernel but the board failed to boot with it. Jun 15 07:41:27 I was wondering if going back to a previous kernel would be an option. I image that this feature is been working OK in the past. Jun 15 08:45:10 hi friends i made one mistake that is 3.3v and gnd are shorted due to some worng connetion in beagleboard-x15 is that any proble in that not in gpio pins only Jun 15 08:45:58 only 3.3v and gnd are shorted iam so scared Jun 15 08:47:56 in beagleboard-x15 Jun 15 10:04:08 Hello! Jun 15 10:04:22 Set_ here. I am just checking in. Jun 15 10:04:25 I hope all is well. Jun 15 10:18:11 ... Jun 15 10:18:37 Are there any people using the Motor Bridge Cape that would like to discuss software for it? Jun 15 10:24:27 ... Jun 15 10:24:32 https://pastebin.com/bdtaiQSS Jun 15 10:24:44 ... Jun 15 10:25:18 This software controls one motor. I have software for two motors but I wanted to see what other people had in mind. Jun 15 10:26:51 The Wiki is listed here: http://wiki.seeed.cc/Motor_Bridge_Cape_v1.0/. Jun 15 10:27:27 dcMotors! Jun 15 10:29:59 I have the BBG and the Motor Bridge Cape that make some piece of machinery go. Jun 15 11:09:41 hm. so, i'm trying to change the uart used for console from the debug headers to another uart. i've created an uEnv.txt with this content: "bootargs=console=/dev/ttyO3,115200n8", and when booting it says it reads environment from uEnv.txt. Jun 15 11:10:29 but the console is still at /dev/ttyO0, and /proc/cmdline says "console=/dev/ttyO0,115200n8....." Jun 15 11:45:50 Up, up, and Blah! Jun 15 12:28:41 Hi All, Had anyone experienced working with UniFlash for BBB flashing? Jun 15 13:36:25 Hi guys, I have a question, I have BeagleBone Black Rev C, when I try to upgrade Debian from Wheezy to Jessy, I get an error while mounting OS to MMC Jun 15 13:36:31 I know MMC is 4GB Jun 15 13:36:40 I am using 4GB MicroSD Jun 15 13:36:48 what could be the reason? Jun 15 13:37:01 I can mount Wheezy by the way Jun 15 15:01:44 ionte: put console=/dev/ttyO3,115200n8 on a line by itself Jun 15 15:22:58 ionte: actually, just console=ttyO3,115200n8 Jun 15 15:25:38 (I guess probably either works) Jun 15 15:35:52 Hello folks I am using the beaglebone x15 and trying to interface a mpc2515 can controller over mcspi, the problem is when I try to read the mpc2515 registers the value read is 0x0 always.. Jun 15 15:40:03 prabhakarlad: did you setup pinmux? Jun 15 15:40:58 have you checked with a scope or such whether the signal looks right on the pins? Jun 15 15:49:50 zmatt: I have setup up the pinmux (https://pastebin.com/JN8TqWrU) properly I do see clock and data Jun 15 15:50:35 on the MISO is see a bit weired data but the clock and mosi seems proper. Jun 15 15:52:45 hmm, ok, then I dunno Jun 15 15:53:17 btw, why not use the integrated CAN of the x15 ? Jun 15 15:54:47 We need to more CAN interfaces for our product Jun 15 15:54:51 ah ok Jun 15 15:55:24 the only thing is I have my CS pin active high does that make any difference to SPI mode 0 Jun 15 15:55:27 ? Jun 15 15:56:56 ehh, the MCP2515 uses active-low CS Jun 15 15:57:32 (like every other spi device I've ever seen) Jun 15 16:00:03 also, try using spi mode 3 Jun 15 16:02:02 (iirc mcspi doesn't support mode 0 very well) Jun 15 16:02:21 I tried with spi-cpol; spi-cpha; but the value is still 00 Jun 15 16:04:46 Since my CS pin is active high I have set spi-cs-high; as well but doesnt make any difference. Jun 15 16:05:18 you have an inverter on the CS line? Jun 15 16:06:50 see page 68 of http://ww1.microchip.com/downloads/en/DeviceDoc/20001801H.pdf for what the signals are supposed to look like during a read transfer (they're using spi mode 0 in that diagram, but mode 3 is also supported, see page 71) Jun 15 16:07:14 make sure CS is not deasserted at any point during the transfer Jun 15 16:17:15 Ahh I see the CS goes high when data is still coming Jun 15 16:17:41 :) Jun 15 16:21:14 in that case do i need to look at mcspi driver ? Jun 15 16:21:22 you're probably just using it wrong Jun 15 16:21:57 wait, are you using it manually or using the mcp2515 kernel driver? Jun 15 16:23:43 mcp2515 kernel driver Jun 15 16:23:50 that's weird Jun 15 16:23:57 the probe itself is failing.. Jun 15 16:24:07 it should know how to do proper spi transfers Jun 15 16:25:46 beware however that, if I remember correctly, mcspi is unable to keep cs asserted between transfers if mode 0 is used. that's why I recommended mode 3 Jun 15 16:44:57 unfortunately both modes arent working. Jun 15 16:46:54 which kernel are you using? Jun 15 16:51:32 Its 4.4 Jun 15 16:54:09 full version please Jun 15 16:58:41 Sorry its 4.4.54 Jun 15 16:59:00 -bone ? -ti ? Jun 15 16:59:05 no wait, -bone makes no sense Jun 15 16:59:15 I forgot for a moment you're using an x15 Jun 15 17:00:33 yes its a x15 :) Jun 15 17:01:17 that's fairly old btw, latest 4.4-ti kernel is 4.4.70 or something Jun 15 17:02:47 close enough... linux-image-4.4.68-ti-r108 Jun 15 17:03:35 (and latest 4.x-ti kernel in general is linux-image-4.9.31-ti-r39) Jun 15 17:04:56 Is there a link for the latest TI source ? Jun 15 17:05:25 you can just install them with apt Jun 15 17:05:35 source? you're building a custom kernel? Jun 15 17:05:47 I am building using yocto Jun 15 17:05:51 oh Jun 15 17:06:17 I don't really know anything about yocto Jun 15 17:08:26 Its basically ti-lsk-linux-4.4.y Jun 15 17:09:23 I was referring to rcn's 4.x-ti debian packages Jun 15 17:09:28 https://git.ti.com/ti-linux-kernel/ti-linux-kernel/commits/ti-lsk-linux-4.4.y Jun 15 17:09:48 (since I assumed you were using debian, which is installed by default on the x15) Jun 15 17:11:31 No I am not :( Jun 15 17:14:56 I don't see any *obvious* problem with how the mcp251x driver performs spi transfers Jun 15 17:15:17 what exactly did you see on the scope? when does it deassert chip select? Jun 15 17:19:09 actually, I need to go do some shopping... my suggestions would be to either try a more recent kernel if this is convenient, otherwise see if you can track down what's going on with that chip select Jun 15 17:19:49 I would not be surprised if it's due to bugs in the omap2-mcspi driver Jun 15 17:19:56 but it could also be somewhere else Jun 15 17:20:15 if you're currently using a real chip select, try using a gpio chip select, or vice versa Jun 15 17:20:31 (I'm not 100% sure however whether gpio chip selects already worked in 4.4, it may require a 4.9 kernel) Jun 15 17:20:36 http://picpaste.com/mcp2515-S9p6WwSG.jpg Jun 15 17:21:34 The yellow line is the chip select and the green one is miso Jun 15 17:22:21 No problem.. Ill try and debug further to see whats happening and try and update to latest kernel Jun 15 17:22:54 I'm not sure what I'm looking at... how many bittimes is this? Jun 15 17:23:34 I can't tell from that picture whether anything is wrong or not Jun 15 17:24:04 ok, yeah, I really should do shopping first, I'll be back later Jun 15 17:24:13 no worries Jun 15 17:24:57 the scope is when I try to load the module, when initally reset command is sent and CANSTAT register is read Jun 15 20:47:06 hello, is there anyone that has experience working with the GPIO pins on the Beaglebone Black using the adafruit python library? Jun 15 20:49:04 Specifically, if there is a way to make the pins so that they are not active low? Jun 15 20:50:48 uhh what? Jun 15 20:51:00 they're not active-low by default Jun 15 20:54:58 Sorry bout that, was having connection issues Jun 15 20:55:10 22:50 < zmatt> uhh what? Jun 15 20:55:11 22:51 < zmatt> they're not active-low by default Jun 15 20:55:58 When I turn the GPIO pins on using the adafruit library they sure act like it Jun 15 20:56:17 using the command to set them high, sets them low, and vice versa Jun 15 20:56:24 then maybe the adafruit library is just doing loopy things Jun 15 20:57:36 when I browsed to the pin location in the device tree (without using the library) the ones listed also all had a thing that said "active_low" so i figured it was that Jun 15 20:57:50 huh Jun 15 20:58:12 cape-universal sets them to active-low? o.O Jun 15 20:58:20 you can probably override that via sysfs anyway Jun 15 21:00:34 or take advantage of the fact that you can write "high" or "low" to the "direction" attribute, which both serves to set the direction to output and set the output level to low/high independent of the active-low setting Jun 15 21:01:42 yea, Ideally I need a way to either set it such that it doesnt initialize the pins that way every time or find a way to do it in python without sysfs if its a recurring issue Jun 15 21:01:52 trying to use these beaglebones for a robotics class Jun 15 21:02:37 so, I wouldn't bother with the adafruit library, you can easily use gpios via sysfs in pure python obviously Jun 15 21:03:07 you should be able to change pins from active-low to active-high by writing "0" to the active_low attribute Jun 15 21:03:56 copy that, trying that now Jun 15 21:04:52 you can also use device-tree to set the default configuration Jun 15 21:05:28 is there a guide somewhere about setting default configuration? that would solve the problem and could be deployed to our multiple BBs easy enough Jun 15 21:06:15 not sure if there's a good guide... I know probably everything there's to know about DT so I haven't had any need lately to go looking for guides :) Jun 15 21:06:56 im brand new to this sort of thing and usually just the hardware guy Jun 15 21:07:43 https://liktaanjeneus.nl/gpio-example.dtsi.html so, this is an example of a device tree fragment I use to setup some gpios Jun 15 21:08:16 I'm not sure if this already works with kernel 4.4 or whether it needs 4.9, it used to require more verbose declarations Jun 15 21:09:21 what is the bash command to override active low in sysfs? Jun 15 21:10:18 echo 0 >/sys/class/gpio/gpio123/active_low (replace 123 by gpio number) Jun 15 21:11:11 you are the best, that seems to have worked! Jun 15 21:11:32 I'm completely puzzled however why the hell they'd be set to active-low by default Jun 15 21:21:19 another benefit of using device tree declarations is that you can give the gpios sensible names and then use an udev rule to setup nice symlinks -> https://pastebin.com/raw/d1SRMZNH Jun 15 21:21:29 avoids having to hardcode gpio numbers in applications Jun 15 21:50:06 Hi how can I know what pin is ttyO1 is connected to? Jun 15 21:52:03 uhh, you asked that yesterday and got an answer Jun 15 21:53:39 https://pastebin.com/raw/CHu0hHm3 Jun 16 02:05:09 What is the problem of all usr led light up in BBB? Jun 16 02:05:36 right after boot? as in, the leds light up in sequence but then stay on? Jun 16 02:06:05 yes after boot up, leds always stay on Jun 16 02:06:25 sounds like a kernel panic during very very early boot Jun 16 02:07:30 wrong or damaged kernel or dtb might cause that, and there are probably other reasons possible Jun 16 02:08:43 Can it be solved by reload new kernel? Jun 16 02:08:57 that depends on what the problem is, which is hard to guess Jun 16 02:09:14 checking the output on the serial console might be helpful Jun 16 02:11:48 thanks! **** ENDING LOGGING AT Fri Jun 16 03:00:03 2017