**** BEGIN LOGGING AT Tue Jan 28 02:59:57 2020 Jan 28 15:49:53 Hey guys, we are currently trying to communicate with a PmodNAV IMU through SPI from a BeagleBone Blue but are unable to do so. We successfully got data from the IMU with a BeagleBone Black in the past but our new setup uses a BBBlue. We tested the SPI connection to the IMU using an oscilloscope and noticed that the clock (SCLK) line has a level Jan 28 15:49:54 shift that leads to it not falling below ~0.7V during communication, which would be too high to be measured as a 0 by the IMU, is it something anyone experienced before with the SPI communication on the BBBlue ? Jan 28 16:09:55 Odsuv: sounds odd, it should definitely fall below 0.7V Jan 28 16:10:05 unless excessive current is being injected into it Jan 28 16:11:04 doesn't sound healthy does it?! Jan 28 16:11:17 pull-down should be fine Jan 28 16:11:25 well, technically the V_OL(max) is 0.8V at 4 or 6 mA (depending on the pin) Jan 28 16:12:00 wow thats quite high Jan 28 16:12:02 but there's no reason a slave should be injecting that much current anyway, and less current will mean a lower V_OL(max) Jan 28 16:12:09 yup Jan 28 16:15:10 (it's 6 mA for the io cell driving the SPI1_SCK signal on pin 5 of the S1.1 and S1.2 headers) Jan 28 16:16:32 Odsuv: so you may want to check what's going on electrically here, e.g. how much current is flowing from your IMU to the BBB via that pin Jan 28 16:17:12 zmatt: the CPU will be the same for BBB/BBBl .. so its something weird... Jan 28 16:17:25 or are they different SPI muxes? Jan 28 16:17:33 Okay, thanks, we'll try that and update. Would it not be weird that is works on the BBBlack without any issue though ? Jan 28 16:17:40 no muxes or anything, just a direct processor pin connection Jan 28 16:17:49 zmatt: on both boards? Jan 28 16:17:49 yes it is Jan 28 16:17:58 then .. there shold be no difference ;) Jan 28 16:18:13 veremitz: most I/O on most beaglebones are direct cpu connections Jan 28 16:18:23 Odsuv: do you see the same voltage problem on BBBk ? Jan 28 16:18:36 zmatt: yeah thas whatI thought, what makes them a bit vulnerable :) Jan 28 16:18:38 Not at all, the clock goes down to pretty much exactly 0V. Jan 28 16:19:00 have you changed the BBBl ? Jan 28 16:19:06 lemme check the blue schematic to see if anything unusual is going on on that pin Jan 28 16:19:08 not a rogue board Jan 28 16:19:29 We tried 2 BBBlue, one used a few times over the past six months, the other one almost never used. Jan 28 16:19:43 They are genuine boards, nothing weird. Jan 28 16:20:04 okies .. just eliminating some of the simpler things :) Jan 28 16:21:09 Sure, no problem, we have been trying to eliminate as much as we could on our side too that's how we got to the clock issue. Jan 28 16:21:33 fair enough Jan 28 16:22:17 nothing unusual is going on, pin 5 of S1.1 and S1.2 both connect directly to the relevant ball of the OSD335x (equivalent to P9.31 on the BBB, although on the BBB that pin actually also connect to the audio clk input of the HDMI framer, but this should have no significant impact) Jan 28 16:22:44 so, my guess is still that something weird must be going on electrically Jan 28 16:22:58 e.g. some subtle error in hookup Jan 28 16:23:04 of the IMU Jan 28 16:23:09 but I can't really imagine what Jan 28 16:23:34 unless you just connected the wrong lines :P Jan 28 16:24:41 Okay, we'll go through all the connections again, hopefully we just made a dumb mistake and solve it. Jan 28 16:25:15 and try inserting a current measurement between the BBBlue and the IMU on that pin Jan 28 16:25:44 also double-check your ground connection between the two devices Jan 28 16:58:23 zmatt Seems like you were right, cleaning up the connections makes it work now, thanks for the help. I also had to decrase the clock frequency a bit, anything above 20MHz does not work, might be due to our cables being ~80cm. Jan 28 16:59:50 It's still odd that the same setup didn't show any issue on the BBBk, but it's working so that's fine. Jan 28 16:59:52 note that SPI frequency is always divided down from 48 MHz, i.e. it's 48 MHz, 24 MHz, 16 MHz, 12 MHz, etc Jan 28 17:00:46 Oh good to know, we'll go for 16 or 12 then. Jan 28 17:01:45 and getting high frequency signals across 80cm would definitely require some care Jan 28 17:04:43 you'd need to make sure each signal is coupled to a suitable return path for HF (e.g. a ribbon cable that's ground, signal, ground, signal, ground, signal, ground, signal, ground, vdd) and you may need small series resistors at the driving side of each line to avoid ringing Jan 28 17:05:54 though to be honest, sometimes it just seems like magic to me what does and doesn't work... I've seen really iffy setups that had no right to work just work fine, and good connections that should have had no signal integrity problems, have signal integrity problems Jan 28 17:09:53 Okay, awesome, I took note of all of that, thanks again for the help. Got to go, have a great day/evening/night ! Jan 28 20:05:51 Anyone know where I can find the System Reference Manual for the Beaglebone Enhanced V1g? Jan 28 20:05:56 V1G* Jan 28 20:06:49 the BBE was created by SanCloud, I have no idea if they ever wrote an SRM. if they did I'd expect you can find it on their site or by googling Jan 28 20:07:24 yeah they may not have then Jan 28 20:07:28 sancloud Jan 28 20:07:32 sancloud Jan 28 20:07:52 sancloud's site has nothing I can find and the google search is exclusive to other boards like the black Jan 28 20:07:57 which I know are similar Jan 28 20:08:03 they are Jan 28 20:08:23 the expansion headers should be fully compatible with the beaglebone black Jan 28 20:09:58 iirc the BBE increases ram, swapped the ethernet phy out for a gigabit one, inserted a usb hub on the host port and attach a wifi chipset to one of the downstream usb ports, added some sensors to the local i2c bus... Jan 28 20:10:29 that's the main differences I think? Jan 28 20:13:23 okay thank you Jan 28 20:13:44 so I might be able to use the BBB SRM to help me through some things? Jan 28 20:15:48 depends on which things I guess Jan 28 20:16:39 right now I am trying to develop some stepper motor code (python) to communicate via SPI to an L6470 driver board from Sparkfun Jan 28 20:16:52 becoming more of a struggle than I anticipated Jan 28 20:17:20 that sounds like it should be relatively straightforward Jan 28 20:17:31 and fairly independent on which beaglebone variant you have Jan 28 20:18:49 in fact, apart from choosing the correct pins and configuring them to spi mode, it should be hardware-independent Jan 28 20:18:52 I am struggling with the SPI configuration Jan 28 20:19:15 trying to use SPI0 but keep getting spidev errors Jan 28 20:19:48 I'll figure it out. thanks for the help to this point Jan 28 20:20:36 so, unless there's software breakage on the BBE for some reason (it'll definitely be far less tested than the BBB), as long as you're running any not-ancient image, you should just be able to configure the four pins to spi mode using config-pin and then use /dev/spidev1.0 Jan 28 20:21:05 (the numbering is off-by-one for historical reasons, on the latest image there should also be a symlink /dev/spi/0.0 that returns sanity) Jan 28 20:22:43 I am following everything up until the last piece there. what do you mean by the symlink part and it being off by one? Jan 28 20:23:18 spi0 cs0 is /dev/spidev1.0 (while /dev/spidev0.0 doesn't exist) Jan 28 20:23:29 the spi bus number is 1 higher than you'd expect Jan 28 20:23:37 that's what I meant by off-by-one Jan 28 20:23:43 oh got it. okay I am with you Jan 28 20:23:56 thank you very much Jan 28 20:24:07 that can't be fixed without breaking backwards compatibility, so instead new symlinks were created that use sane numbering Jan 28 20:25:16 so if you system is recent enough to have them I'd recommend using /dev/spi/0.0 rather than /dev/spidev1.0 Jan 28 20:28:53 this is the error I keep getting: Jan 28 20:28:55 Traceback (most recent call last): Jan 28 20:29:18 if you just tried to paste multi-line output into chat... don't, it doesn't work Jan 28 20:29:26 use a paste service like pastebin.com and share the link Jan 28 20:31:42 does this work? Jan 28 20:31:44 https://dpaste.org/rQNt Jan 28 20:31:52 thats the error I keep getting Jan 28 20:32:20 can you share the contents of your /boot/uEnv.txt ? Jan 28 20:32:57 one sec Jan 28 20:33:32 since this indicates the spi controller is not enabled Jan 28 20:34:02 on a BBB running pretty much any image in default configuration, they would be enabled by default Jan 28 20:36:13 it doesn't exist lol Jan 28 20:36:19 what doesn't? Jan 28 20:36:21 there is nothing there Jan 28 20:36:26 ? Jan 28 20:37:26 I'm sorry, i missed a forward slash Jan 28 20:37:29 one second i have it Jan 28 20:42:30 if your beaglebone has internet access you can just do: pastebinit /boot/uEnv.txt Jan 28 20:42:50 and it'll create a paste for you Jan 28 20:46:15 the nano copying thing is impossible lol Jan 28 20:47:02 even if pastebinit doesn't work (e.g. no internet access from the beaglebone), I definitely wouldn't use an editor, just "cat /boot/uEnv.txt" and then copy-paste from the terminal Jan 28 20:49:00 https://dpaste.org/DaPv Jan 28 20:49:04 there we go Jan 28 20:49:32 hmmm Jan 28 20:50:56 so cape-universal doesn't work on the BBE? that feels worthy of a bug report Jan 28 20:51:00 oh well, plan B Jan 28 20:51:10 change line 19 to: Jan 28 20:51:20 uboot_overlay_addr4=/lib/firmware/BB-SPIDEV0-00A0.dtb Jan 28 20:55:22 okay its rebooting Jan 28 20:55:54 hopefully /dev/spidev1.0 should now exist Jan 28 20:56:30 (just check ls /dev/spi* ) Jan 28 20:58:07 So when I run that in the terminal it shows that it exists Jan 28 20:58:08 however Jan 28 20:58:19 when I run my program, it gives me the same error Jan 28 20:59:17 that seems unlikely Jan 28 20:59:37 but also, what library are you using? avoid the adafruit stuff, a lot of it is broken Jan 28 21:00:54 lol i am using the adafruit_BBIO library Jan 28 21:00:57 (just use e.g. the "spidev" python library) Jan 28 21:00:59 what do you suggest? Jan 28 21:01:11 any generic spi library for linux is fine Jan 28 21:01:49 if it's not installed you can just do "pip3 install spidev" (as normal debian user) Jan 28 21:02:22 I need internet for that right? Jan 28 21:02:45 one second on that Jan 28 21:02:46 oh yeah... it's probably already installed though, I'd guess Jan 28 21:02:59 since my guess would be adafruit_BBIO depends on it Jan 28 21:04:36 unless you're using python2 (since iirc a lot of the adafruit crap doesn't even work in python3)... in which case, since you really should be using python3, it may need to be installed Jan 28 21:05:07 no I am using python 3 Jan 28 21:05:12 ok good Jan 28 21:05:14 python 3.5.3 actually Jan 28 21:05:31 which I know isnt the most up-to-date version but yeah python 3 Jan 28 21:05:35 yeah, I hope buster becomes the default image soon Jan 28 21:06:55 succesfully installed spidev-3.4 Jan 28 21:07:35 still same errors though Jan 28 21:07:39 hmm Jan 28 21:07:54 error* Jan 28 21:08:35 oh well my code is written for the adafruit stuff... Jan 28 21:08:38 keep in mind you'll need spi.open(1,0) Jan 28 21:08:46 when using spidev Jan 28 21:09:55 Well now I compiled Jan 28 21:09:57 no errors Jan 28 21:10:02 annoyingly it seems python-spidev doesn't accept a path Jan 28 21:10:03 thats a good start lol Jan 28 21:10:06 thank you very much Jan 28 21:11:49 it's also perfectly feasible to use pure python: https://pastebin.com/E8Rk58SQ Jan 28 21:12:37 it wouldn't be hard to wrap this in a class... I feel like surely someone must have done that already Jan 28 21:14:02 I would think so by now Jan 28 21:16:11 thanks again for your help though Jan 28 21:16:15 much appreciated Jan 28 21:16:21 you're welcome Jan 28 23:06:06 does anyone know how to use the encoder block in simulink? The output is stuck at 0, is that a problem with the hardware support packages or am I doing something wrong? any comments would be appreciated Jan 28 23:06:17 for the beaglebone blue Jan 28 23:36:55 wheeeeeeeeeeeeeee 300% improvement Jan 29 01:06:25 falcon: this isn't really the place for support for third-party commercial software... maybe try mathworks support? Jan 29 02:06:06 falcon: yt? Jan 29 02:06:13 :-/ Jan 29 02:06:22 hey jkridner, got my email? Jan 29 02:06:27 I did. Jan 29 02:06:35 haven't grok'ed it yet. Jan 29 02:06:55 gotta get back to the problem again some time soon. Jan 29 02:07:41 I had hoped I'd managed to make it fairly straightforward Jan 29 02:07:46 I will test the overlays. Jan 29 02:08:34 hopefully I didn't make any typo, I haven't even checked whether they compile... I probably should have, lol Jan 29 02:08:36 I'll have a board up in the morning (unless I get a wild hair and stay awake) and I'll merge the example commits, reboot and test. Jan 29 02:09:09 although the nodes are pretty simple, shouldn't be much that can be wrong Jan 29 02:09:57 makes a world of difference having an explicit example Jan 29 02:10:50 hmmm 300% isn't enough Jan 29 02:11:07 fortunately the same snippet basically works for all versions of remoteproc, with the caveat that one of them used relative addressing within the subsystem Jan 29 02:11:32 ds2: well, then make it faster Jan 29 02:11:50 if @#$@!#!@#@!#!@ TIDL wasn't such a POS Jan 29 02:13:41 :-( Jan 29 02:13:57 you almost make me want to try it out Jan 29 02:14:23 ds2: I'm really hopeful the TFLite stuff will make it sane. Jan 29 02:14:40 it's not too late to make uio-eve ;-) Jan 29 02:16:49 jkridner: thinking of proposing a GSoC project to divide tidl into layer accelerator but even doing the ground work for that is an ARRRRGGGGGG Jan 29 02:17:58 For the C66x stuff, the OpenCL is sane. Jan 29 02:18:15 YOLOv2-tiny is down to 15sec per frame w/o TIDL (vs abut 30 sec before) Jan 29 02:18:17 I'm not sure what TIDL is doing to provide optimized "kernels" for layer implementations. Jan 29 02:18:29 not cool it seems to be closed right now. Jan 29 02:18:43 TIDL is encumbered with these objects hiding everything Jan 29 02:19:08 and you can't pass weights, etc directly to an object. the object wants to read it from a file which in turn references another file Jan 29 02:19:26 ew Jan 29 02:19:48 the opencl stuff seems to be very size limited...suspect rpmsg is the culprit Jan 29 02:20:01 zmatt: you can say that 2^64 times :D Jan 29 02:20:09 no I can't Jan 29 02:20:32 :P **** ENDING LOGGING AT Wed Jan 29 02:59:57 2020