**** BEGIN LOGGING AT Sun Feb 11 03:00:00 2018 Feb 11 03:00:58 Curt_: sounds like pinmux might not be setup right? Feb 11 03:03:23 Curt_: can you check what (the beaglebone blue version of) my show-pins script says about those two pins? -> https://github.com/mvduin/bbb-pin-utils/tree/blue#show-pins Feb 11 03:05:32 Curt_: also, which kernel version are you running? Feb 11 03:05:38 oh wait Feb 11 03:05:40 pocketbeagle Feb 11 03:05:44 not beaglebone blue Feb 11 03:05:51 sorry, brainfart Feb 11 03:06:20 well I don't have a pocketbeagle version of my script yet... but I'd guess you haven't configured the pins to uart function yet Feb 11 03:29:11 Hi Zmatt, in the good old beaglebone black days I would add BB-UART2 to the line in /boot/uEnv.txt, but that doesn't seem to be the way to do things anymore? Back then if you did that, your /dev/ttyO2 would magically appear and you would be good to go. So in modern times, how are you supposed to configure the pins for uart function? UART4 did work right out of the box for me, so I was surprised to run into trouble with UART2. Oh, Feb 11 03:29:14 Thanks! Feb 11 04:18:30 zmatt: I have no clue why neither my code nor your code is working now! Feb 11 04:36:47 zmatt: i see you changed the iram input Feb 11 04:38:58 pru_python: it's a MemRegion now Feb 11 04:39:07 which support access in three different ways: Feb 11 04:39:58 1. you can map a struct (or other type) from ctypes located at some offset Feb 11 04:40:13 rgn.map( struct, offset ) Feb 11 04:40:43 2. you can read: rgn.read( offset, length ) returns bytes Feb 11 04:41:02 3. you can write: rgn.write( offset, data ) Feb 11 04:41:39 Curt_: use the config-pin utility Feb 11 04:41:58 umm so..... how do i give in the bin file :p Feb 11 04:42:44 sorry, offset is second argument (and optional), not first argument Feb 11 04:43:04 uh, well pruss.iram0.write( read_program_from_file() ) Feb 11 04:44:17 right Feb 11 04:44:26 and how do i get the ti library :p Feb 11 04:44:45 what do you mean? it's right there in my repository Feb 11 04:45:12 https://github.com/mvduin/py-uio/tree/master/ti/icss Feb 11 04:45:19 ah fuck i didn't realise the pruss-test was outside Feb 11 04:46:30 I'm not going to claim this repository is cleanly structured :P but I was lazy Feb 11 04:47:18 I had the intention of properly separating library files and demos at some point, but that was before I learned that I hate python Feb 11 04:49:41 well im gonna go try it on the bbb, might get disconnected :p Feb 11 04:49:50 Curt_: yeah for some reason the pocketbeagle chose to give various pins default functionality instead of leaving them at gpio by default Feb 11 04:51:37 Curt_: for example P2.05/07 are configured to uart4 by default, P1.06/08/10/12 are configured to spi by default Feb 11 04:53:20 Curt_: OH, that does mean you should be careful! the uart2 rx pin (which would be driven by whatever you connect to it) will by default be spi0_clk ... which I think might be always driven (although I'm not 100% sure, it might be tristated when idle) Feb 11 04:53:39 there might be potential risk of a drive conflict there Feb 11 04:54:34 zmatt: I've attempted to run config-pin and set P1_08 and P1_10 to uart, but that doesn't seem to help. :-( I tried adding BB-UART2-00A0.dtbo asa uboot_overlay in /boot/uEnv.txt and that leads to pinmux squawks about these pins already being consumed already by the serial driver, but I'm still not getting anything out of the port. Grrr ... might be time to give up and go to bed. Maybe the hardware elves will visit my shop while I Feb 11 04:56:59 Curt_: mixing old and new ways of doing things is a certain recipe to make a mess Feb 11 04:57:06 zmatt: I'm not doing any spi from the pocketbeagle, can I just turn that off? Feb 11 04:57:37 you can reconfigure the pins at runtime with config-pin... (or at least you should be able to) Feb 11 04:57:57 zmatt: old vs. new: the problem is the docs are spread out over the last 10 years and I'm not a kernel developer and don't track that world very closely, so big changes like this can leave me floundering! Feb 11 04:58:12 if you want them correctly configured from boot, you'll need to customize the DT... Feb 11 04:58:20 So I did reconfigure my P1_08 and P1_10 to be uart, but that didn't seem to bring my uart2 port alive? Feb 11 04:58:24 zmatt: hey man, ti is a directory which doesn't have any file named icss but instead has a directory named icss Feb 11 04:58:27 that's odd Feb 11 04:58:33 pru_python: yes? Feb 11 04:58:35 zmatt: how are you importing that?? Feb 11 04:58:44 uhh, that's perfectly normal in python? Feb 11 04:59:04 zmatt: when you do import a.b as c b needs to be a .py file right..? Feb 11 04:59:14 you put an __init__.py inside the directory Feb 11 04:59:39 Curt_: but the command completed without error? Feb 11 04:59:46 zmatt: are there any definitive 'new' docs I can go read to catch up on the new ways of doing thing? Feb 11 05:00:11 I have no idea Feb 11 05:01:13 zmatt: yes, command completely without error and I could see the pin self reported as uart. No errors. I can open /dev/ttyS2 and write to it without error, but nothing goes through. I can also read from it, but I see nothinig when I send from the other end. (UART4 though is working great, just UART2 is giving me headaches) :-( Feb 11 05:01:29 Curt_: can you try running show-pins script? https://github.com/mvduin/bbb-pin-utils#show-pins of course the output will be all mislabeled since it assumed a beaglebone black, but I'll quickly look up the equivalent pin for the pocketbeagle's P1.08/10 Feb 11 05:01:41 zmatt: ah fuck i got it, i was running python 2 -_- Feb 11 05:02:36 I don't know much about python2, but I'm pretty sure I'm happy I started with python3 Feb 11 05:03:18 Hi Matt, I'm running out of time tonight to pull a script over, maybe I can catch up with you tomorrow. Hopefully you don't sleep and you are here 24/7? :-) Feb 11 05:03:42 Curt_: those spi pins are the same ones used for spi boot Feb 11 05:03:48 so those are clearly labeled in the output of my script Feb 11 05:04:18 should make it easy to find them and check how they're actually configured Feb 11 05:04:24 Thanks for all the helps so far. I'm 90% through a custom board build, and this is the one thing I didn't test during the breadboard phase. Feb 11 05:04:59 there's probably just something silly going wrong Feb 11 05:05:51 zmatt: heres how I write the program file to the iram: pruss.iram0.write(read_program_from_file('blinkled.p') ?? Feb 11 05:06:06 uhh, read_program_from_file isn't an actual function that exists Feb 11 05:06:17 I just meant... read the program from file :P Feb 11 05:06:37 oh so just pass the file name? Feb 11 05:06:46 no, read the file Feb 11 05:07:06 and pass the data to iram0.write Feb 11 05:08:06 that would be the bin file and not the asm one right Feb 11 05:08:42 unless you quickly write an assembler in python, you'll want the binary data yes :P Feb 11 05:09:27 dude i have no clue how to read the bin file Feb 11 05:09:49 zmatt: trying to hang with you a bit longer ... here is the output of show-pins on my pocketbeagle: https://pastebin.com/pKac8fAT Feb 11 05:10:01 I'd have to look it up too... remember I'm not actually a python programmer :P but surely it can't be that hard to find on the interwebs how to read a file in python Feb 11 05:10:28 Curt_: can you pass the -v option to show-pins ? Feb 11 05:10:53 uh Feb 11 05:10:57 it's configured as uart Feb 11 05:11:05 P9.22 / spi boot clk 84 fast rx 1 uart 2 rxd serial@48024000 (pinmux_bb_uart2_pins) Feb 11 05:11:08 P9.21 / spi boot in 85 fast 1 uart 2 txd serial@48024000 (pinmux_bb_uart2_pins) Feb 11 05:11:32 so, whatever is causing your uart problems... it doesn't actually seem to be due to pinmux Feb 11 05:14:27 zmatt: here is show-pins -v: https://pastebin.com/1P2utF2m (although maybe you already found what you needed to see.) Yeah, I don't think it's a pin muxing issue either ... but I'm completely baffled. Feb 11 05:14:52 I assume other people get uart2 running on a pocketbeagle? Or am I the first to try on debian 9.2? Feb 11 05:15:19 I don't see how that could matter Feb 11 05:15:54 there must be *something* different about that uart... but I don't really have ideas Feb 11 05:16:27 check that hardware flow control is disabled? Feb 11 05:17:23 maybe compare the output of stty -a -F $DEV for the working and non-working uart Feb 11 05:17:44 I saw a reference from Robert Nelson that 2 uarts are enabled by default on the pocketbeagle, but no reference on how to enable others ... unless it is via the pin-mux thing? I'm trying to talk over port with minicom, and definitely with flow control disabled. Feb 11 05:18:42 that's probably referring to pinmux yeah, since uart0 and uart4 appear to be muxed by default Feb 11 05:18:51 but you evidently fixed the pinmux Feb 11 05:19:07 so really, it ought to work now Feb 11 05:19:51 the pinmux can be quite a labyrinth Feb 11 05:20:10 pretty straightforward in this case Feb 11 05:20:12 also make sure the direction of the pins is right (outtie innie etc) Feb 11 05:20:14 The output of stty -a -F for /dev/ttyS2 an /dev/ttyS4 are identical according to the 'diff' utility, but that was worth checking. Feb 11 05:20:21 moto-timo: they are Feb 11 05:20:45 receiver is enabled for uart 2 rxd Feb 11 05:20:51 k Feb 11 05:22:26 zmatt: id have to do iram.map(data) or iram.write(data) where data contains the binary file data as bytes?? Feb 11 05:22:41 pru_python: just write Feb 11 05:22:44 map is for mapping a struct Feb 11 05:22:47 I tested continuity end-to-end from radio modem to beaglebone, so I know it's not a cable issue. Maybe the next thing is to try swapping hardware. Thanks again for verifying the pinmux and all the ideas ... I'll keep trying. Feb 11 05:22:48 (btw the default pruss-test.py works, it printed r0 = 124) Feb 11 05:23:49 so, in my little test I mapped iram as an array of 32-bit integers so I could access it like that Feb 11 05:23:57 but read/write use a more direct approach Feb 11 05:24:26 just copies bytes to/from the designated area Feb 11 05:24:58 'c_ulong_Array_4096' object has no attribute 'write' Feb 11 05:25:17 pru_python: I told you not to map Feb 11 05:27:37 read/write are methods directly on the MemRegion, i.e. pruss.iram0 Feb 11 05:28:21 oh fuck Feb 11 05:35:30 'c_ulong_Array_4096' object is not callable Feb 11 05:36:17 can you pastebin your code? Feb 11 05:37:17 maybe I messed something up... although I have tested the read and write methods before pushing it to git Feb 11 05:37:24 https://pastebin.com/12mW1dub Feb 11 05:37:33 ill disconnect login into board Feb 11 05:38:44 calling the write method on iram0 instead of trying to call iram itself as if it were a function will probably help Feb 11 05:39:07 very strange error message then though Feb 11 05:39:32 oh right you're probably gone, your ping just doesn't know it yet Feb 11 05:42:19 Hey was there stuff wrong with how I passed it? Feb 11 05:42:28 why do you lose connection when you log into your beaglebone? Feb 11 05:42:40 06:38 < zmatt> calling the write method on iram0 instead of trying to call iram itself as if it were a function will probably help Feb 11 05:42:47 06:39 < zmatt> very strange error message then though Feb 11 05:42:57 I cannot do it over my wifi because there are like 6 devices connected already, and it becomes slow af Feb 11 05:43:29 So I have to ssh onto the wifi of the BB and so I lose connection Feb 11 05:44:14 Well fuck, btw did you find out possibly why the case code is hanging? Like when I ran yours again, it blinked the LED once, and then nothing bet after that Feb 11 05:44:21 you can also ssh into the beaglebone if it's connected via usb Feb 11 05:44:22 Asm* Feb 11 05:44:42 Oh..... lol well I'll try that next time Feb 11 05:44:54 so... were you able to launch the code? Feb 11 05:45:05 eh Feb 11 05:45:22 maybe check the state of the pause button using show-pins? Feb 11 05:45:25 I dunno Feb 11 05:45:49 where's that link again.... Feb 11 05:45:56 I'll take another look Feb 11 05:46:29 but, if you have it working using py-uio now, that means you can also easily check what the core is doing Feb 11 05:46:34 I'm out for a bite rn, will check when back Feb 11 05:46:48 ... Feb 11 05:47:06 ...? Feb 11 05:47:18 well I was still talking to pru_python_ Feb 11 05:47:26 which I guess is a dead connection Feb 11 05:47:43 What do you mean? I'm here, but don't have my board with me Feb 11 05:48:03 https://pastebin.com/raw/UFMi1jpM Feb 11 05:50:07 Just a bad connection is all Feb 11 05:52:30 Perhaps it's best if I go back at my machine at text, this thing keeps resetting on my phone Feb 11 05:57:01 with open('pru-test-fw.bin', 'rb') as f: Feb 11 05:57:02 pruss.iram0.write( f.read() ) Feb 11 05:57:05 works for me Feb 11 05:57:18 Okay will try that Feb 11 05:57:49 And how do you check where it's halting? Feb 11 05:58:52 you can check pruss.core0.halted to see if it's halted, and you can check the current instruction by reading pruss.core0.pc (that's also allowed while it's running, not just when it's halted) Feb 11 05:59:31 when the core is halted, you can read and write the core's registers (as I show in pruss-test.py) Feb 11 06:01:03 core control still needs a lot more polish... I just very quickly added the full_reset() and run() methods and the halted property to have the minimal basics to run code Feb 11 06:01:15 but e.g. single-stepping would probably be a useful thing to have :) Feb 11 06:01:36 Wtf is single stepping Feb 11 06:02:20 uhh, have you never used a debugger? Feb 11 06:02:51 single-stepping is pretty much what it says... going through the program step by step Feb 11 06:02:51 Ohhhhhhh Feb 11 06:03:34 more concretely, it means the core halts after executing 1 instruction (and you can then reenable it to execute the next instruction, and so on) Feb 11 06:05:26 Alright I'll try this and tell you Feb 11 07:05:37 #x15 Feb 11 07:09:39 Hello Everyone, I have beagleboard x15. I installed ti android and the board a few minutes after boot up Feb 11 07:10:15 I thought it's a temperature issue so I installed a heat sink and fan with no success Feb 11 07:11:08 the system reboots a few minutes after boot up Feb 11 07:20:37 zmatt: with open('blinkled.bin', 'rb') as f: pruss.iram0(f.read()) Feb 11 07:20:47 that worked right? Feb 11 07:26:13 pruss.iram0.write( f.read() ) Feb 11 07:27:48 I explicitly pointed out this mistake earlier Feb 11 07:31:01 sorry that was a typo from my part, pruss.iram0.write(f.read()) AttributeError: 'c_ulong_Array_4096' object has no attribute 'write' Feb 11 07:32:30 uhh what Feb 11 07:32:53 are you sure you have the latest version from git? Feb 11 07:33:04 (of py-uio) Feb 11 07:33:44 oh boy, PRU fun Feb 11 07:33:47 since this sounds like you're still using the previous version Feb 11 07:34:00 fuck you're right Feb 11 07:35:28 well it runs and executes Feb 11 07:35:37 and does nothing ..... :( Feb 11 07:37:01 but now you can at least check the pru state and pc Feb 11 07:37:55 oh, in case you want to know what more is possible, I have a header with notes on the pru core controls that's a bit more detailed than the TRM: https://liktaanjeneus.nl/pdsp.h.html Feb 11 07:44:43 thanks for that Feb 11 07:44:49 but the core is not getting halted Feb 11 07:45:52 then just poll pc a couple of times Feb 11 07:46:05 to see if it's stuck somewhere or appears to be running normallly Feb 11 07:46:09 ohh Feb 11 07:46:16 ? Feb 11 07:46:34 I might have an idea, but one moment brb Feb 11 07:48:37 sorry, I had an idea, and then needed to pee Feb 11 07:48:54 anyway, first check what it seems to be doing Feb 11 07:49:18 by polling..? Feb 11 07:49:32 also, check the pin configuration of the led using my show-pins script Feb 11 07:49:51 yeah, just read pc a bunch of times Feb 11 07:51:33 e.g. for i in range(20): print( pruss.core0.pc ) Feb 11 07:52:47 its prntiinng out a bunch of 10s and 9s Feb 11 07:53:00 btw what script are you referring to? Feb 11 07:56:38 hmm, I haven't pointed you to it yet? Feb 11 07:56:54 zmatt nice doc Feb 11 07:57:46 zmatt: i did see you mention it to some other dude, but i can't access the latest logs Feb 11 07:58:22 pru_python_: https://github.com/mvduin/bbb-pin-utils/tree/blue#show-pins Feb 11 07:59:21 can you give me a link to your current code? Feb 11 08:00:06 you mean the asm code? Feb 11 08:00:09 if you're only ever seeing 10s and 9s that suggests it's stuck in a delay loop Feb 11 08:00:09 yes Feb 11 08:00:37 one sec Feb 11 08:00:56 I mean, statistically you'll almost certainly always sample it while it's in a delay loop... but you'd expect to detect it in both delay loops with equal probability Feb 11 08:02:09 https://pastebin.com/TdwnwdxT Feb 11 08:03:26 9 and 10 is the LED_ON loop Feb 11 08:03:45 okay wait Feb 11 08:04:07 200 ms is a long time... you probably just sampled it while it was in that particular loop Feb 11 08:04:19 btw heres the led pin: Feb 11 08:04:20 P8.07 36 fast 7 gpio 2.02 ocp/helper (pins) Feb 11 08:04:40 P8.07 36 fast 7 gpio 2.02 ocp/helper (pins) Feb 11 08:05:07 that looks weird Feb 11 08:05:29 ikr Feb 11 08:05:34 try exporting the gpio Feb 11 08:05:45 echo 66 >/sys/class/gpio/export Feb 11 08:06:47 I'm starting to guess the gpio is never setup as output Feb 11 08:07:17 the boneblue dts in 4.9-bone is just crappy Feb 11 08:07:24 yes Feb 11 08:07:38 ds2: thanks Feb 11 08:09:03 so now its showing an exclamation that means it's configured as input but the receiver is disabled Feb 11 08:10:02 echo low >/sys/class/gpio/gpio66/direction Feb 11 08:10:38 (yes you can write "low" or "high" to the "direction" attribute to set its direction to output with the initial value of the output being low or high respectively... very intuitive :P ) Feb 11 08:11:54 lol :p Feb 11 08:12:22 man idk if its the kernel or what but the wifi has become real shit Feb 11 08:12:28 it disconnects randomly Feb 11 08:13:19 btw uio won't work on 4.4 ti kernel? Feb 11 08:14:33 uhh, probably, but why would you want a 4.4-ti kernel? it's so ancient! does it even have a dt for the blue? Feb 11 08:15:49 the thing is, i am totally running blind when it comes to the dt stuff. I had a feeling my asm wasn't running only cuz of wrong gpio pinmux, but i didn't understand anything Feb 11 08:15:55 so i just want something that works lol Feb 11 08:16:46 but why would downgrading help? Feb 11 08:17:28 all that's needed are some dt fixes... this is probably something you should just complain about on the forum to hopefully get rcn's attention Feb 11 08:18:28 alright till do that Feb 11 08:18:28 u-boot overlays should be fixed for the blue so you can enable uio-pruss via /boot/uEnv.txt Feb 11 08:18:40 and/or the 4.9-bone dt for the blue should... suck less Feb 11 08:18:52 lol yea Feb 11 08:19:01 ok so i set it to low Feb 11 08:19:09 anyway, for now I think you can just work around it by manually setting the direction via sysfs Feb 11 08:19:47 and then it should be possible to toggle it with pru Feb 11 08:20:07 (you'd also see the changes if you read /sys/class/gpio/gpio66/value ) Feb 11 08:21:32 should i post a request to change the dt or fix th overlays in the bb.overlays git issues Feb 11 08:21:54 I have no idea what you mean by the latter Feb 11 08:22:04 you're trying to use uio-pruss on the blue Feb 11 08:22:22 problem 1: disabling it in /boot/uEnv.txt just doesn't work at all because the blue doesn't support u-boot overlays yet Feb 11 08:23:31 problem 2: there's no simple way to build a custom 4.9-ti dt with uio-pruss instead of remoteproc-pru Feb 11 08:24:06 problem 3: while the 4.9-bone dt does use uio-pruss, it looks like it just hasn't been kept in sync at all Feb 11 08:24:45 if any one of these is fixed then your problem is solved Feb 11 08:24:55 I think? Feb 11 08:25:29 #shamelessly copy paste the problems onto the issue post Feb 11 08:27:19 so its not ssh-ing unless i log onto its wifi Feb 11 08:27:21 so brb Feb 11 08:32:59 im cryin :( Feb 11 08:33:02 its working Feb 11 08:33:59 zmatt: so to configure the thing for pwm / input also i can use sysfs Feb 11 08:37:21 only if dt has suitable declarations to allow userspace to switch configuration at runtime (using config-pin) Feb 11 08:40:00 the led isn't there Feb 11 08:40:16 and so the way to tell if it doesn't have those declarations is if config-pin returns pin-mix file not found? Feb 11 08:40:28 ye i was looking at it rn Feb 11 08:40:48 well I'd think that that error indicates the pin isn't runtime configurable? Feb 11 08:40:53 https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.9.80-bone-rt-r9/arch/arm/boot/dts/am335x-boneblue.dts#L219-L431 Feb 11 08:41:16 these are the declarations of reconfigurable pins (with references to pinmux blocks declared earlier and in a shared .dtsi file) Feb 11 08:41:48 can't we just add the led part here as it is in the ti one Feb 11 08:41:55 yes Feb 11 08:42:09 or just a gpio helper to set its direction to output Feb 11 08:42:26 but... I really need some sleep Feb 11 08:42:32 yes boss Feb 11 08:42:36 thanks for your patience Feb 11 08:43:02 ill disconnect now then Feb 11 14:18:29 zmatt: I got my pocketbeagle uart2 talking today. I tried so many things yesterday and googled so many pages I lost track of what change might have fixed it. Thanks again for all your help, something in there surely must have done the trick. Thanks again! Feb 11 14:32:41 HI Feb 11 14:33:39 I just want to ask how I can download opencv in my beaglebone black . what is the best version to download the opencv on it Feb 11 14:41:34 Curt_: Well congrats on almost figuring it out! Heh. If you have to re-image the thing at some point, try to keep track of what the important change is; that'll be useful data to help others Feb 11 15:15:49 I do keep my list of setup notes and update it every time I go though the process and positively figure out something new. Hopefully my pocketbeagle-based board will be ready to fly in a week or two. Feb 11 15:17:43 Abdul: I've never run opencv on the beaglebone (only on laptop/desktop computers) but I would start with 'apt install opencv'. Then go from there if it's missing something you need. In general, it's a lot easier to stick with stock packages versus needing to compile up custom installs. Feb 11 15:27:47 He left. Feb 11 15:37:29 If you are curious, here is what I'm building up with my pocketbeage: http://gallinazo.flightgear.org/uas/new-hardware-design-project/ Feb 11 16:06:58 oh that's super slick Feb 11 16:07:10 reusing the sbus receiver code from the bbblue? Feb 11 16:10:12 Be double sure that you're never backfeeding voltage into the I/O pins while the beagle itself isn't powered, that's a quick way to blow up the SOC. But it looks like your whole design is powered together so that's pretty close to OK. Feb 11 16:10:49 (Technically there's an output from the PMIC that goes high a little after power is applied, and that's supposed to be the signal you wait for) Feb 11 16:12:04 I'm not so sure this is safe Feb 11 16:12:24 the pmic performs a sequenced power-up that takes a non-negligible amount of time Feb 11 16:12:35 while the 3.3v from the teensy is probably just an ldo Feb 11 16:13:10 so there's a very real risk of driving signals into the am335x before its 3.3v supply is up Feb 11 16:14:34 could you nab that PMIC signal and drive a _shdn pin on the rest-of-the-board regulator perhaps? Feb 11 16:15:51 I doubt PGOOD (== POR) is pinned out on the pocketbeagle, it isn't even on the beaglebone, but the reset output is a decent substitute Feb 11 16:18:32 I see the GPS and telemetry modules are currently powered from 5v... so actually they're not even dependent on any 3.3v supply Feb 11 16:19:22 Hmmm, I'm only using the beaglebone uarts. The teensy is powered from the 3.3v output of the beagle. I've been running this basic architecture for going on 3 years now and haven't blown up a SOC yet, but I suppose there is always a first time. Feb 11 16:19:51 hmm, I'm not seeing 3.3v from the pocketbeagle being used in the schematic Feb 11 16:21:47 I wrote my own sbus code. Sbus -> teensy -> relayed to BB via a uart. The teensy is a big sensor collector and pwm driver. The [pocket]beagle[bone] does all the high level crunching, communication, logging, etc. Over the years I've run this architecture with gumstix [400mhz], verdex, overo, beaglebone, and pocketbeagle ... not to mention various linux PC's. I have a little onion omega2 here I'm eyeballing to try supporting as wel Feb 11 16:22:24 and since the power domain violation would only occur briefly during power up or when explicitly shutting down the pocketbeagle, it may not give problems right away. there's a risk however that it will adversely affect the SoC's lifetime Feb 11 16:22:28 But I'm having trouble getting the python devel stuff (Python.h, libpython-2.7.so) compiled and installed for my cross compiler tools. But this is an issue for a different IRC channel and a different day. :-) Feb 11 16:22:40 zmatt: the 3.3V only goes to the header. Feb 11 16:23:25 jkridner[m]: I'm referring to Curt_'s schematic Feb 11 16:23:29 matt: shoot, I mispoke ... 3.3v from the teensy powers my IMU breakout. Both the teensy and the pocket beagle run off the same 5v regualted voltage in my current design. Feb 11 16:24:09 Curt_: yes, so the signals driven into the pocketbeagle are not dependent on its 3.3v supply being up Feb 11 16:25:28 indeed, that isn’t great. there is a RESETN signal out of the board that will be later in the power up sequence. Feb 11 16:25:30 yes, you are right. I never considered that could be an issue. Is there a standard circuit design for dealing with this? I can connect GPIO's, but I'm not an analog circuit design guy. Feb 11 16:26:42 the simplest solution to power domain violations is avoiding creating multiple power domains :) i.e. power everything off the same 3.3v. that's unfortunately not always an option though Feb 11 16:27:36 e.g. it seems the telemetry unit is powered from 5v so that creates a power domain in any case Feb 11 16:28:18 Well my external devices (gps and radio modem) require 5v power, but talk 3.3v TTL. Same with the onboard teensy. I could power them all downstream of the pocketbeagle's onboard regulator, but I would imagine the danger of overloading that and blowing up my beagle bone is greater than seeing a 3.3v input signal a nanosecond too early. Feb 11 16:29:24 And what if I power up the external devices later, but they would suffer the same issue of seeing 3.3v on their inputs signals before they were powered? Feb 11 16:29:38 (Would I blow up my teensy in that case?) Feb 11 16:29:42 it won't be a nanosecond, iirc it would be around 70 ms Feb 11 16:30:04 that's how long it takes after 5v is supplied to the beagle before its 3.3v supply is up Feb 11 16:30:45 and yes other components may have the same issue, unless their i/o is specifically designed to tolerate it Feb 11 16:31:34 So experientially, I've never had any of about a dozen of my beaglebones go chips up ... just one that had it's usb port ripped off in a crash, but it still ran after that. So this may be a real issue, but I haven't seen it experientially. I don't know how (from a practical perspective) how to design around it. Feb 11 16:34:05 one dirty but simple solution is use series resistors and clipping diodes Feb 11 16:35:41 for the teensy it would probably be sufficient to use series resistors and rely on its internal clipping diodes... I'd be less comfortable doing so with the am335x Feb 11 16:36:05 but at the very least, limiting the current using series resistors should help quite a bit toward preventing damage Feb 11 16:37:25 oh it's way longer than 70ms even Feb 11 16:37:58 I think... or whatever, it's quite a long time in any case :P Feb 11 16:38:59 the insidious thing is that if stuff is being exposed to overvoltage, this causes cumulative damage over time Feb 11 16:39:13 so the issue is long-term reliability Feb 11 16:53:59 On the other hand, if you haven't had problems for years, and if the replacement cost of a pocketbeagle is lower than the PITA-factor of redesigning the circuit, and if it's just a hobby project, no worries! I've done worse.... so much worse. Feb 11 16:54:25 hehe, fair enough Feb 11 16:55:13 I just thought it would be worth mentioning as a consideration in future revisions. I'd take the RESETN signal out of the beagle and hook it to a big P-FET in the 5v supply to the other modules, call it a day. Feb 11 16:55:38 Plus series resistors everywhere, which are good practice as smoke-limiters in general. Feb 11 16:56:57 I don't really have a good feeling of what you can or can't get away with or for how long, so I try to stay on the safe side Feb 11 16:57:12 heh, smoke-limiters Feb 11 16:57:15 Curt_: The stuff on your site is super impressive, by the way. I just watched the autonomous landing after the bug-collecting circular path and that's stupendously cool. Feb 11 17:07:38 Thanks for the kind words ... on a good day I have some fun. Most other days I'm chasing down things like uncopperative UART's or letting myself get talked into complete board redesigns! Feb 11 17:09:02 For whatever it's worth, one of my design goals/hopes for this particular pocketbeagle project is to have something "simple" I can hand solder myself without needing to get crazy with reflow or deal with parts that are less than one pixel resolution with respect to my eyes. :-) Feb 11 17:11:33 fair enough :) Feb 11 17:12:15 maybe I'm just being overly cautious Feb 11 17:16:42 being cautious is not a bad thing nor is it a good thing, it just is and usually comes from blowing things up unintentionally. Feb 11 17:17:17 we have a small graveyard worth of beaglebones that have fallen in the line of duty ;) Feb 11 17:19:50 they have "test subject number" and notes like "extra smoke was in this one."? Feb 11 17:20:03 (the most recent addition being one whose eMMC got completely worn out in two weeks time or so) Feb 11 17:21:11 hehe Feb 11 17:21:17 That sounds like a software issue almost. Feb 11 17:21:26 that is because it was Feb 11 17:22:06 a issue that caused writing hundreds of gigabytes of data per day Feb 11 17:24:06 *an Feb 11 17:25:41 That's quite a volume of data, I can see how the eMMC gave up the ghost. I don't need to ask what did it I can imagine well enough. Feb 11 17:35:35 I am glad they moved the pocket beagle to KiCAD gives me access to the schematic parts they made :D Feb 11 17:36:17 pro-tip: don't perform a VACUUM statement on a decently sized sqlite database every few seconds Feb 11 17:36:53 I have my own little graveyard of parts ... like the $800 IMU I blew up by reversing polarity on the power ... stuff I know to be careful about, but still happens now and then. Feb 11 17:37:00 ouch Feb 11 17:38:19 and yeah, I was actually still able to extract the contents of the eMMC, but it was giving I/O errors on certain writes Feb 11 17:39:10 after recovery I attempted to erase it... that froze, and after power cycling the eMMC wouldn't even appear as block device anymore, it just stopped responding during initialization Feb 11 17:39:10 I appreciate the words of caution on my design. These subtle things are *way* off my radar screen otherwise. Now that they are on my radar screen, I don't have the ability to do anything about it within the scope of my own knowledge, time, etc. but I can see that everyone is on a different place in the path and everyone is learning. So I appreciate those that are way out in front of me being willing to give a few heads ups. Feb 11 17:39:44 Hmmm "I blew up the only prototype real good!" sounds like an EE song I could write. Feb 11 17:41:32 rest in peace, prototype Feb 11 17:41:51 GenTooMan: you don't drive an icecream truck do you? https://www.youtube.com/watch?v=76E7MJsYx1g Feb 11 17:42:53 Curt_: Ah you know the song LOL. Feb 11 17:45:43 +1 on anything Steve Taylor does. :-) I don't think he does beaglebone development though. One of my favorites all time. Feb 11 19:54:28 https://youtu.be/F5ZDmQzAmdY Feb 11 20:27:17 hi guys, what is nowadays the preferred way of updating the eMMC in a beaglebone black? u-boot ums? SD card flasher images? I do frequent updates of the rootfs and kernel (built with buildroot) and I do not want to use tftp/nfs but have the software installed in the eMMC Feb 11 20:30:11 I don't know the preferred way, but I've had good luck with making an SD card, uncommenting the line at the end of /boot/uEnv.txt and booting my beaglebone black with it. It does the cycle thing for a while and shuts down when it's complete. That seems as easy and quick as anything. Feb 11 20:30:32 [the cylon thing] ... darn autocorrect ... Feb 11 20:35:06 Curt_: I guess that in addition to your u-boot, rootfs and kernel, you need an uEnv.txt found in the existing debian images, right? Feb 11 20:47:08 Curt_: thanks, I will try creating an SD card Feb 11 20:53:56 I had wondered the same it would be good if the beagle board wiki was more up-to-date Feb 11 21:06:24 hi Feb 11 21:06:32 anyone here? Feb 11 21:06:56 hi Feb 11 21:06:59 anyone here Feb 11 21:07:20 anyone??? Feb 11 22:36:54 I downloaded the stretch-console for x15 and imaged an 8GB SD Card on macOS using Etcher. I put this in the x15 and powered it on. It gets partway through the boot process, and appears to be booting from the SD card (the installed kernel on the MMC is -r44, and the log shows -r96), but then it gets stuck. There's a fairly long delay after "mmc0: error -110 whilst initialising SD card." Console log below: Feb 11 22:36:54 https://pastebin.com/Y5pX3uBW Feb 12 00:01:01 Hey all, is there a guide around for slimming down the Debian Slack distro for the BBB? I installed it yesterday, and found it 100% filled the eMMC, which isn't great. Feb 12 00:01:23 Or is it better to just stick with Jessie, for now? Feb 12 00:01:57 TezlaCoil: do you need a desktop environment? otherwise use the iot image instead of the lxqt one Feb 12 00:02:18 (also, it's Stretch, not Slack :P ) Feb 12 00:02:29 zmatt: that IS the IoT image. My bad on Stretch/Slack Feb 12 00:02:49 uhh what? the iot image shouldn't take up that much space Feb 12 00:03:36 bone-debian-9.3-iot-armhf-2018-01-28-4gb.img <- what I downloaded Feb 12 00:04:29 it's like... around 450 MB compressed. there's no way in hell that expands to a completely filled 4GB filesystem Feb 12 00:07:51 Found my issue: using a Rev. B BBB, so only 2GB of eMMC. Feb 12 00:08:01 ok Feb 12 00:08:09 the iot image fills up 2GB of space? Feb 12 00:08:15 holy shit... how? Feb 12 00:08:22 According to "df", yes. Feb 12 00:09:00 what on earth did they stuff into that image Feb 12 00:11:10 even on our main development beaglebone, which has the largest amount of shit install of them all, there's only 1.1G of disk space used if I exclude /home Feb 12 00:11:18 *installed Feb 12 00:12:04 (and 1.2G in /home ... jeez we need to clean up our home directories) Feb 12 00:13:38 I have an element14 Rev. C, I'll re-flash and let you know what DF says, on that one. Feb 12 00:14:03 The Rev. B I just used as a PiHole; don't need much space for that. Feb 12 00:14:50 note: we don't use the iot image, I started with a console image, removed any unnecessary crap from that, and then installed stuff as needed Feb 12 00:21:32 Fresh 4GB SD card -> 53% filled by IoT image, so I guess it does use over 2GB? Feb 12 00:22:06 that's just crazy Feb 12 00:22:14 "df" reports 3357264 blocks total, 1658684 consumed, 1508324 free Feb 12 00:23:24 Well, that answers my question, thanks for reminding me the "B" and "C" revisions differ in eMMC (for some reason I thought the C just had more RAM). Feb 12 00:23:38 no difference in RAM, just eMMC Feb 12 00:24:00 (the only beaglebone black derivative that has more ram is sancloud's beaglebone enhanced) Feb 12 00:32:05 so, yeah, you can either try to find and remove pointless packages installed, or start with the console image and install the stuff you need Feb 12 00:32:26 I usually find the latter to be easier Feb 12 00:34:13 but I'm a pretty experienced debian user (I also use it on my laptop), so it's very difficult for me to gauge how hard this stuff is to do for people who aren't Feb 12 00:35:48 I'm a total noob and I've gotten to understand the 'apt install' thing. The trouble is when I encounter software that isn't packaged for debian, I'm completely lost :P Feb 12 00:36:36 yeah the only issue I can imagine is identifying what package you need for certain stuff to work maybe Feb 12 00:37:30 well a lot of software comes with an INSTALL readme, and if you're lucky it's just something like ./configure && make && sudo make install Feb 12 00:37:43 or something similar Feb 12 00:38:28 Heh, I'm not so experienced, but not too scared of the command line either. I'm starting with the IoT image and paring it down though. Probably cleaned out about 100MB of BBBlue/Green and WiFi/Bluetooth stuff that the BBBlack will never need. Feb 12 00:41:22 what usually helps is going through the list of manually-installed packages (apt-mark showmanual) and marking as many of them as possible as "automatically installed" (apt-mark auto ), leaving only things you actually need directly Feb 12 00:41:31 and then let apt-get autoremove clean up junk Feb 12 00:42:02 this avoids having to figure out by trial and error whether you can remove some unfamiliar package or whether it's needed as dependency for packages you need Feb 12 00:42:55 there's also a configuration option for apt that makes it not install "recommended" dependencies, only "required" ones Feb 12 00:43:17 sometimes the recommendations from packages are just bullshit Feb 12 00:57:14 I was offline for a while, dunno if anyoen responded to my earlier query about booting console on x15 Feb 12 00:57:30 nope Feb 12 00:57:51 thanks Feb 12 00:58:04 Is anyone successfully runing a console build on x15? Feb 12 01:00:22 normally it shouldn't matter which image type you're using... they have the same kernel and bootloader, so there shouldn't be any difference in bootability Feb 12 01:00:50 Makes sense. Maybe I can try one of the other flavors. Feb 12 01:00:57 I don't know how to interpret the errors I'm seeing Feb 12 01:03:09 it looks like potentially an issue with the sd card? Feb 12 01:03:53 a timeout while trying to initialize the card Feb 12 01:07:46 But…isn't it booting from the card? Feb 12 01:08:25 It's showing the kernel version that's on the card Feb 12 01:08:44 apparently u-boot can access the card, but for some reason the kernel then fails to (re)initialize the card Feb 12 01:11:28 I'll have to try another card Feb 12 01:12:21 Although…I think I was able to mount the card on the eMMC version that boots fine Feb 12 01:12:30 odd Feb 12 01:13:02 Yeah Feb 12 01:13:05 I just got this x15, too Feb 12 01:13:47 which image are you using? Feb 12 01:14:11 maybe it's just some weird issue with the particular kernel or something Feb 12 01:14:18 I don't know, just making completely random guesses Feb 12 01:14:45 https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#microSD.2FStandalone:_.28stretch-console.29_.28BeagleBoard-X15.29 Feb 12 01:17:06 maybe try the latest official image instead of the latest testing image? the testing image should still work obviously, but I dunno Feb 12 01:19:28 I couldn't find a console image in the official releases Feb 12 01:19:36 I din't want to install all the LXQT stuff Feb 12 01:19:44 I guess there's a Stretch IoT Feb 12 01:20:12 Oh, no, for x15 there's just the full build Feb 12 01:20:30 oh Feb 12 01:20:31 hm Feb 12 01:20:41 then I dunno, sorry Feb 12 01:21:18 No worries, I appreciate the help. Maybe rcn will chime in on the list this week Feb 12 02:42:46 94 upgrades and 10 newly installed. Boomin'! Feb 12 02:43:07 Any new books out there on the BBB? Feb 12 02:43:36 Well... Feb 12 02:44:05 I found a couple on Amazon but I am not sure if they are affiliated w/ your org. or not. Feb 12 02:45:26 Other than those two or three on Amazon, I could not find newly finished books. Feb 12 02:45:45 <<<<< ongoing learner and enthusiast... Feb 12 02:47:02 <<<<< looking for new books about BBB and Linux. Feb 12 02:49:33 ... Feb 12 02:50:11 There is this company or someone called UpSkill Learning. I think they have the newest version of Linux and the BBB stuff. Feb 12 02:50:12 ... Feb 12 02:50:23 Are they affiliated w/ you and your org? Feb 12 02:51:18 They have this book. Feb 12 02:51:25 https://www.amazon.com/BeagleBone-Black-Comprehensive-Learning-Beginners-ebook/dp/B01MAWFSY4/ref=sr_1_17/133-5877765-1306519?ie=UTF8&qid=1518403714&sr=8-17&keywords=beaglebone+black Feb 12 02:51:26 ... Feb 12 02:51:27 Sorry. **** ENDING LOGGING AT Mon Feb 12 03:00:00 2018