<zmatt>
and I've never seen a beaglebone get damaged by "improper power down", it's almost always due to exposing I/O to overvoltage or overcurrent (usually overvoltage, e.g. due to incorrect power sequencing of external components)
<starblue3>
forgot I filtered out leave messages
<starblue3>
the ~twenty times I just pulled the cable so far didn't damage it
<zmatt>
neither did the thousands of times (if not more) we did over many years
thinkfat has quit [Ping timeout: 240 seconds]
Guest10 has joined #beagle
<Guest10>
Anyone have some idea why SYS_5V dont go higher then 1.1V?
<Guest10>
I already replaced the TPS65217C but the issue stay the same
<zmatt>
Guest10: after poweroff it's normal for sys_5v to linger at around 1.1v for extended time
<zmatt>
the description you gave earlier sounds like a fried AM335x
<zmatt>
the pmic tries to power up but detects overcurrent and immediately powers off again
<zmatt>
(most common reason is an AM335x with an I/O cell fried by exposure to overvoltage, which for some reason tends to cause an internal short of a supply rail, but the same pmic behaviour would be caused by any other component shorting one of the PMIC's supply outputs)
<zmatt>
given that you mentioned the power led doesn't turn on at all (not even a short flash) I'm more inclined to assume it's one of the 1.8V supplies that get shorted
<Guest10>
where should i be able to measure any short? I have two boards (rev C) here and can always do measurements between a working and a non working one
<zmatt>
this seems like an excessive amount of time to pour into a fried board
<Guest10>
Yes, i have read about this short flashing power-led. Its not the situation in my case.
<zmatt>
which means the affected power supply is one that's sequenced earlier than the 3.3V supplies
<Guest10>
Yes, i am willing to spend this amount of times into a fried board, because i bought this fried board like this to put the time into it. I dont have that much money and hope to fix it. The working rev-c is borrowed from a friend
<zmatt>
sounds like a lost cause to me, since usually it's the AM335x that's fried
<Guest10>
Is there any source i could get one for a good price? The ones on aliexpress are way too expensive.
<zmatt>
though I guess it depends on the amount of confidence you have in your rework skills :P
<Guest10>
I have done BGA soldering work some time ago and successfully replaced the TPS65217C on the board already
<Guest10>
I would still like to measure somewhere the short. Any idea on what capacitor i should be able to find the short?
<zmatt>
and an AM3358BZCZ100 is a fairly expensive component (~$20 @ 1 unit), it also seems poorly available right now (like so many electronic components)
<zmatt>
yeah, just check the schematic
<zmatt>
at least one of the 1.8V supplies can be measured on the P9 expansion header
<zmatt>
C14 is VDD_1V8 (LDO3), C16 is VDDS/VRTC (LDO1)
<zmatt>
VDD_1V8 (which is also available on P9) seems more likely to be the culprit, it would probably mean an analog input got exposed to overvoltage
<zmatt>
wow, someone else in that thread you mentioned actually had a shorted VDD_CORE
<zmatt>
interesting, I had no idea that was possible
<Guest10>
On P9 measured: AIN1 is shorted to ground. AIN2 and further are fine
<zmatt>
rest in peace AIN1 ... though the input itself being shorted to ground is obviously not reason enough for the board to power up, but if the input got blown up then my guess would be it also resulted in an internal short on VDD_1V8 or perhaps VDD_CORE
<Guest10>
C14 is shorted. C16 is fine
<zmatt>
yep, exactly as expected... VDD_1V8 is (among other things) the I/O supply for the analog inputs
<zmatt>
so someone probably exposed AIN1 to way more than 1.8V
<Guest10>
C11 (VDD_CORE) is fine
<Guest10>
Can the AM335x work without the VDD_1V8 ?
<zmatt>
afaik it's the internal esd protection that causes this, it is meant for dealing with brief spikes of overvoltage (caused by electrostatic discharge) by shunting them to ground, but sustained overvoltage will probably melt it into a puddle that shorts the supply rail to ground
<zmatt>
no, absolutely not
<Guest10>
Because VDDS_SRAM_CORE_BG and VDDS_PLL_MPU are powered by VDD_1V8 ?
<zmatt>
and a few more I'm pretty sure
<zmatt>
but yes those are critical supplies
<Guest10>
Maybe i find some way to split analog input from those
<zmatt>
I guess you could try removing FB2
<zmatt>
I *think* the AM335x _might_ be okay with leaving the analog inputs unpowered, though I'm definitely not 100% sure about that
ikarso has joined #beagle
thinkfat has joined #beagle
thinkfat has quit [Ping timeout: 240 seconds]
<Guest10>
FB2 removed - i have a working BBB without analog inputs. Great. Thanks. I dont even need those analog inputs.
starblue3 has quit [Ping timeout: 265 seconds]
starblue3 has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
noahm has quit [Changing host]
noahm has joined #beagle
johanhenselmans_ has joined #beagle
johanhenselmans has quit [Ping timeout: 252 seconds]
johanhenselmans_ is now known as johanhenselmans
<set_>
Okay. So, I have configured how to write a "1" and a "0" to the BBGW, cloud9-example stuff, in node.js/JavaScript and it is so slow...
<set_>
I thought I needed to open, write, close but writing is fine (I think for now).
<set_>
Or maybe I should be using streams...aw. Who knows?
<zmatt>
just use fs.writeFileSync
<zmatt>
it'll open the file, write the data, and close it again.. all in a single call
<set_>
Oh.
<set_>
I tried that way like you previously stated.
<set_>
I could not figure it out for some reason.
<set_>
Anyway, I used fs.writeFile() this time.
<set_>
That leaves the file open. I think.
<zmatt>
writeFile works the same as writeFileSync except writeFile is much harder to use (for no benefit in this particular situation)
<set_>
Oh.
<zmatt>
it is asynchronous and requires a callback
<set_>
Right.
<set_>
I was receiving too many errors using writeFileSync, i.e. all of which I could not debug currently.
<set_>
I am still trying to make the LED blink. Should I mess w/ /trigger?
<zmatt>
using writeFile will cause the exact same errors under the same circumstances as writeFileSync
<set_>
Hmm. Okay. I guess I will use it then.
<zmatt>
(except writeFile will usually report its errors via the callback instead of throwing an exception)
<set_>
Oh.
<Guest10>
zmatt, do you already have a BeagleV? If yes, what is your experience with it until now?
<zmatt>
I do not have a BeagleV, I have not registered to get one
<zmatt>
I wasn't aware the beta batch was already available? but I also haven't really been paying attention to it
<set_>
Anyway, breakfast time! I need to make some errand runnin' today. See you all later!
<zmatt>
afaik the BeagleV mostly targets people who are really excited about RISC-V and want to get their hands on a RISC-V system to be able to work on tooling, kernel support, etc
<Guest10>
"making it usefull for different tasks" :D
<zmatt>
but yeah, if you're lucky enough that it's an analog input that got fried (and not a digital I/O) then it can rescue a device for repurposing
<zmatt>
unfortunately people seem to fry digital I/O most often than analog inputs
<Guest10>
Then i was lucky to get cheap one with fried analog inputs
<zmatt>
yep
buzzmarshall has joined #beagle
xet7 has quit [Remote host closed the connection]
yCrazyEdd has quit [Ping timeout: 256 seconds]
xet7 has joined #beagle
thinkfat has joined #beagle
Daulity has quit [Read error: No route to host]
thinkfat has quit [Ping timeout: 265 seconds]
Guest35 has joined #beagle
Guest10 has quit [Ping timeout: 246 seconds]
Guest35 has quit [Quit: Client closed]
Guest88 has joined #beagle
yCrazyEdd has joined #beagle
Guest1042 has joined #beagle
Guest1042 has quit [Quit: Client closed]
Guest88 has quit [Ping timeout: 246 seconds]
thinkfat has joined #beagle
lucas_ has quit [Quit: Leaving]
thinkfat has quit [Ping timeout: 265 seconds]
mattb0ne has joined #beagle
Guest88 has joined #beagle
<Guest88>
hello internet, How easy is it to upgrade a BB-AI board RAM? to 2GB or 4GB?
<RossSchulman[m]>
Are there any stats on power draw for the PocketBeagle?
Posterdati has quit [Ping timeout: 245 seconds]
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #beagle
Guest88 has quit [Ping timeout: 246 seconds]
Posterdati has joined #beagle
thinkfat has joined #beagle
thinkfat has quit [Quit: Konversation terminated!]
thinkfat has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
thinkfat has quit [Ping timeout: 265 seconds]
thinkfat has joined #beagle
<zmatt>
RossSchulman[m]: that's probably highly dependent on how it's being used
vagrantc has joined #beagle
<RossSchulman[m]>
Yeah, I mean base stats, just at idle or whatever.
<zmatt>
a beaglebone with video and ethernet disabled (which should be reasonably close to a pocketbeagle) idling at fixed 1 GHz (cpufreq governor "performance") seems to be 0.17-0.18A
<zmatt>
well, the pocketbeagle is probably lower, there's probably lots of little things drawing power on the BBB
<RossSchulman[m]>
OK. I had seen an estimate on the web somewhere of 200mA
<RossSchulman[m]>
So that's perhaps a bet high.
<RossSchulman[m]>
But not unreasonable.
<RossSchulman[m]>
*bit
<zmatt>
it'll just depend... how idle is the system really? what exact kernel are you using? how warm is it?
GenTooMan has quit [Ping timeout: 250 seconds]
<zmatt>
there's undoubtedly also some variation from device to device
GenTooMan has joined #beagle
GenTooMan has quit [Excess Flood]
GenTooMan has joined #beagle
johanhenselmans_ has joined #beagle
johanhenselmans has quit [Ping timeout: 268 seconds]
johanhenselmans_ is now known as johanhenselmans
GenTooMan has quit [Ping timeout: 255 seconds]
thinkfat has quit [Ping timeout: 265 seconds]
GenTooMan has joined #beagle
Shadyman has joined #beagle
<set_>
https://pastebin.com/4PsmUgur is some source that I have come up w/ currently. This is not the final product.
<set_>
Obviously. But, there are a a few things I would like pointed out.
<set_>
Why is setInterval(perk, 10000); in the source not changing the outcome of the if statements in the while loop?
<set_>
Do I need an else statement too?
dlan has quit [Ping timeout: 240 seconds]
dlan has joined #beagle
<set_>
Or is that I am running the loop so quickly, the LED is malfunctioning?
<zmatt>
writeFileSync doesn't take a callback as argument
<zmatt>
it's just fs.writeFileSync(LED1, '1');
<set_>
Hmm. Is my callback (err)?
<set_>
Oh.
<set_>
I tried that idea before and got nowhere. I will try again. Dang it.
<zmatt>
and your perk() function is in an infinite loop and freezes your entire program
<set_>
hahahah. I thought so.
<set_>
Okay.
<zmatt>
(while attempting to turn the led on and off again at the maximum speed possible with 100% cpu load)
<set_>
Hahhaha. I knew something was odd.
<set_>
I just would not have put it that way.
<set_>
100%?
<set_>
Yikes.
<set_>
Is setTimeout better than setInterval in making a "wait" factor evident?
<zmatt>
setTimeout requests that a function is called once after a delay, setInterval requests that it be called periodically
<set_>
How am I using 100% cpu load?
<zmatt>
you have an infinite while-loop
<set_>
Aw.
<set_>
Okay. So, while do is sane while infinite is not so nice. Okay.
<set_>
No issue. I will look. I am already on for loops and do while loops for some reason.
<set_>
I knew trigger had something to do w/ it.
<set_>
I read Dr. Molloy's older materials on .c files and user LEDs on the BBB.
<set_>
I was about to put in streams to handle some specific instances...
<set_>
I guess I did not need streams. Phew.
<zmatt>
trigger is to configure the function of the led
<zmatt>
by default the usr0 led is configured to "heartbeat"
<set_>
Aw. Okay. Ha.
<zmatt>
to control a led manually you'll want it configured to 'none'
<set_>
Dang...I was not close at all.
<set_>
Okay.
<set_>
trigger to none.
<set_>
got it.
<set_>
Why are there addition symbols in the source after LED0?
<zmatt>
string concatenation
<set_>
Okay. Got it.
<set_>
Makes sense.
<zmatt>
well, that's arguable, but it's something multiple languages do
<set_>
Whelp, you are right.
<set_>
I guess I can try other things now that you told me. I can try to add more LEDs or add new patterns or do a push to the cloud9-examples.
<set_>
Is anyone even interested in those cloud9-examples codes?
<set_>
I figured I would try to update them to make them Linux compatible.
<set_>
Not just bonescript compatible was the idea people had for a while, i.e. years back. I never really got to it until now.
<zmatt>
you are not the person to be attempting to make or revise examples, you have no idea what you're doing yourself
<set_>
Okay.
<set_>
Well, someone needs to do it. People are too busy w/ this BeagleV board and GSOC.
<zmatt>
I'm not sure I agree with the goal either
<set_>
Oh.
<set_>
You mean, "attempting to update older source to make it useful in the current times?"
<zmatt>
no, the whole "it's better to not use a library" thing
<set_>
Oh.
<zmatt>
there should be no need to update the examples (other than maybe to be in a more modern style of javascript)
<set_>
Oh. I got you. That makes sense. It is hard enough keeping up w/ what people change constantly in styles of languages, i.e. python, javascript, and etc.
<zmatt>
I have no idea what you mean
<set_>
Not only does one have to change the source to the updated versioning of the language, one would have to update their "library" too.
<zmatt>
??
<set_>
Forget it.
<set_>
Sheesh.
<set_>
You know all this stuff and you still do not understand what I disuss at times.
<set_>
You are basically an encyclopedia of what no one knows how to research.
<set_>
Ship happens. << I can keep this up instead?
<zmatt>
I know many things; however what it is you're trying to say is often a complete mystery to me
<set_>
Fine. Caring about what the general consensus is currently is current affairs.
<set_>
I was just sharing.
<set_>
Argh.
<set_>
Anyway, you have taught me what I understand and cannot solve.
<set_>
You are awesome and nice but...
buzzmarshall has quit [Quit: Konversation terminated!]
<set_>
I know things and my temporomandibular joint is killing me. I talk while typing. I am cursed. Back to the BBB!