**** BEGIN LOGGING AT Tue Feb 08 02:59:57 2022 Feb 08 03:14:10 The command reset works! Feb 08 03:15:11 brb Feb 08 03:31:01 @zmatt: Did you see my latest post? I showed what happens on Win 11 machines w/ the cat /etc/dogtag and uname -r commands. Feb 08 03:32:06 I know it is not a Linux machine, yet. But...the machine I use to BBB' is showing some oddities. Feb 08 03:32:34 This may be useful for people not understanding this idea of error and malfunction. Feb 08 03:55:53 I know there are only five minutes left in chat time but... Feb 08 03:55:59 Here goes it! Feb 08 03:56:46 Do you think that the USB-C to USB 3.0 when not correctly sourced would create a "malfunction" like this post I made? Feb 08 03:57:26 For instance, it shows SS on the port but the port is black and not blue. Feb 08 03:57:42 I may have been tricked? Feb 08 04:08:13 Do you think that USB 3.1 v1 or v2 would be better for connection host to target for the BBAI, i.e. rather than USB 3.0? Feb 08 04:12:16 Anyway. Past 10:00. Until tomorrow! Feb 08 07:02:13 think that reasoning went out the window with the "no need to write your own DT/Uboot mod/x-loader mod idealogy" Feb 08 07:02:39 but that at least is a sign of sanity Feb 08 07:02:44 ? Feb 08 07:03:15 sorry, ds2: correct... why would you intentionally toggle the pull .... Feb 08 07:03:15 whether the final configuration is applied by a custom DT, DT overlay, or using config-pin is immaterial Feb 08 07:03:31 I don't see your point Feb 08 07:03:44 a custom x-loader would minimize the potential time of conflict Feb 08 07:03:56 or MLO or whatever name of the day/flash :D Feb 08 07:04:10 "conflict" ? if there's "conflict" you misdesigned the hardware Feb 08 07:04:35 there are times when you don't have a choice... i.e out of routing resources or free GPIOs :/ Feb 08 07:04:54 if the reset-default pull is not what you need in a particular purpose, use a pin that has the desired default pull or override the internal pull with stronger external pull Feb 08 07:05:12 the internal pull is kinda mostly just to keep pins from floating anyway Feb 08 07:05:32 i understand all that... I am just trying to see where the default images land things Feb 08 07:05:55 I'm assuming/hoping they preserve the reset defaults, I haven't actually verified Feb 08 07:06:01 oh :D Feb 08 07:06:14 cape-universal is not devoid of flaws ;P Feb 08 07:06:36 discovered this while trying to be lazy - wiring in push button switches w/o external pulls Feb 08 07:07:01 I mean, you can do that just fine as long as you setup the pin correctly Feb 08 07:07:20 even resorted to use plug in breadboards and loose random plug in wires :D Feb 08 07:08:20 for the next experiment - hot plug I2C :D Feb 08 07:08:50 ah, you want to test the driver's fault recovery code? Feb 08 07:09:39 since the omap-i2c controller's state machine will lock up if you pulse the sda line low :D Feb 08 07:09:42 well, I am hoping it won't come to that... I am isolating it with a I2C 1:8 mux - sw will switch to a terminated port (just pull ups) and switch back when the new device is detected Feb 08 07:12:17 I hope that condition is detectable and that block can at least recover with a block reset Feb 08 07:13:56 yeah the driver should detect it and recover Feb 08 07:13:57 iirc Feb 08 07:14:58 if all goes well, I'll find out if the driver notices this weekend Feb 08 07:15:33 what I am a bit worried about is - will the i2c device drivers propertly disconnect Feb 08 07:17:38 if you manually unbind them you mean? Feb 08 07:18:17 great question, that might not be well tested :D Feb 08 07:21:25 yeah... that sysfs incantation Feb 08 07:27:33 ds2: cape-universal's defaults match the reset defaults for the non-eMMC non-HDMI pins (i.e. the pins for which cape-universal is enabled in the default config), but its defaults for the eMMC/HDMI pins (when these functions are disabled in /boot/uEnv.txt) could use improvement: https://pastebin.com/raw/UXa6U9ft Feb 08 07:28:31 pulling down the eMMC pins is pointless, it's overpowered by the external pullups Feb 08 07:29:36 and it probably ought to leave the sysboot-pins high-z, or at least not create a pull-up/down conflict with the external weak pulls Feb 08 07:41:44 pulling down against external pull up is just a bad idea Feb 08 07:43:37 (from a heat and a noise prospective) Feb 08 07:52:19 the internal pull is fairly weak anyway... but yeah it's definitely suboptimal Feb 08 10:01:32 set_: absolutely nothing in your long post in nmingotti's thread is even remotely relevant to the topic Feb 08 10:23:36 Good morning, Feb 08 10:24:06 Do you know if Gnd and Analog ground can be safely tied together ? Feb 08 10:34:48 jfsimon1981: in fact it's recommended to do so unless you're very confident you know what you're doing Feb 08 10:35:50 worst case if you tie them together you might end up picking up some digital noise on your analog inputs Feb 08 10:36:13 then again, if you don't worst case is you end up accidently making a nice antenna for picking up random crap on your analog inputs ;) Feb 08 10:37:00 ok Feb 08 10:37:11 no i don't intend to do so Feb 08 10:37:42 it's better be stable, right i'll do the tie thanks Feb 08 10:39:07 i don't intend to do rf listenig i mean, those are only analog inputs for pot and battery in fact Feb 08 10:40:17 right, but unfortunately just because you don't intend to do rf listening doesn't mean you won't pick any up ;) Feb 08 10:40:42 if only EMI were that easy Feb 08 10:42:39 i learnt some type of capacitors are kind of shielded on one end, so that you put the pin on lower impedence or ground, and the capacitor behaves real properly. Feb 08 10:43:30 Was measureing that yesterday and that's real, if the cap is measures on a scope in a way, it's reading 0V, on the other way, it picks up my noise a i serve antenna, about 1v 50 Hz Feb 08 10:43:56 interesting. That's on another topic, old analog scope repairs from the 60's Feb 08 17:20:48 I am working on the beaglebone AI to implement SPI pin outs with a dts overlay file. I am a little confused on where exactly I export the overlay for beaglebone AI I have seen many videos on BBB but they go into a directory that doesn't exist for BB AI. Feb 08 17:20:48 https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/exporting-and-unexporting-an-overlay Feb 08 17:45:07 Guest93: I found this idea online from the forums >>> https://octavosystems.com/app_notes/osd335x-design-tutorial/osd335x-lesson-2-minimal-linux-boot/linux-device-tree/ Feb 08 17:45:28 @zmatt: Okay. Sorry. I thought my exact image could help that person. Feb 08 17:46:01 Guest93: There are two lessons on their site for DT. Feb 08 17:51:39 Guest93 I don't know if bone_capemgr is present in the BBAI... I normally use /boot/uEnv.txt to set the overlays Feb 08 17:52:49  So we can just modify the uEnv.txt file. What if we want to add an overlay? Feb 08 17:57:12 What if we want to write and add a specific overlay? Just out of curiosity? Feb 08 18:32:22 Like where do we add dts files Feb 08 18:32:41 you add the dtb file to the boot/dtbs folder Feb 08 18:32:51 you compile your dts to make a dtb Feb 08 18:33:15 I have tried to communicate between the PRU using scratchpad. I have a beaglebone ai (the am5729 sitara one). I followed https://beagleboard.org/static/prucookbook/#_xout_and_xin_transfering_between_prus Feb 08 18:33:15 Not sure how to proceed, any idea? Feb 08 18:33:16 Here is the link to the code : https://pastebin.com/WxrEFJqx Feb 08 18:33:51 in uEnv.txt: uboot_overlay_addr7=/lib/firmware/overlay.dtbo Feb 08 18:35:25 with enable_uboot_overlays=1, also you should check if any pin is in conflict with cape-universal Feb 08 18:35:57 Thank you Feb 08 18:45:08 note that overlays and cape-universal on the BBAI is a fairly recent development and not in the official released image, I think you'd need a testing image or manually update certain stuff Feb 08 18:45:21 (also, with caoe-universal you don't really need an overlay for spi) Feb 08 18:45:44 8cape Feb 08 18:45:46 *cape Feb 08 18:45:57 caoe-universal? Feb 08 18:46:10 cape-universal Feb 08 18:46:27 the thing that makes runtime pin configuration using config-pin work Feb 08 18:46:55 you can get download the pinmux tool from ti and use it, just you will have to select am5728 Feb 08 18:47:42 you can, but that way sucks since you have to build a custom u-boot Feb 08 18:48:53 that's the official route, but not exactly convenient Feb 08 18:51:10 fair enough, i usually use the one from the survival guide and just make additions to it and it has worked fine for me Feb 08 18:51:29 although, any help with pru will be appreciated right now, i have hit a slump Feb 08 18:53:22 it's not clear to me what you're trying to do Feb 08 18:53:54 I have tried to communicate between the PRU using scratchpad. I have a beaglebone ai (the am5729 sitara one). I followed https://beagleboard.org/static/prucookbook/#_xout_and_xin_transfering_between_prus Feb 08 18:53:55 Not sure how to proceed, any idea? Feb 08 18:53:55 Here is the link to the code : https://pastebin.com/WxrEFJqx Feb 08 18:53:56 here you go Feb 08 18:54:20 yes I looked at that Feb 08 18:54:58 okay so ...i am trying to communicate between the prus, using scratchpad , i try towrite using one of the core, but cant read from the another core Feb 08 18:56:19 but what you pasted contains both send and receive code in the same file, and you're also checking an interrupt bit but it's not clear what you're doing with that or how it's getting signalled Feb 08 18:59:00 okay so what i do is i compile a binary with send commented,  and put it in pru0 , and then i compile with recieve commented in pru1 , so pru1 gets the send part and pru 0 gets  the recieve part Feb 08 18:59:24 as you can see either send or recieve will be commented in the main function Feb 08 19:00:48 okay, that's rather unclear and inconvenient... why aren't you just using two separate files? anyway, core-to-core transfer using xfr 14 requires that one core executes the xin at pretty much the same time as the other core executes the xout... like, if the other side isn't ready the core will wait briefly, but only up to 1024 cpu cycles (after which an error is signalled) Feb 08 19:02:05 pardon me for that. but if you take a look i am using mode 10 Feb 08 19:02:19 ah, sorry Feb 08 19:02:22 i am tyring to write to scratchpad bank 0 and read from it later Feb 08 19:02:44 i can write to the same pru and read it back Feb 08 19:02:52 but cant do it with a different pru core Feb 08 19:04:02 that's weird, the scratchpads should be shared between the cores... as long as you're using the two cores of one pruss (keep in mind the am572x has two independent pru subsystems) Feb 08 19:05:03 about the subsystems , do you mean pru10 and pru01 are a part of a single subsystem and cant access stuff from the pru2x? Feb 08 19:08:10 but the trm shows a scratchpad memory shared between both pru cores Feb 08 19:08:37 pruss1 and pruss2 are completely separate... the options for interaction between them are basically the same as the options for interaction between a pruss instance and the arm: shared memory and/or interrupts Feb 08 19:08:46 yes, between the two cores of one pruss Feb 08 19:09:25 each pruss has two cores Feb 08 19:10:22 but while the am335x has only one pruss (two pru cores total), the am572x has two pruss instances, each having two pru cores (for a total of four pru cores) Feb 08 19:11:52 and each pruss has its own scratchpads, shared between the two cores of that pruss Feb 08 19:12:37 (along with its own local memory, peripherals, interrupt controller, etc) Feb 08 19:13:17 ouch , i get it now why it was not working , much thanks Feb 09 01:11:43 Okay. Feb 09 01:12:15 If I have two channels on my Oscilliscope, how would I test for SPI communication on the BBAI? Feb 09 01:12:34 I can run a loopback test in the form of a clause so far. Feb 09 01:13:14 It reports back what is supposed to be done but blah. Let me just throw in a do-while. Blah. Feb 09 01:17:50 I caught it and w/out burning up the processor! Feb 09 01:42:50 @zmatt or GenTooMan, does this look correct for CS on a loopback test for /dev/spidev1.0 on the BBAI? https://imgur.com/a/19M22Yt Feb 09 01:59:45 set_: you really need more context to determine if CS is correct - prehaps clock on another channel? otherwise, the best guess is you are looking at the end of a transaction Feb 09 01:59:56 CS is active low Feb 09 02:03:13 that is a bit of overshoot/ringing.. are the probes compensated? Feb 09 02:03:26 Hmm. Feb 09 02:03:34 I hope I did this already. Feb 09 02:03:47 Off to compensate again. Blah. Feb 09 02:05:45 I will go and look up a bit of info. first. I need to compensate correctly again and again (right). so, Molloy's software from his book shows some spidev usage in the form of a loopback test. All I did was add GND and CS on Channel 1 of the O-Scope. Feb 09 02:06:14 I changed his software to use it continuously and then paused/stopped the reading so I can analyze it. Feb 09 02:06:38 But...first things first. I will go and compensate again. Feb 09 02:14:16 Do you really need the BBAI for that? Feb 09 02:14:33 Okay. Feb 09 02:14:45 So, I am compensated now. Feb 09 02:14:54 Well, the o-scope is compensated. Feb 09 02:15:09 It was already done and in good standing still. Feb 09 02:15:44 hnv: I do not need the AI for SPI. No. Feb 09 02:16:34 The fellows on the forum or ladies/whomever really, anyway, they need some answers. I just wanted to let them know things are done and figuring things out is partially done too. Feb 09 02:17:19 Yes. The probes are compensated. Feb 09 02:17:33 ds2 lives! Feb 09 02:17:44 Okay, I will try another channel. Feb 09 02:18:20 and ds2. you are right from what I read. CS is active low but the source seems to make me think I can alter its state. Feb 09 02:27:10 Actually, I will have to write the process that maps to -l in the source (I think). Feb 09 02:27:22 hmm? Feb 09 02:27:33 the driver should handle the /CS line Feb 09 02:27:57 I say that b/c the system will not allow me to simply -l the CS line on the command line. Feb 09 02:28:20 Oh. Feb 09 02:28:27 Well, let me try again. Feb 09 02:32:25 You are right. Feb 09 02:32:32 I was trying -l. Feb 09 02:32:48 For loopback. I think this is the normal routine it takes. Feb 09 02:35:10 I performed the delay this time and I will show you the photo. Please hold. Feb 09 02:37:49 Okay. It is the second photo down: https://imgur.com/a/19M22Yt Feb 09 02:38:38 I slowed the process down for the Hz too. Feb 09 02:39:11 So, there is a delay like w/ the driver and then my addition of slowing the Hz down. Feb 09 02:39:21 I will try w/ the regular driver and get back to you. Feb 09 02:43:00 *shrug* that is just a rising edge. not meaningful without context. you really need to qualify it with at least one other line. About the only info from it is - if it toggles wien you run the command, it must be associated with SPI Feb 09 02:43:20 Okay. Feb 09 02:43:25 it really doesn't have enough info to say is it MISO/MOSI/CLK/CS Feb 09 02:43:40 Okay. Feb 09 02:44:39 CS is the line but I will use the second Channel to show off CLK. P9.31 from /dev/spidev1.0 b/c of bone-buses is due! Feb 09 02:44:44 ideally, you would put a 4+ channel logic analyzer or scope on it but 2 at a time and working on the combos should give you enough clues Feb 09 02:44:52 Right. Feb 09 02:45:00 Right. Feb 09 02:45:16 I got a bottom bargain on this thing. It works! Feb 09 02:45:21 Just not w/ four channels. Feb 09 02:45:38 this is not only useful for learning - it is good for checking if SW and HW are in sync and verifying wiring Feb 09 02:46:16 Nice and right...it is an all around useful tool. Feb 09 02:46:33 wouldn't worry about the number of channels - you could do some of this with a DMM if you know what to look for Feb 09 02:46:44 Okay. Feb 09 02:46:57 but a VOM would be easier then a DMM though Feb 09 02:47:05 I can do all combos and then take notes. No issue. Feb 09 02:47:16 YOu say VOM, heh? What is that thing? Feb 09 02:47:30 think analog precursor to the DMM Feb 09 02:47:39 Oh. VoltMeter? Feb 09 02:47:46 it has a moving needle that due to physics - averages the signal Feb 09 02:47:54 Volt-Ohm-Meter Feb 09 02:47:55 Yep. Feb 09 02:47:57 Oh! Feb 09 02:48:36 Hmm. I am not familiar w/ them. So, the dial needle is testament to the average. Feb 09 02:48:57 What would be gained from knowin' the average? Feb 09 02:49:21 well... the 4 signals have different duty cycles Feb 09 02:49:29 Okay. Feb 09 02:49:33 I am w/ you. Feb 09 02:49:42 you're backing out the duty cycle by looking at the average Feb 09 02:49:50 PWM in action :D Feb 09 02:50:48 Right. Oh. So, the average of +/- on the dial shows a specific number and that number is the average? Feb 09 02:51:47 I know on the O-Scope, the above and below signals in PWM are either positive or negative w/ respect to 0.00v. **** ENDING LOGGING AT Wed Feb 09 02:59:56 2022