**** BEGIN LOGGING AT Mon Mar 11 02:59:57 2019 Mar 11 03:33:27 Blah! Mar 11 03:35:15 Does the MotorCape handle four motors? Mar 11 03:35:26 DC motors? Mar 11 03:36:19 I know the MotorCape can handle four motors but why would one board work and the other BBBW not work w/ the same software? Mar 11 03:36:20 ... Mar 11 03:37:16 Do not worry. I am done for the night anyway. I do not know why I brought this up again. Mar 11 09:35:50 how would you connect a 0-5V device signal into a GPIO ? Mar 11 09:36:11 fred__tv: level shifter. Mar 11 09:38:35 would a resistive voltage divider be enough ? Mar 11 09:39:16 fred__tv: well you did not specify direction nor tolerances so far. so, depends. Mar 11 09:40:29 it is a 5v output IC to be read by GPIO configured as input Mar 11 09:40:46 resistive voltage divider can be an implementation of a level shifter. it has the disadvantage of drawing continuous current from the source when it is logic 1 Mar 11 09:40:59 zmatt: perfect answer. Mar 11 09:41:56 picking large resistor values can counteract that, but results in a weakly driven output signal, which may be less suited for high-speed signals and more prone to pick up noise Mar 11 09:42:38 also, when interfacing anything to the beaglebone that's not directly powered from the beaglebone's 3.3v, there's an opportunity for a power domain violation that can be harmful to the beaglebone Mar 11 09:43:17 like that analyzer interfacing we were discussing some times ago.... Mar 11 09:44:06 specifically, you're not permitted to apply any voltage significantly above the beaglebone's 3.3v I/O supply to any of its I/O. As a special case, that means you may not apply a voltage significantly above 0v to the beaglebone's I/O as long as the 3.3v supply is not (yet) powered Mar 11 09:45:55 the 5V supplies provided by the beaglebone itself are among the first to be powered during the power-up sequence. the 3.3v supply is among the last. this creates a window during power-up where external logic powered by a 5V supply may violate these requirements Mar 11 09:47:56 for low-speed signals, a simple level shifter that avoids this problem consists of a pull-up resistor from the beaglebone's I/O to the beaglebone's 3.3V supply, and a diode from the beaglebone's I/O to the external logic Mar 11 09:48:09 so it is better to use VDD3v3 as source for enable external board power supply Mar 11 09:49:13 the diode lets the external logic drive the pin low, but blocks any attempt to drive it high. the pull-up resistor makes the signal on the beaglebone side go high whenever it's not driven low by the external logic Mar 11 09:49:55 in general it's a bad idea to use a supply to enable another supply. use a gpio instead Mar 11 09:50:06 ahh, just figured out that 5V device can be supplied with 3v3 also Mar 11 09:52:01 can't VDD3v3 be used to drive a microrelay or solid state relay (galvanically isolated from the other supply) ? any issue ? Mar 11 09:52:59 if it's actually isolated, sure. but in your case it's not actually isolated since the power domains are connected via I/O Mar 11 09:53:37 this can cause current to flow from the switch-enabled power domain, via I/O, back to the first supply that's used to enable the switch Mar 11 09:54:06 causing it to unintentionally keep itself active Mar 11 09:54:58 using gpio to control the switch avoids this, since the first thing that happens when powering down is that the power-on-reset signal is asserted, causing all I/O to become high-impedance Mar 11 09:56:50 ok Mar 11 10:02:44 l Mar 11 15:02:34 Having issue getting MAX14830 Quad UART set up with BBB. Drivers enabled in kernel and uEnv.txt edited to load the driver (which also defines the SPI0 pins). But uBoot complains that the pins are already used - how come? I thought SPI0 was free and only SPI1 used for HDMI? Mar 11 15:04:05 you can see used by what Mar 11 15:04:12 look at your device tree Mar 11 15:07:07 @mawk Is there a concise way of listing that? (I'm a newbie - sorry). Mar 11 15:07:18 I don't think so Mar 11 15:07:21 just open it and look Mar 11 15:07:37 Where is it? Mar 11 15:07:38 you can find the source code if you're savvy enough, otherwise you can decompile it easily Mar 11 15:07:46 it should be in /lib/firmware or something Mar 11 15:08:08 the name should be in uEnv.txt, or it's said at boot anyway Mar 11 15:08:08 boot the bbb and look for a name ending in .dtb Mar 11 15:08:14 Ah OK - thanks. Mar 11 15:08:18 IIRC kernel exposes the in use kernel at runtime Mar 11 15:08:37 we're talking about the device tree Mar 11 15:08:44 but yeah the device tree should be exposed at runtime also I guess Mar 11 15:08:51 but it's a bit harder to search through I think Mar 11 15:08:54 it's a lot of folders Mar 11 15:09:21 aren't those exposed in /sys/device/platform/ocp ? Mar 11 15:10:19 yeah I guess Mar 11 15:10:47 @mawk - there is no reference to anyoneth dtb other than my own in uEnv.txt Mar 11 15:11:24 yeah, i'ts said at boot Mar 11 15:11:34 but anyway you can guess the correct file in /lib/firmware Mar 11 15:11:38 universal something something Mar 11 15:11:41 I don't remember exactly Mar 11 15:13:30 OK : am335x-boneblack-uboot-univ.dtb Mar 11 15:14:43 right Mar 11 15:15:36 dtc -@ -I dtb -O dts -o am335x-boneblack-uboot-univ.dts /lib/firmware/am335x-boneblack-uboot-univ.dtb Mar 11 15:15:44 should spawn a am335x-boneblack-uboot-univ.dts file in the current directory Mar 11 15:15:52 rowsail_: if you're using a custom overlay, be sure to disable the pinmux helpers for the pins you use Mar 11 15:16:13 Thanks - just trying to figure out that line! Mar 11 15:16:19 mawk: please don't recommend anyone to decompile dtb files Mar 11 15:16:24 just look up the source code Mar 11 15:16:33 but it's fragmented Mar 11 15:16:40 it's a spaghetti of #include Mar 11 15:16:59 unless you know beforehand how to code or how to read code it'll be pretty hard Mar 11 15:17:32 if you want to see the final consolidated device tree, /proc/device-tree is probably the way to go. individual dtbs are just fragments too, since u-boot applies overlays to them Mar 11 15:18:02 anyway, like I said it's probably the pinmux helpers from the universal overlay Mar 11 15:18:30 that's why every overlay in bb.org-overlays specifically disables those for the pins they use Mar 11 15:19:18 if you're declaring spi stuff, you probably also want to disable the devices the universal overlay declares on the spi buses Mar 11 15:20:24 the examples in my overlay-utils do both, e.g.: https://github.com/mvduin/overlay-utils/blob/master/spi0.dtsi#L4-L14 Mar 11 15:20:31 OK - thank you. Mar 11 15:20:54 (USES_PIN is a convenience macro I defined, https://github.com/mvduin/overlay-utils/blob/master/include/bone/common.h ) Mar 11 15:20:56 and yes, earlier the second 'kernel' should have been DT, just as now pointed out by zmatt. Mar 11 15:22:04 to read the source code at least there should be a way to pre-process only the #includes for a start Mar 11 15:22:10 maybe clang has a magical switch for that Mar 11 15:22:15 or some kind of script could do it Mar 11 15:22:28 a minor modification of the standard makefile rule will work for that Mar 11 15:22:42 the makefile actually preprocesses the source before passing it to dtc Mar 11 15:22:47 ah I mean in the kernel itself Mar 11 15:22:53 in your tool yeah I saw that Mar 11 15:23:02 ditto in the kernel Mar 11 15:23:07 ah good Mar 11 15:23:08 my makefile already has a rule for it yes Mar 11 15:23:20 if the one in the kernel/dtb-rebuilder lacks one, it's easy enough to add Mar 11 15:23:45 but as a side-effect it will pre-process any kind of nice macro there would be, like your USES_PIN Mar 11 15:23:49 but maybe the kernel doesn't use any of these Mar 11 15:24:12 it does Mar 11 15:24:31 you could tweak the cpp flags if you just want it to expand includes but not expand macros, I think Mar 11 15:56:50 so is it possible for the pru to switch a pin between input and outout or do you have to use two different pins? Mar 11 15:57:04 on the pruout and one the pruin? Mar 11 15:57:07 or Mar 11 15:57:17 one the pruout and one the pruin Mar 11 15:57:50 I never used the PRU but if you can access the configuration address space there's no reason you couldn't switch between output and input Mar 11 15:58:00 pru's direct I/O can't easily switch direction Mar 11 15:58:14 since that requires changing pinmux, which requires privileged writes to the control module Mar 11 15:58:28 k that is what it seemed like Mar 11 15:59:12 there is an "EDIO" peripheral inside PRUSS that apparently does support direction-changing, but I haven't tried it yet myself. it won't be quite as low-latency as pru's direct I/O, but still a lot better than normal GPIOs Mar 11 16:10:57 The two antennas are working on bbbw or how do confirm if the antennas are working? I use the command " iw list | grep Antenna", it showed "Available Antennas: TX 0 RX 0". I am newbie for the beaglebone black wireless. Mar 11 16:11:45 that probably just means the kernel driver isn't able to inform the iw utility about the antennas Mar 11 16:11:58 in the default configuration they work, obviously Mar 11 16:16:59 to zmatt: thank you, do you have any advice for it? because I need to make sure if the antennas are working. I use the bbbw on my project. I read the rssi value via netlink library, the range of rss changed a lot when I changed the direction of bbbw boards. Mar 11 18:00:31 are the cycle counts for lbxx and sbxx discussed someplace? Mar 11 18:04:38 ah .. nm wiki has it Mar 11 18:04:42 the minimum cycle counts are 1+n for an n-word store and 2+n for an n-word load Mar 11 18:05:02 CPI Mar 11 18:05:21 (the number of words being specifically the number of aligned 32-bit words that contain at least one byte of the memory range accessed) Mar 11 18:07:14 for PRUSS-local memories (and some, but not all, other PRUSS-local resources) those minimum counts will also be achieved provided that there's no interfering simultaneous access to the same target by another initiator (the other pru core, the cortex-a8, or DMA) Mar 11 18:32:01 so zmatt do you do most of your development on a bb? or cross compile ? Mar 11 18:34:20 I wouldn't compile anything beyond hello world on such a limited device Mar 11 18:34:57 i guess it all depends what you are compiling .. gui qt stuff ya probably not .. console/pru stuff it seems fine Mar 11 18:35:19 heh .. i can remember when i was really happy to get a new intel pentium 233MHz Mar 11 18:36:19 sure, if it is fast enough Mar 11 18:36:46 what kinds of things are you doing on your bb tbr ? Mar 11 18:37:13 not much nowadays, I mostly give ill-informed advice on IRC. Mar 11 18:37:26 perfect .. just like most of us :) Mar 11 18:37:54 (my hit/miss ratio is embarassing as of recent, zmatt keeps correcting me, luckily for the poor people) Mar 11 18:41:01 I mostly dev on beaglebones (except for things like the linux kernel). we do however have distcc setup so that compilation gets distributed to a fast build machine. this yields most of the benefits of cross-compilation with none of the hassle Mar 11 18:43:11 yeah, that seems common among professionals. Friend who does a lot of ARM embedded also does that. Mar 11 18:43:31 * looks up distcc Mar 11 18:44:02 thanks Mar 11 19:09:03 Rickta59: https://pastebin.com/raw/sYYjHghJ this is my overall setup Mar 11 19:10:11 the stuff at the end may seem a bit hacky, but unfortunately distcc doesn't automagically ensure a compiler for the right arch is used, so it's important to prevent "gcc" on the beaglebone from being distcc'd to "gcc" on the (x86) build server Mar 11 19:12:02 how many machines do you have in this setup? Mar 11 19:12:40 one build machine, one beaglebone Mar 11 19:14:13 although it's of course easy enough to use more devices on both sides Mar 11 19:15:17 i used to have a lot of machines .. i'm down to just one Mar 11 19:15:29 well if you don't count rpi/bbb Mar 11 19:15:33 one is enough Mar 11 19:16:29 there's a decent chance the beaglebone ends up the bottleneck anyway, since it's still doing the preprocessing and linking Mar 11 19:16:32 so i'm successfully spewing ws281x pulse streams from pru now .. pretty simple Mar 11 19:16:38 woop :) Mar 11 19:16:54 the hardest part was figuring out the remoteproc stuff Mar 11 19:17:21 and the comments in the pru sdk don't exactly explain what they are doing Mar 11 19:18:07 on the bright side, when you switch major kernel version, the remoteproc stuff will probably break again ;) Mar 11 19:18:37 i got all this going and now i'm doing an apt-get upgrade .. will see Mar 11 19:18:52 kernel on the bbb doesn't get upgraded with apt-get upgrade (deliberately) Mar 11 19:19:02 that works .. woop Mar 11 19:19:14 now to try the /opt/scripts/tool update Mar 11 19:19:35 is there any advantage of going from 4.14 to 4.19? Mar 11 19:20:17 presumably there are, otherwise linux would be done ;P Mar 11 19:20:42 not sure what the status of the 4.19 series is currently though, i.e. whether everything has been forward-ported from 4.14 yet Mar 11 19:21:00 hmmm .. maybe save that for another day Mar 11 19:21:48 I forward-ported uio-pruss a few weeks ago, and I think remoteproc-pru was forward-ported not long after that Mar 11 19:30:25 https://gist.github.com/RickKimball/e347a3c47e5ab1ed7170243e3a98722b that worked for me on debian with universal cape and hdmi/emmc/audio turned off with u-boot dts on Mar 11 19:31:38 for the guy having issues the other day ... forget who asked Mar 11 19:31:59 he had the problem with start stop to remoteprocx/state Mar 11 19:32:12 uhh, you mean universal cape turned on Mar 11 19:32:24 right on Mar 11 19:33:21 in the code i use PIN_MASK to set the __R30 Mar 11 19:33:45 and set it in the CFLAGS of the makefile Mar 11 19:34:55 so where does this PRU_gpioToggle come from? if I google for it, I just find an old (am335x-incompatible) uio-pruss example Mar 11 19:35:30 the code in /usr/lib/ti/pru-software-support-package/examples/am335x/PRU_gpioToggle Mar 11 19:35:38 comes installed in debian Mar 11 19:36:12 found it.. weird that google has a lot of trouble finding it Mar 11 19:37:12 is messing with STANDBY_INIT still required? I thought remoteproc-pru takes care of that Mar 11 19:37:33 (in general I feel like that's something the loader should do. py-uio does so anyway) Mar 11 19:37:35 heh .. that would be the kind of question i would ask you :) Mar 11 19:38:07 zmatt: hey, got a second in private for me? Mar 11 19:38:10 even more bizarrely, this example doesn't even make use of it Mar 11 19:38:22 uhh, I guess Mar 11 19:39:51 commenting it out seems to make no difference ... let me reboot and see if it still works Mar 11 19:40:00 it won't make a difference Mar 11 19:40:07 since this example doesn't make use of the master port Mar 11 19:40:37 master port as in __R30 making to gpio ? or is that something else? Mar 11 19:42:27 master port as in PRU access to the L3 interconnect Mar 11 19:42:46 * topic i haven't reached yet Mar 11 19:47:20 so is hotplugging working now in these latest images? Mar 11 19:48:40 * remember all the things that made me to decide to let the BBB percolate Mar 11 19:50:06 hotplugging what? Mar 11 19:50:11 usb Mar 11 19:51:03 uhh, hotplugging in general has always worked I think, even if some devices caused problems due to inrush current (because of the very inadequate output caps on the beaglebone) Mar 11 19:51:15 I do think the driver has become much less fussy than it used to be Mar 11 19:51:38 I haven't noticed any problems with usb myself recently, although I also don't use it very often Mar 11 19:52:11 hmmm didn't seem to like me plugging in a usb stick Mar 11 19:52:51 btw, for reference, this is what that example would look like using pasm (+ my common.h) https://github.com/mvduin/py-uio/blob/master/pru-examples/fw/toggle-pruio.pasm Mar 11 19:53:39 i was reading the different between pasm and clpru Mar 11 19:54:00 doesn't seem to like my usb wifi dongle Mar 11 19:54:28 hotplugging or in general? Mar 11 19:54:49 i just grabbed 2 things on my desktop it reject hot plugging both Mar 11 19:54:55 in what sense? Mar 11 19:54:57 powering down now to see if they work Mar 11 19:55:05 what error did you see in kernel log? Mar 11 19:55:18 [ 691.312036] usb 1-1: device descriptor read/64, error -110 Mar 11 19:55:23 disk Mar 11 19:55:30 ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x1004 with error -110 Mar 11 19:55:33 wifi Mar 11 19:55:43 neither of those look like hotplugging issues to me Mar 11 19:56:11 the latter looks like a crappy driver and/or poorly supported wifi chipset Mar 11 19:56:16 no idea what the former is Mar 11 19:56:24 it was the one i used to use with this Mar 11 19:56:34 * i may have added a module .. can't remember Mar 11 19:56:38 works find on an rpi though Mar 11 19:56:42 it might also be usb autosuspend issues Mar 11 19:56:48 many devices don't like that Mar 11 19:57:32 you can try adding usbcore.autosuspend=-1 to the kernel parameters Mar 11 20:03:10 seems to be happy with a dynex microsd reader Mar 11 20:04:28 * i did set the autosuspend -1 .. let me try the problem stick Mar 11 20:04:34 quit Mar 11 20:05:10 and now the usb stick is happy thanks that did the trick Mar 11 20:05:42 hmm .. i have a apple partion that .. hmm Mar 11 20:05:59 so, I'm pretty sure that means the problem is actually with the usb stick... unfortunately there are lots of crappy usb devices Mar 11 20:06:15 what does that actually do? Mar 11 20:06:31 the kernel parameter? disable usb autosuspend Mar 11 20:06:39 usb power request? yesh the disable Mar 11 20:06:57 so the kernel will never suspend devices that are idle Mar 11 20:07:08 does that happen in msecs? Mar 11 20:07:22 seemed like it had barely enumerated Mar 11 20:07:52 dunno when it gets autosuspended Mar 11 20:07:58 obviously not while transfers are in progress :P Mar 11 20:15:19 or it could have been a power issue Mar 11 20:15:31 now the wifi dongle shows up .. Mar 11 20:15:39 well then autosuspend=-1 wouldn't fix it Mar 11 20:16:27 i set autosuspend back to 2 and now it fails Mar 11 20:16:36 but iirc power issues (due to output cap / inrush current) cause loud yelling about VBUS in the kernel log anyway Mar 11 20:16:43 yeah, autosuspend issues Mar 11 20:17:13 Bus 001 Device 025: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter Mar 11 20:17:23 happy .. Mar 11 20:17:29 turned the speed down to 300 Mar 11 20:18:48 in fact, some googling shows that so many devices have problems with autosuspend, that instead of blacklisting devices that misbehave with autosuspend, generally only whitelisted devices get autosuspend enabled Mar 11 20:18:48 I have no idea why that default seems to be different on the BBB Mar 11 20:19:33 well thanks .. you are like the dex for BB :) Mar 11 20:19:51 i guess all these questions have been asked a million times :) Mar 11 20:21:19 "The USB specification states that all USB devices must support power management. Nevertheless, the sad fact is that many devices do not support it very well. You can suspend them all right, but when you try to resume them they disconnect themselves from the USB bus or they stop working entirely." Mar 11 20:21:46 so ultimately your devices are at fault here Mar 11 20:21:57 i'm sure they are all cheap things from china Mar 11 20:22:08 well the usb drive no Mar 11 20:22:12 stick Mar 11 20:23:32 hmm legit ftdi stick works without -1 Mar 11 20:24:47 proper 2A supply makes it happy with all devices wifi usb stick .. ftdi dynex microsd Mar 11 20:27:16 hah .. no .. reboot and hotplugged .. failed Mar 11 20:27:41 lol, this poor guy... https://bugzilla.redhat.com/show_bug.cgi?id=1196943 Mar 11 20:28:47 it could still be a power stability issue I guess. one way to check would be by using a powered usb hub and hotplugging into that Mar 11 20:29:00 maybe even an unpowered one might work Mar 11 20:29:06 (bus-powered I mean) Mar 11 20:30:53 pfff .. the ac power strip was off .. red herring mania Mar 11 20:32:11 maybe time to eat something :) Mar 11 21:18:28 Hello everyone, I need help and would be grateful for any help to understand what happened with a unit of my BBB wireless. I'm not looking for RMA, but only to understand what might have caused the board short circuit. Mar 11 21:18:56 Every help is welcome. Mar 11 21:19:28 power led blinks briefly when connecting power? Mar 11 21:19:53 probably the most common cause is exposing the beaglebone's expansion header pins to overvoltage Mar 11 21:20:09 I would like the help and opinion of those who have been using a BBBW for a while longer, to tell me their assessment regarding how much the board is sensitive to electrical surges. Mar 11 21:21:10 @zmatt What's making me worried is that I left the board off in halt at night and in the morning I was short-circuited. Mar 11 21:21:34 was it connected to anything via the expansion headers? Mar 11 21:22:06 what do you mean by "in halt" exactly? and how do you know it is "short-circuited" ? Mar 11 21:23:22 I just execute a halt on the command line and did not turn off the power at night before going to sleep. Mar 11 21:24:11 halt? that's a weird command to use. you don't mean poweroff ? Mar 11 21:24:26 I measured the resistance between the line VDD_3V3B and the GND and is <1.5R. Mar 11 21:25:01 yes, that is equivalent a power off. Mar 11 21:25:48 hm, historically they've never been equivalent, but maybe it acts like that on a beaglebone for some reason... never tried it I think Mar 11 21:25:54 I believe the voltage regulator contained in the eighth osd335x is damaged. Mar 11 21:26:12 and I don't know if that's actually a sensible measurement Mar 11 21:26:57 you still haven't answered the most important question: was it connected to anything via the expansion headers? Mar 11 21:28:38 @zmatt, ok, sorry. Yes, I have a 7 "LCD and an gpio output connected to an NPN with a 510R resistor (it drains around 5.5 ma while in high state). Mar 11 21:29:10 510R resistor connected at the base, I meant.. Mar 11 21:29:25 which specific lcd cape? is a schematic available? Mar 11 21:30:08 yes, this one http://www.newhavendisplay.com/specs/NHD-7.0CTP-CAPE-L.pdf Mar 11 21:30:49 and a DAC https://www.digikey.com/product-detail/en/adafruit-industries-llc/3006/1528-1696-ND/6058477 Mar 11 21:33:59 is it powered from 3.3v or 5v ? Mar 11 21:34:54 both, 3.3V and 5V. Mar 11 21:35:03 i mean about the LCD. Mar 11 21:35:10 this DAC with 5V. Mar 11 21:35:12 I meant the DAC, sorry Mar 11 21:35:20 SYS_5V or VDD_5V ? Mar 11 21:35:35 VDD_5V Mar 11 21:35:48 okay now we're getting in potential hazard zone Mar 11 21:36:37 the (badly named) VDD_5V net is tied directly to the 5V DC input (barrel jack), and in particular will never power down at software request Mar 11 21:36:52 normally it's used to provide power *to* the beaglebone Mar 11 21:37:04 right.. Mar 11 21:37:11 sys_5v is the 5v power output of the beaglebone, which is also what the lcd cape uses Mar 11 21:37:23 yes.. Mar 11 21:37:34 so now the question becomes whether the DAC pulls up any of the signal lines Mar 11 21:38:33 oh that DAC requires a lot of power Mar 11 21:38:45 right, it's not a DAC, it's an amplifier Mar 11 21:38:57 what I checked is that the DAC which is a class D has a current depressible consumption when it does not play audio. Mar 11 21:39:53 a what? Mar 11 21:39:54 I treat like a DAC because it gets direct signal from an i2s line. Mar 11 21:41:20 I was just passing more details on the dac or amplifier, ok .. Mar 11 21:41:20 btw if it can really draw 500 mA like the datasheet says, then using SYS_5V to power it might not be possible Mar 11 21:41:39 I just didn't understand what you said Mar 11 21:42:19 yes, so I prefer to plug in the 5V line of JAC, VDD-5V. Mar 11 21:42:51 hm, it seems like the digital signals to the DAC should be high-impedance with negligible leakage Mar 11 21:43:55 so the fact that the DAC remains powered while the beaglebone is off shouldn't cause a problem, as far as I can tell based on the datasheet Mar 11 21:44:03 I think yes. Mar 11 21:45:11 I'm very worried because I'm in the middle of a project and I think of using a custom BBBW as a basis and after this problem I'm completely lost. Mar 11 21:45:36 btw, "a gpio output connected to an NPN with a 510R resistor (it drains around 5.5 mA while in high state)." it is recommended to limit the current through a gpio to 4 mA Mar 11 21:46:17 we integrate beaglebones into our products and we've shipped many hundreds without any problems Mar 11 21:46:41 "it is recommended to limit the current through a gpio to 4 mA" :O Mar 11 21:47:12 I've dimensioned it to below 6ma .. that's what I read in the documentation :O Mar 11 21:47:33 4 or 6 mA, varies per pin, so I generally give the 4 mA advice for simplicity Mar 11 21:47:55 regardless it's not an absolute maximum rating, it's just that V_OH/V_OL values are specified at that current Mar 11 21:48:21 got it :O Mar 11 21:48:23 in general gpio are meant for digital signals, not for driving loads Mar 11 21:49:38 so, based on the information you've given I don't really know what could have caused your beaglebone to die Mar 11 21:50:49 Do you believe that if a GPIO is overloaded it can lead to a full board short circuit? Mar 11 21:51:34 I already have plans to exchange the driver for a FET ZXMS6004FFTA Mar 11 21:51:35 however like I said, most commonly beaglebones get damaged due to overvoltage. expansion header pins should never be exposed to significantly higher voltage than the relevant I/O supply (3.3V for most pins, 1.8V for the analog inputs). when the beaglebone is powered off, this means the pins may not be exposed to voltages significantly higher than 0V Mar 11 21:51:39 https://br.mouser.com/ProductDetail/522-ZXMS6004FFTA Mar 11 21:52:19 yes, exposing gpio to overvoltage can easily cause internal damage in the SoC that manifests itself as an internal short-circuit Mar 11 21:52:59 the typical symptom is that upon applying power to the beaglebone, the power led just flashes very briefly Mar 11 21:53:11 "when the beaglebone is powered off, this means the pins may not be exposed to voltages significantly higher than 0V" You helped me a lot!! Mar 11 21:53:39 (note: when testing to see if a beaglebone is dead, always remove all connections to external hardware first, to exclude any problems caused by that) Mar 11 21:54:00 "the power led just flashes very briefly" yes, that's what happens. Mar 11 21:54:23 yes, that's why it's generally safest to power external hardware from the 3.3v supply of the beaglebone itself Mar 11 21:54:51 connecting to independently-powered electronics requires a lot of care Mar 11 21:54:56 "(note: when testing to see if a beaglebone is dead... to exclude any problems caused by that) yes, i made this. a blue led flash one time. Mar 11 21:56:40 i'm looking at the ZXMS6004FFTA for a replacement for this npn because the energy requirement of it to commute is very low. Mar 11 21:57:56 Thanks a lot for the help. You took a huge load off my back. Mar 11 21:58:57 I was very worried that I could not identify the cause of the problem. So I will take more attention and provide no more energy for peripherals with the board off and no longer use halt, it was a serious mistake. Mar 11 21:59:12 but overall yes, the beaglebone is somewhat "fragile" if you mishandle it, are as all modern high-performance SoCs as far as I know (tiny transistors are easily damaged). but in our experience it won't die randomly, there's always a clear reason for it, generally having to do with mistakes in connecting electronics to it Mar 11 22:00:07 "but in our experience it won't die randomly, there's always a clear reason for it, generally having to do with mistakes in connecting electronics to it" THANKS A LOT for this! Mar 11 22:00:51 I'm working on a very important project and I was feeling lost for not knowing what damaged the board. Mar 11 22:02:37 I have how to have your email or some other contact to exchange experience? I promise I will not bother you. In any case, my main contacts are: rlucas@rlrobotics.com and Skype: roger.lucas Mar 11 22:02:53 sorry, no. I don't provide email support Mar 11 22:03:36 My sincere thanks for your time and attention. Mar 11 22:04:27 good luck :) Mar 11 22:04:51 thanks :) Mar 11 23:12:49 btw the rt5370 (148f:5370) wifi dongle works without any issues on debian 9.5 Mar 11 23:12:57 without any extra installs Mar 11 23:13:57 sorry 9.8 Mar 12 01:55:15 I have four motors... Mar 12 01:56:35 Does one of the L298 drivers on the MotorCape handle motor1 and motor4 in theory or should I put motor1 and motor2 inline instead of perpendicular? Right? Mar 12 01:57:25 I am looking at the schematic. The motor1 and motor2 or M1 and M4 are on the same L298. Mar 12 01:57:50 sorry. motor2 = motor4 Mar 12 01:58:47 So, would I place my leads in the terminals on the MotorCape in M1 and M4 for one set or in M1 and M2? Mar 12 01:59:05 B/c...I either need differential or inline. Mar 12 01:59:14 Not X. Mar 12 02:00:25 and, and Mar 12 02:01:41 Does the MotorCape run in loops/circles w/ all motors promoted towards one direction? I am missing something or my motors are "#@$*!" Mar 12 02:02:13 I am not being disrespectful. I am trying to understand. Mar 12 02:13:39 I think maybe I made a mistake w/ the software side of things. I am seeing now that the m1 and m4 are located on one L298 on the silkscreen.pdf, right? So, inline and not differential was an adverse thing to accomplish in software. Mar 12 02:13:40 ... Mar 12 02:15:36 So, if I wanted to have two, front "differential" motors, I really should have put the leads to the m1 (front left) and m4 (front right) in correlation w/ that idea. Mar 12 02:15:37 ... Mar 12 02:16:16 See! I was trying inline. So, I was trying to run the software w/ all forward but w/ m1 and m2 as inline on one L298. Mar 12 02:16:36 Aw! Mar 12 02:18:36 Just for reference, I would do a L298 for the left and then another for the rightside of the bots it can control. That is me, yep. Mar 12 02:27:12 Otay. I am done. Mar 12 02:30:07 I saw a set of those mecanum wheels. Those look cool for two-cubic sets of ideas. Like, everything seems okay until one drives three in some direction. Mar 12 02:30:12 dang it. Okay. I am done. Mar 12 02:40:45 quadratic-schmatic. Aw! Mar 12 02:57:08 Now, it is time to test connections instead of taking the bot apart. Elongated times are ahead! **** ENDING LOGGING AT Tue Mar 12 02:59:57 2019