buzzmarshall has quit [Quit: Konversation terminated!]
Guest40269 has joined #beagle
rob_w has joined #beagle
Guest40269 has quit [Quit: Client closed]
Guest40269 has joined #beagle
Daulity has quit [Ping timeout: 268 seconds]
LetoThe2nd has joined #beagle
robert__ has joined #beagle
Guest40269 has quit [Quit: Client closed]
Guest40269 has joined #beagle
Guest40269 has quit [Quit: Client closed]
Guest40269 has joined #beagle
frostsnow has quit [Ping timeout: 256 seconds]
florian has joined #beagle
<jduchniewicz>
I just read about the plundervolt set_
<jduchniewicz>
sounds scary :)
<jduchniewicz>
if I understand correctly the root cause of the problem is bit flips caused by undervoltage?
frostsnow has joined #beagle
<zmatt>
well the root cause of the problem is allowing lower-privileged software to mess with the voltage regulator of a core running higher-privileged software
<zmatt>
(and/or the clock generator thereof)
<zmatt>
if you can selectively overclock a core at specific moments while it's executing code, you can obviously introduce faults
robert__ is now known as Daulity
<Daulity>
zmatt: we solved the problem with our uart
<Daulity>
there was no problem lol
<zmatt>
those are the best problems
<Daulity>
the hardware was fine but our senior programmer made a cable that was wrong ...
Guest40269 has quit [Quit: Client closed]
Guest40269 has joined #beagle
<kveremitz>
^ that statement amuses me.
<kveremitz>
that said, been there, knowing to look for that kinda fault helps :)
<kveremitz>
s/look/check/
<kveremitz>
I call it 'sanity checks'
<kveremitz>
quite frequently it is confirmed - I /am/ insane. This is fine by me. :D
<zmatt>
lol
<kveremitz>
I blame it on my genes..
<kveremitz>
tl;dr - don't make assumptions .. you could be wrong (and assumptions quite frequently have flaws..)
<zmatt>
well in this case it was already known that the two wires were swapped, so there's really only two places where that swap can be: inside the device, between the transceiver and the connector, and outside the device, in the cable
<Daulity>
well one of our production workers made that cabel for him and that is why he was absolutely certain it was not the cable lol
<zmatt>
I guess it could also have been the remote device, unless you were connecting to a known-good device or an existing operational bus
<Daulity>
it was connecting to a existing operational bus
<zmatt>
was the cable incorrectly made or incorrectly specified?
<Daulity>
incorrectly made
<zmatt>
oof
Guest40269 has quit [Quit: Client closed]
<jduchniewicz>
oh yes I was going crazy with debugging an Arduino Nano 33 IoT via SWD, turned out my solder tip oxidized and the solder some times conducted and at other didn't
<jduchniewicz>
cleaned the tip, resoldered and voila
<jduchniewicz>
just out of curiosity, did any of you have experience with Lauterbach software/hardware?
Daulity has quit [Remote host closed the connection]
<kveremitz>
not here yet no sorry
Guest40269 has joined #beagle
rob_w has quit [Quit: Leaving]
Guest40269 has quit [Ping timeout: 246 seconds]
Shadyman has quit [Quit: Leaving.]
ikarso has joined #beagle
lucascastro has quit [Read error: No route to host]
argonautx has joined #beagle
charlie5 has quit [Ping timeout: 250 seconds]
ikarso has quit [Quit: Connection closed for inactivity]
Guest26 has joined #beagle
<Guest26>
Hello, is there still somebody out there using the beagle board?
<Guest26>
I'm facing an SPI Problem and don't know how to solve my issue (SPI works, but between bytes the Voltage of the MOSI-Line decreases very slowly...)
<zmatt>
which "beagleboard" ?
<Guest26>
Hi zmatt ... it has the AM335x Processor on it
<zmatt>
then you mean beaglebone, not beagleboard
<zmatt>
MOSI is tristate when no SPI transfer is in progress, hence it wil slowly float up or down depending on whether there's a pull-up or pull-down configured on the line
<Guest26>
thank you, Beagle Bone Black was the right answer...
<Guest26>
okay, i observe this behaviour ... but it confuses my spi slave device....
<zmatt>
this is normal
<Guest26>
is there a way to supress this tristate mode?
<zmatt>
then your spi slave device is broken, it should not care about MOSI when there's no clock, and it should ignore the bus entirely when its chip select is deasserted
xet7 has quit [Read error: Connection reset by peer]
<Guest26>
I tried to use an external pulldown resistor to "sharpen" the edge but it's still no sharp transition.
<zmatt>
if it's a problem that the line hovers for too long at an intermediate voltage, you could add an external 1 kΩ pull-up or pull-down resistor
<zmatt>
note that SPI does not define any action on MOSI edges... MOSI is only to be sampled at an SCLK edge (rising or falling, depending on SPI mode)
<zmatt>
in the absence of an SCLK edge, MOSI is "do not care"
xet7 has joined #beagle
<Guest26>
yes, you are right. the device is only interested into the mosi line when clock signal changes ... but: I have an bus isolator which does not like these slow transistions.
<zmatt>
then it seems you chose a bus isolator which is not well suited for the purpose
<Guest26>
obviously :-( (ADUM3154)
<zmatt>
mosi is tristated because it the SPI controller doesn't have a fixed MOSI line, it has d0 and d1 lines and which one is MOSI and which one is MISO is configurable per slave device... outside of SPI transfers there's no slave device selected, hence neither d0 nor d1 is mosi
<zmatt>
page 1 of the ADUM3154 datasheet is showing a block diagram where the MO input has a smith-triggered buffer
<zmatt>
that would normally imply it shouldn't care about transition time
<zmatt>
yep, typ 500 mV input hysteresis is specified
<zmatt>
what problem are you actually seeing? what makes you think that slow transition time on MOSI is the problem?
<Guest26>
yes ... that's right but ... well I try to explain
<Guest26>
... with a very slow falling voltage on MISO... there is a point in time when the adum switches it's output. and under very bad timing conditions it is possible that at this moment the next (sharp) MOSI-transition occures.
<zmatt>
ah
<Guest26>
and because of the just transmitted signal .. it looks like an short delay of the MOSI signal...
<Guest26>
i saw, there are bus-holder-ics which could solve the problem
lucascastro has joined #beagle
<zmatt>
so really what you want is a bus-keeper to eliminate the transition entirely
<zmatt>
yeah that
<zmatt>
you don't need a special IC, just replace the 1 kΩ pull-up or pull-down with a buffer with 1 kΩ series resistor on its output
<Guest26>
but well... i wondered if there is a software / configuration way to stop the tristate behaviour...
<zmatt>
afaik no, for the aforementioned reason
<zmatt>
it would have been nice if I/Os in general could have the internal pull be configured to "bus keeper" mode instead of only up/down/disabled but alas this is not the case
<Guest26>
Ok, thank you very much for your hints and assistance. Now I know that there is no way to stop the tristate-behaviour between the bytes..... and it's time to check the different hardware-solutions -.-
<Guest26>
ok. thank you very much for your help!
<Guest26>
(=
<zmatt>
good luck!
<Guest26>
have a nice weekend
Guest26 has quit [Quit: Client closed]
buckket has quit [Remote host closed the connection]
Ankit49 has joined #beagle
buckket has joined #beagle
<Ankit49>
@zmatt - sorry for late reply. I want to know "How can I find compatible u-boot -- uEnv.txt - uImage versions. ?
<zmatt>
I don't know what that question means really
<zmatt>
what's an "uImage" ?
buzzmarshall has joined #beagle
<zmatt>
like I said, I don't actually have any experience with the part of netbooting after u-boot gets loaded, maybe kveremitz can comment
<Ankit49>
Ok. Thanks
charlie5 has joined #beagle
<kveremitz>
most of the board using uboot these days have a separate uEnv.txt file which can easily be manually edited, and the kernel is an ordinary zImage
<kveremitz>
modern versions of uboot I believe can load compressed kernel images, but I'd defer over to rcn-ee for that specifically
<kveremitz>
boot.scr and embedded uImages are a bit of a pain for configurability
<kveremitz>
(and hence development)
<kveremitz>
most boot ROMs will cope with an elf-style binary which uboot produces as its primary loader (SPL)
<kveremitz>
(I think its elf- or its The Other One, someone may correct me)
<kveremitz>
netbooting .. I'm not sure exactly what uboot points at .. but you might get some insights from the BBBlfs project which allows you to usb-boot a board to expose the eMMC as a flash 'drive'
<kveremitz>
that could also be TI-specific
<kveremitz>
I've done more x86 netbooting than ARM ever ..
<kveremitz>
and that's not a lot (before I discovered initramfs, and other things..
<kveremitz>
(rootfs on nfs, etc)
<kveremitz>
apologies that might be a scatter-gun kinda answer
<kveremitz>
zmatt: FYI uImage is some uboot-friendly-packaged kernel image (I forget what the extra 'sauce' is exactly)
LetoThe2nd has quit [Quit: Connection closed for inactivity]
set_ has quit [Ping timeout: 250 seconds]
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #beagle
<zmatt>
is that like a historic thing, given that u-boot clearly has no issue loading a normal kernel image?
florian has quit [Quit: Ex-Chat]
vagrantc has joined #beagle
<rcn-ee>
it is, u-boot didn't get the ability to load normal "zImage" till about 2012... for long time you had to use mkimage, which stuck a crc/header on top of zImage -> uImage..
<vagrantc>
and support for zimage wasn't consistently available in most platforms by default till much more recently ...
johanhenselmans has quit [Ping timeout: 252 seconds]
johanhenselmans has joined #beagle
Guest40 has joined #beagle
Guest40 has quit [Quit: Client closed]
<zmatt>
kveremitz: so what are the steps for PXE boot you used? you have a reference?
<zmatt>
netbooting is still something that interests me, I should try it again some day
<zmatt>
oh right, I used also netboot via usb to put beaglebones into an UMS mode (g_mass_storage-based, like bbblfs)... that's very similar except I didn't need any rootfs, it just run out of its initramfs
Ankit49 has quit [Ping timeout: 246 seconds]
<kveremitz>
zmatt: bit rusty tbh, but BOOTP/DHCP obviously, which sends kernel[/initramfs] with some cmdline option for where to find the nfsroot iirc
<kveremitz>
which I think is TFTP?
<kveremitz>
along those lines, I'm sure its easy enough to fill the gaps from there
<zmatt>
I mean, you're just describing basic tftpboot, I assumed PXE was something more specific