<zmatt>
break detected generally either means wrong baudrate or the pin isn't muxed
<zmatt>
(uart rxd pin)
<zmatt>
receive fifo overrun means too much data was received that you didn't process fast enough
starblue1 has joined #beagle
<mattb0ne>
what is weird is was working fine and it will misbehave, I am wondering if it is hardware related
<mattb0ne>
like I can poweroff
<zmatt>
and close is a method on the I/O object (pruss.uart.io)
<mattb0ne>
and then boot up drop into python3 and just try and send a command through the UART and I will get the FIFO runtime error
<mattb0ne>
will close and reinit help you think if I get stuck with that
<zmatt>
FIFO overrun you mean... yes, once you configure the load cell to start spamming it will... start spamming. unless the data is being processed continuously you are guaranteed to get a receive FIFO overrun
<zmatt>
like, py-uio's uart interface is primarily meant to do initial setup of the uart and whatever device is connected to the uart prior to starting pru
<zmatt>
handling a continuous stream of received uart data is a real-time task that you can't really do in python, certainly not reliably
<zmatt>
if you try, receive FIFO overruns are pretty much guaranteed
<zmatt>
if you try from the REPL, they're definitely guaranteed :P
<mattb0ne>
hmmm
<zmatt>
the only thing here that looks weird is the break detected... all the rest looks like exactly what I'd expect to happen
<mattb0ne>
ok
<mattb0ne>
does reading from PRU have the same limitation
<zmatt>
no
<mattb0ne>
ok
<mattb0ne>
so maybe this is not my problem really...
<zmatt>
"Receive FIFO overrun" is a performance problem... you're not keeping up with the data as fast as it's being sent
<mattb0ne>
ok this error is generated after I get an error transmitted
<zmatt>
??
<mattb0ne>
one second let me pastebin something
<mattb0ne>
ok in my application in which the pru is reading the UART. I have been runnning fine but occasionally I will get the following to throw an error
<mattb0ne>
then when I try and trouble shoot I will try and interact with the UART through python
<zmatt>
okay, so that would be the "Break detected" .. like I said, that's pretty weird
<mattb0ne>
and that gave me that earlier paste bin
<zmatt>
basically it means the line was low for too long a time
<zmatt>
the rxd line
<mattb0ne>
so my code was running fine for 2 weeks did this behavior all the sudden fixed and now it is doing it again
<mattb0ne>
do you think it is wiring or HW possibly
<mattb0ne>
everything was working fine now it is not
<zmatt>
definitely possible... "break" is called that because in certain wiring setups it indicates a physical break in the cable
<zmatt>
does the uart rxd pin have pull-up or pull-down on the beaglebone side?
<mattb0ne>
let me check need to power on
<zmatt>
a power interruption of the load cell could cause it too
<mattb0ne>
pull up
<zmatt>
okay, then a cable break can't cause a break condition
<mattb0ne>
both txd and rxd
<zmatt>
power interruption of the load cell comes to mind, or maybe the load cell resets and produces some garbage on the line during that
<zmatt>
or something briefly shorts the rxd line to ground
<mattb0ne>
is there anyway to guard against that
<mattb0ne>
from the SW
<mattb0ne>
or is that someting where I need to check physical connections
<zmatt>
I mean, obviously you could add logic to python to automatically recover/restart when the system fails... but your first priority should probably be to figure out what's causing the failure to begin with
<mattb0ne>
now one of my C routinres works and does not throw the error so that makes me think I amd doing something wrong on the coding
<mattb0ne>
i can pastebin
<mattb0ne>
one second
<zmatt>
I don't see an obvious way you could cause a break condition through a software mistake, unless you're messing with the uart's registers
<mattb0ne>
no I havent changed the code
<mattb0ne>
could moisture and heat make a difference
<mattb0ne>
all my electronics are in a relatively well sealed box
<mattb0ne>
but it is sitting in a 95% humidity 37C incubator
<zmatt>
uhh, right now we don't even know what's going on that's causing a break condition to be detected... like, some of my guesses include the load cell resetting, but those are just _guesses_ ... if it doesn't out it *is* resetting then you can start wondering about what might cause it to do so, such as environmental factors, but that line of thinking seems excessively premature
<zmatt>
*if it turns out
<mattb0ne>
ok
<mattb0ne>
so my loadcells go to a summing box before going to the em100 digitizer that goes to the UART
<mattb0ne>
so I should be testing the EM100?
<mattb0ne>
or the actual load cells
<zmatt>
I've always meant the EM100, which is what you've previously referred to as the load cell hence which I'll continue to call that :P
<zmatt>
the-thing-driving-your-uart-rxd-line
<zmatt>
so again, a break condition means the rxd line was detected as being low (i.e. closer to 0V) for a longer amount of time than it can ever be as part of a normal character transmission. if this is actually happening on your uart rxd line then for example that's something a scope could capture if it has a way to trigger on "signal low for at least <this long>"
<zmatt>
if it's not something really happening at an electrical level the only alternatives are that the uart is confused, e.g. due to messing with its registers in a weird way, or the uart is being deceived, e.g. because the pinmux is being changed causing the uart to no longer be actually connected to the external pin
<zmatt>
if it *is* happening at an electrical level then the next question becomes why... a scope capture of the event might perhaps already give a clue, e.g. whether it's some form or interference or something the EM100 is doing. if it's something the EM100 is doing then the diagnosis would proceed from there
<mattb0ne>
ok
<mattb0ne>
all I do is play with the shared memory which I assume would not impact the UART at all
<zmatt>
correct
<mattb0ne>
and I definitely did not change the pinmux
<mattb0ne>
so I will scope tomorrow
<mattb0ne>
very strange
<mattb0ne>
was working fine for weeks
<mattb0ne>
now all over the place
<zmatt>
if you're suspecting software, then just go back to the last known-good version, which you obviously committed to git and/or backed up right?
<mattb0ne>
I can revert but the software was running fine as well
<mattb0ne>
the problem went away on its own and now is back
<zmatt>
definitely sounds more like hardware than software
<mattb0ne>
which makes me think it is HW but got to scope it
<zmatt>
next time it happens, try running this utility function to dump some data from the uart: https://pastebin.com/W9qXEjUK
<mattb0ne>
ok
<zmatt>
just for debugging
<mattb0ne>
so after it crashes run this
<zmatt>
yeah after the pru core has halted
<mattb0ne>
I dont catch the error so I would have to cntrl-c to get a prompt
<mattb0ne>
ok
<mattb0ne>
does it make sense that I cannot run io.close() without getting FIFO overrun
<zmatt>
??
thinkfat has joined #beagle
<zmatt>
io.close() never throws an error
<mattb0ne>
well I tried running again crashed immediately, i ran that dump script that you just gave me and it printed nothing probably because I bombed immediately
<mattb0ne>
so I tried to reset it without powering everything off
thinkfat_ has quit [Ping timeout: 272 seconds]
<mattb0ne>
so I go into python and try and call uart.io.close()
<mattb0ne>
and it gives me the FIFO overrun error
<mattb0ne>
want the stack trace?
<zmatt>
nothing you just said makes any sense
<zmatt>
the little function I gave (which is not a standalone script, it assumes there's a pruss already) should be executed when pru has aborted with this specific problem
<zmatt>
neither pruss nor its uart must be reset between the problem occurring and the debug function being run
<zmatt>
oh, close calls flush
<zmatt>
hmm
<zmatt>
but why are you calling io.close() at this point anyway? you shouldn't be accessing pruss.uart.io at all between the problem occurring and running my debug function
<zmatt>
I didn't realize close() calls flush() ... it makes sense though it's a bit annoying in this case
<zmatt>
but basically just don't use pruss.uart.io here
<mattb0ne>
ok
<mattb0ne>
ok I added the script
<mattb0ne>
but now watch it wont do it for a while
<mattb0ne>
*sigh*
<mattb0ne>
how is life zmatt. I always bomb you with noob questions but never really ask how you are doing
<mattb0ne>
things well?
<zmatt>
actually been kinda sick last few days, sore throat
<mattb0ne>
covid?
<mattb0ne>
sore throat is the calling card
<mattb0ne>
I garggle salt water when my throat is sore, it might be placebo but it makes me feel like something will happen
<mattb0ne>
also ice cream
<mattb0ne>
lol
<zmatt>
sore throat is pretty uncommon in covid afaik?
<mattb0ne>
no therapeutic benefit just taste good
<mattb0ne>
dry scratchy
<mattb0ne>
maybe not sore
<zmatt>
whatever I have doesn't seem lung-involved, it seems more like a flu or something... either way, haven't had an opportunity to get a test
<mattb0ne>
well otherwise I hope things are going alright for you. Just hot over here
<zmatt>
yeah it's warm here too :-/ it's fine now outside, but it was briefly excessively hot and my home still seems to have that heat absorbed
mattb0ne has quit [Ping timeout: 252 seconds]
mattb0ne has joined #beagle
mattb0ne has quit [Ping timeout: 245 seconds]
lucascastro has quit [Remote host closed the connection]
hays has quit []
hays has joined #beagle
hays has quit []
hays has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
<ds2>
regarding the UART thing - are there any level converters? those can cause similar symptoms
renrelkha has quit [Quit: bye]
renrelkha has joined #beagle
Steve__ has quit [Ping timeout: 244 seconds]
SJFriedl has joined #beagle
florian has joined #beagle
PhotoJim has quit [Ping timeout: 244 seconds]
PhotoJim has joined #beagle
akaWolf has quit [Ping timeout: 252 seconds]
akaWolf has joined #beagle
<zmatt>
oh right the EM100 uses actual proper rs232 or rs485... so maybe a break can indicate a broken connection after all
sicelo has quit [Ping timeout: 272 seconds]
sicelo has joined #beagle
sicelo has joined #beagle
indigaz has quit [Ping timeout: 252 seconds]
indigaz has joined #beagle
Shadyman has quit [Remote host closed the connection]
mattb0ne has joined #beagle
buzzmarshall has joined #beagle
ikarso has joined #beagle
lucascastro has joined #beagle
Guest4 has joined #beagle
<Guest4>
hello
<Guest4>
I do not know why my BeagleBone ai 64 is not booting up
<Guest4>
as a standalone w/keyboard + mouse
<Guest4>
can someone help me?
Guest448 has joined #beagle
Guest448 has quit [Client Quit]
vagrantc has joined #beagle
Guest4 has quit [Ping timeout: 252 seconds]
mattb0ne has quit [Ping timeout: 252 seconds]
florian has quit [Quit: Ex-Chat]
Shadyman has joined #beagle
brook_ has joined #beagle
brook has quit [Read error: Connection reset by peer]
lucascastro has quit [Quit: Leaving]
mattb0ne has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
<mattb0ne>
NicvServ IDENTIFY mattb0ne pass1234
<mattb0ne>
lol
<mattb0ne>
whelp
<zmatt>
amazing password choice matt :P
<zmatt>
also, you can avoid accidents like that by configuring SASL authentication in your irc client, see https://libera.chat/guides/sasl
<zmatt>
mattb0ne: it shows the uart saw a single isolated break (the first line), and the EM100 continued sending data after that so it evidently didn't reset
<zmatt>
hmm the second one is different
<zmatt>
here's my interpretation of the first one: https://pastebin.com/raw/BXGeSf2U so after the break there's still one and a half intact measurement and then it just starts to overrun because my python code only manages to read one or two bytes of each EM100 measurement before it already sends the next one again
<zmatt>
the second one has significantly more garbage at the start
<mattb0ne>
hwo did you interpet all that using the codes?
<mattb0ne>
and what do you think I should do to fix
<zmatt>
it looks like either some kind of noise/interference or maybe an intermittent connection that gets jiggled by vibration or whatever
<mattb0ne>
ok
<mattb0ne>
I will check the wiring
<mattb0ne>
do you think it is still worth scoping
<zmatt>
probably not
<zmatt>
dunno
<zmatt>
I guess it could still be informative, an analog scope on the rs232 line might be able to tell the difference between the two options I just mentioned, if you can manage to capture the event
<zmatt>
you're using some kind of rs232 receiver right?
<zmatt>
or rs485 ?
<mattb0ne>
no I just go straight into the beagle
<zmatt>
??
<zmatt>
maybe I misread the EM100
<zmatt>
no I didn't, it's clearly not possible to go "straight into the beagle", you would not be able to receive any data (and also almost certainly instant-fry the beaglebone)
<zmatt>
given that you *are* receiving data (and also your beaglebone isn't dead), you evidently have a suitable receiver in between the EM100 and the BBB
lucascastro has joined #beagle
<zmatt>
mattb0ne: my interpretation of the second paste, with an attempt at visualizing the garbage at the start: https://pastebin.com/raw/xZBBdaHb
<zmatt>
(with two possible interpretations... I'm not 100% sure how an uart behaves when a framing error continues into a break)
<zmatt>
dotted lines indicate parts that may be longer than drawn (spaces between chars and breaks)
<zmatt>
so yeah it really does look like some random garbage pulses
demirok has joined #beagle
<mattb0ne>
level shifter
<mattb0ne>
sorry
<mattb0ne>
wait
<mattb0ne>
let me check my amazon but I think I took a RS232 cord and just cut it
<mattb0ne>
so I have the EM100 going to that and the cord going into the Beagle
<mattb0ne>
i think it was a RS232 to TTL cord
<mattb0ne>
any chance I could fix this with a coding thing
<mattb0ne>
if i cannot find the source of the interference
_whitelogger has joined #beagle
brook_ has quit [Read error: Connection reset by peer]
ikarso has joined #beagle
brook has joined #beagle
cygnix has left #beagle [Konversation terminated!]
cygnix has joined #beagle
alan_o_ has joined #beagle
alan_o_ has quit [Client Quit]
alan_o has quit [Read error: Connection reset by peer]
alan_o has joined #beagle
alan_o has quit [Remote host closed the connection]
mattb0ne has quit [Ping timeout: 252 seconds]
mattb0ne has joined #beagle
akaWolf has quit [Ping timeout: 268 seconds]
alan_o has joined #beagle
Guest5 has joined #beagle
akaWolf has joined #beagle
Guest5 has quit [Ping timeout: 252 seconds]
mattb0ne has quit [Ping timeout: 268 seconds]
ikarso has quit [Quit: Connection closed for inactivity]