<set_>
I know I am sort of rerouting you but I see that it accepts RX, TX, and GND.
<set_>
RX and TX are 3.3v only.
<set_>
I would think it does not power the board via 5v.
<set_>
But who knows what others have accomplished so far?
<ball>
Thanks. I'll budget for a power supply too then.
<set_>
Are you using the BBB?
<set_>
I mean, are you using the BBB in this case?
<set_>
5v 2A is a good PSU for the BBB (I am pretty sure) but the board powers well off of USB from the host too.
<set_>
I have never really had any trouble powering the BBB from a host via USB unless heavier hardware was involved.
<set_>
But the 5v 2A is for barrel jacks.
<set_>
And you may want to make sure the barrel jack is the correct polarity. I think it is center positive for the barrel jack.
<ball>
set_: I'm thinking of buying a BeagleBone Black (and perhaps a BeagleBone Green). Not sure I'll be able to use USB for the console but I've had good luck with (3.3V) serial on other boards.
<set_>
Oh. This is connected via mini usb for the BBB or micro USB for the BBG.
<set_>
The serial does no power the board.
<set_>
Oh!
<set_>
I got what you are doing. Okay.
<set_>
So, barrel jack to the BBB and RX, TX, GND to/from BBB.
* ball
nods
<set_>
ha.
<set_>
I never really used the UART0 on the BBB that often since it is full blown Linux but I am startin' to learn more about its uses.
<set_>
Up, up, and otay!
<set_>
bbl!
<ball>
I hear the BeagleBones have more than one UART, so that's potentially really useful.
<ball>
(to me)
<set_>
Yeppers!
<set_>
they do. I think there are six or five of them that can be used.
<set_>
I need to check but I remember seeing /dev/ttyS1 - /dev/ttyS5.
<set_>
W/ the current images that are produced via whomever, the images I find or make, there are symlinks from ttyO1 to ttyS1.
<set_>
And so on...
<set_>
I never really found out if this was useful and b/c of the kernel changes or if this was a BBB thing.
<set_>
Anyway, they exist and can be used!
<ball>
Thanks!
<set_>
I mean...I saw others use it in their systems. I just remember at some point in time, /dev/ttyO1 was used while...
<set_>
Yep.
<set_>
Are you done w/ me yet?
<ball>
Sure :-)
<set_>
Alright, onto odd behaviors and readings!
<set_>
peace and harmony but only on Thu!
buzzmarshall has quit [Quit: Konversation terminated!]
Shadyman has joined #beagle
ikarso has joined #beagle
vigneshr has quit []
vigneshr has joined #beagle
Guest67 has joined #beagle
<Guest67>
Hi everyone
<Guest67>
I am looking to build nd flash linux od to beaglebone blue,If possible can anybody share the tutorial link.
rob_w has joined #beagle
Stat_headcrabed has joined #beagle
florian_kc has joined #beagle
Guest67 has quit [Ping timeout: 260 seconds]
ft has quit [Quit: leaving]
Shadyman has quit [Quit: Leaving.]
wiagn has joined #beagle
Stat_headcrabed has quit [Ping timeout: 260 seconds]
wiagn is now known as Stat_headcrabed
Stat_headcrabed has quit [Client Quit]
jfsimon1981_b has quit [Remote host closed the connection]
Guest40 has joined #beagle
<Guest40>
I want to purchase beagle bone AI 64 board but have a query that whether it has port for atleast 4 RS_232 communication interface
Guest40 has quit [Client Quit]
Guest40 has joined #beagle
Guest40 has quit [Client Quit]
Parduz has joined #beagle
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #beagle
<Parduz>
About RTC pcf8523: i've encountered this problem:
<Parduz>
(hwclock and timedatectl always returning "invalid argument", solved with 'hwclock --systohc --utc').
<Parduz>
The linked issues show that the driver was updated to handle the flag.
<Parduz>
I'm using an old Debian 10 IOT image, and my driver don't even handle the low battery flag: are the BBB drivers updated as the Raspberry one in the new BBB images?
Parduz20 has joined #beagle
Parduz has quit [Ping timeout: 260 seconds]
<ball>
I should really shut down because of the thunderstorm but my computer's building some software...
<ball>
Parduz20: I'm not ignoring you I just don't know anything about Linux on the BeagleBone Black.
<Parduz20>
ball: ok, np :)
Guest67 has joined #beagle
otisolsen70 has joined #beagle
<set_>
build!
Parduz20 has quit [Ping timeout: 260 seconds]
otisolsen70 has quit [Quit: Leaving]
ikarso has quit [Quit: Connection closed for inactivity]
alan_o has quit [Remote host closed the connection]
alan_o has joined #beagle
rob_w has quit [Quit: Leaving]
Guest67 has quit [Ping timeout: 260 seconds]
otisolsen70 has joined #beagle
Guest72 has joined #beagle
Guest72 has quit [Client Quit]
Parduz has joined #beagle
<Parduz>
@zmatt are you here?
Parduz has quit [Ping timeout: 260 seconds]
Parduz has joined #beagle
<zmatt>
Parduz: hmm?
<Parduz>
could you answer to my question of about 3 hours ago (if you can see it, or i'll write it again)
<zmatt>
yeah I'm looking
<zmatt>
Parduz: it sounds like this is a hardware issue caused by power supply instability?
<zmatt>
or insufficient decoupling of the rtc's poewr supply
<Parduz>
it could be. I'm more worried that the flags isn't handled properly, whatever the cause
<zmatt>
this isn't a driver "update", it's an ugly patch to work around a hardware issue, but the patch isn't really correct behaviour hence presumably hasn't been integrated upstream
<Parduz>
oh.. ok.
<zmatt>
you're getting "invalid argument" because the rtc has lost the current date/time (or at least the oscillator has stopped hence it has no idea how much time has elapsed)
<zmatt>
apparently this can happen due to power supply glitches, causing a very brief oscillator stop, but neither the rtc nor linux know that for a fact, they just know the oscillator has stopped, not for how long it has stopped
<Parduz>
isn't "invalid argument" a wrong "returned error"? it took me 2 hours to understand what wasn't right
<zmatt>
so linux has to play it safe and assume the rtc date/time is now unpredictable
<zmatt>
well that's the issue with syscall return codes, there's a rather limited selection to choose from
<zmatt>
I would agree it doesn't really sound like the right choice to me
<zmatt>
EINVAL normally means the programmer provided a wrong argument
<zmatt>
bbl
Parduz86 has joined #beagle
Parduz has quit [Ping timeout: 260 seconds]
<zmatt>
Parduz86: amusingly, the current version of the patch is also just broken
<Parduz86>
listening
<zmatt>
they broke it while forward-porting
brook has quit [Remote host closed the connection]
brook has joined #beagle
Parduz86 has quit [Ping timeout: 260 seconds]
brook has quit [Ping timeout: 276 seconds]
Parduz has joined #beagle
brook has joined #beagle
<LetoThe2nd>
just trying to get started with Yocto on the BeaglePlay. The current state of machine in meta-ti builds fine but after writing the wic to sd card I only get radio silence on the debug UART. Any pointers? Maybe @denix
<LetoThe2nd>
correction: there is the grub console, but it does not continue.
Parduz has quit [Quit: Client closed]
brook_ has joined #beagle
brook_ has quit [Read error: Connection reset by peer]
brook__ has joined #beagle
brook has quit [Ping timeout: 250 seconds]
Parduz has joined #beagle
Guest6 has joined #beagle
Guest6 has quit [Client Quit]
Parduz has quit [Ping timeout: 260 seconds]
<zmatt>
that always sucks when you get nothing at all... like, it could be crashing right away, or maybe it's doing fine but the console was not configured right, or anything in between
<denix>
LetoThe2nd: uh-oh, that's not good! I still haven't gotten my BeaglePlay... I tried to replicate everything after rcn-ee as close as possible, but might have missed some small detail...
<denix>
LetoThe2nd: what do you have in the boot partition on the SD card?
<LetoThe2nd>
denix: hm, okay. it seems that on my first try the silence was caused by me pressing the USR button during boot as the docs say. Without it, grub shows up but is stuck in the menu.
brook__ has quit [Remote host closed the connection]
brook has joined #beagle
cappie has joined #beagle
<cappie>
Yeah have the adc overlay enabled in the /boot/uEnv.txt and I think that works because I can see the device and the pins in the filesystem I just can't read them. I can try flashing a new bullseye image with 5.10 today. I am a little worried that the ADC hardware itself is damaged do you know of any ways to verify the hardware is working? The
<cappie>
VADC reference voltage is 1.8V and the ADC pins that are floating measured between 50mV and 500mV does that sound normal?
<zmatt>
there's no "normal" voltage for a floating ADC pin, it's undefined
<zmatt>
what exactly is the symptom yoi
<zmatt>
*you're having
<cappie>
reading from the ADC causes whichever program is reading it to hang and become an un-killable process I've tried the pyiiolib, Adafruit_BBIO, and cat /sys/bus/iio/devices/iio\:device0/in_voltage0_raw
<zmatt>
that doesn't sound good
<cappie>
If I put the ADC in continuous mode the reading process never returns anything, but it also can be killed
<zmatt>
so just for clarity, if you power-cycle the board and just run iio_info this also hangs? (without doing any sort of adc configuration or other custom interaction with it)
<zmatt>
I should setup a beaglebone to run bullseye, my test beaglebone here is still running the 2020-04-06 buster image (since that's still the current official image)
<zmatt>
I have trouble imagining how a SoC could get damaged in a way that could cause the ADC to hang but leave the SoC otherwise in a functional state... like, I'd expect ESD or overvoltage on ADC pins to either destroy the SoC (e.g. in the usual way by causing an internal short of supply rails) or to result damage in the analog parts of the ADC resulting in loss of functionality (e.g. garbage readings) or ...
<zmatt>
...accuracy, but that still wouldn't cause its digital logic to hang
<cappie>
Where can I find iio_info? I was trying
<cappie>
iioc = iio.Context()
<cappie>
dev = find_device('TI-am335x-adc.0.auto')
<cappie>
dev.channels[0].attrs['raw'].value
<cappie>
and the first time after reboot it says "device or resource busy" and the second time it hangs forever
<zmatt>
cappie: at least on the buster image iio_info and other iio utilities are installed by default
<zmatt>
hmm
<zmatt>
have you tried this on the buster image?
<zmatt>
the 2020-04-06 buster IoT image I mean (the current recommended image for BBB)
<cappie>
oh sorry I had a message yesterday, but yes I was originally on buster 2020-04-06 with 4.19.94-r73 kernel and had the issue so I tried updating the kernel to 5.10.168-bone71 and still have the issue
<zmatt>
very odd... btw you should generally stick to the -ti kernel series unless you have a very specific reason to
<zmatt>
but this is something that should absolutely work out of the box on the 2020-04-06 image
<cappie>
oh ok so your recommendation is the 2020-04-06 IoT image with which kernel?
<zmatt>
I mean it should probably work on any recent image or kernel, but using a known-good one was just a good idea to exclude variables
<zmatt>
otherwise, what image I'd recommend would probably vary depending on the user and application
Stat_headcrabed has joined #beagle
Stat_headcrabed has quit [Client Quit]
<zmatt>
anyway, very curious, I've never heard of a case where the ADC and _just_ the ADC is broken in the way you're describing, nor do I have any idea how one would even manage to damage the SoC in such a way
<zmatt>
I guess the analog domain of the ADC must have gotten damaged in a way that leave the digital domain waiting for some kind of signal that's never coming
<zmatt>
presumably due to exposing the ADC pins to overvoltage or ESD
<zmatt>
(which is typically how people get the SoC damaged)
<cappie>
oh ok the output of iio_info is
<cappie>
```
<cappie>
Library version: 0.19 (git tag: v0.19)
<cappie>
Compiled with backends: local xml ip usb serial
<cappie>
IIO context created with local backend.
<cappie>
Backend version: 0.19 (git tag: v0.19)
<cappie>
Backend description string: Linux vacuum 5.10.168-bone71 #1buster SMP PREEMPT Tue Feb 28 22:27:56 UTC 2023 armv7l
cappie was kicked from #beagle by zmatt [don't paste into chat]
cappie has joined #beagle
<cappie>
oh sorry! yeah the iio_info command fails to read channel 0 then hangs forever trying to read channel 1
<zmatt>
cappie: please don't paste stuff like that into chat, use a paste service like pastebin.com to share multi-line text snippets
<cappie>
ok I will use pastebin in the future!
<zmatt>
my only concern in this case would be whether (in attempts to debug issues) you've messed something up in the system (though even then I wouldn't know how you'd get this result), but if you say the problem is also present on a clean 2020-04-06 image then that is kind of case closed
<cappie>
hmm I don't think we overvoltaged it. It was reading an RTD. The cables are long and near a stepper motor so I guess ESD could be an issue I just thought it would have fried the board. Maybe I'll put some latching diodes or zeners or something on our setup and use this board for non ADC purposes.
<cappie>
thanks for your help zmatt! Do you have any preferred ESD mitigation strategies for the BBB ADC?
<zmatt>
ah see the fact that it used to work (and was part of a setup that also involves motors) but ceased to work would have been useful info to have
<cappie>
oh sorry well it never worked well
<cappie>
just sometimes it would work and sometimes fail
<cappie>
and then it never worked, but it always had the same failure mode of stalling forever
<zmatt>
maybe the adc was getting glitched out by whatever you were doing to its inputs, and eventually it failed entirely?
<zmatt>
maybe some kind of noise spikes getting coupled onto your measurement line
<cappie>
I suppose, but our other beaglebone is in the same setup and has been running for months
<cappie>
I am guessing noise spikes too
<zmatt>
or it got damaged by ESD resulting in erratic behaviour and eventually failure
<cappie>
yeah that could be perhaps we need some grounding mats on our test rigs
<cappie>
anyway thanks for helping out I love these little guys!
<zmatt>
also, with motors, be mindful of voltage drop across high-current supply paths including their ground paths
ikarso has joined #beagle
<cappie>
yeah the motor side is opto-isolated and cables cross at 90s
<zmatt>
ok
vagrantc has joined #beagle
<zmatt>
not sure then... we've also got a small cemetary of dead beaglebones, for some of them we know perfectly well what we did to murder the, sometimes it's less clear
<cappie>
oh yeah we def have some very known dead ones haha!
<zmatt>
accidently dropping a 7V supply lead onto the pcb is, for example, not advisable
jfsimon1981 has joined #beagle
<cappie>
oof we were doing a lot of 6kV static adhesion testing and def one board got a nice pretty arc...
<zmatt>
haha
Stat_headcrabed has joined #beagle
brook_ has joined #beagle
brook_ has quit [Read error: Connection reset by peer]
Stat_headcrabed1 has joined #beagle
brook has quit [Ping timeout: 240 seconds]
brook_ has joined #beagle
Stat_headcrabed has quit [Ping timeout: 260 seconds]
Stat_headcrabed1 is now known as Stat_headcrabed
Stat_headcrabed has quit [Quit: Stat_headcrabed]
Stat_headcrabed has joined #beagle
Stat_headcrabed has quit [Client Quit]
ft has joined #beagle
cappie has quit [Ping timeout: 260 seconds]
brook_ has quit [Remote host closed the connection]
brook has joined #beagle
Guest40 has joined #beagle
Guest40 has quit [Client Quit]
brook_ has joined #beagle
brook_ has quit [Read error: Connection reset by peer]
brook__ has joined #beagle
brook has quit [Ping timeout: 252 seconds]
alan_o has quit [Remote host closed the connection]
alan_o has joined #beagle
outrageous has quit [Ping timeout: 248 seconds]
vagrantc has quit [Quit: leaving]
otisolsen70 has quit [Quit: Leaving]
brook__ has quit [Remote host closed the connection]
vagrantc has joined #beagle
brook has joined #beagle
nslu2-log has quit [Quit: Disconnecting from stoned server.]
nslu2-log has joined #beagle
brook has quit [Read error: Connection reset by peer]
brook_ has joined #beagle
brook_ has quit [Read error: Connection reset by peer]
brook has joined #beagle
brook has quit [Read error: Connection reset by peer]
brook_ has joined #beagle
brook_ has quit [Read error: Connection reset by peer]
brook has joined #beagle
brook has quit [Read error: Connection reset by peer]
brook_ has joined #beagle
brook_ has quit [Read error: Connection reset by peer]
brook has joined #beagle
brook has quit [Read error: Connection reset by peer]
brook_ has joined #beagle
brook_ has quit [Read error: Connection reset by peer]
brook has joined #beagle
brook has quit [Read error: Connection reset by peer]
brook_ has joined #beagle
brook_ has quit [Read error: Connection reset by peer]
brook has joined #beagle
brook has quit [Read error: Connection reset by peer]
brook_ has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
brook_ has quit [Read error: Connection reset by peer]