**** BEGIN LOGGING AT Tue Jun 16 03:06:38 2020 Jun 16 18:43:29 I want to use P9_24 and P9_26 for the soft UART on PRU1 Jun 16 18:43:45 does this link reflect the proper way to disable your HDMI Jun 16 18:43:47 https://www.onlogic.com/company/io-hub/disabling-the-beaglebone-black-hdmi-cape/ Jun 16 18:43:56 its old Jun 16 18:44:10 i know I need to do something in uEnv.txt Jun 16 18:46:15 MattB0ne: if you have an lcd cape it doesn't apply (since hdmi it automatically disabled), otherwise uncomment the line disable_uboot_overlay_video=1 in /boot/uEnv.txt Jun 16 18:46:47 ok Jun 16 18:46:52 also you probably just mean the pruss uart, not a soft-uart Jun 16 18:47:06 correct Jun 16 18:47:09 (a soft uart is an uart implemented in software) Jun 16 18:47:32 why did they make it so only PRU1 can see the uart Jun 16 18:47:40 they didn't Jun 16 18:47:59 but your pru0 is busy with decoding anyway Jun 16 18:48:31 why are you interested in the uart at this point? that seems very premature Jun 16 18:48:57 and what commands do you need to receive there that are so time-critical that you need pru to deal with it instead of handling it in linux userspace? Jun 16 18:49:24 I want PRU1 to read data coming through my load cells. I just want my encoder position and weight reading tightly paired Jun 16 18:49:57 it is important for that relationship to be as accurate as possible Jun 16 18:50:29 I am not there yet but ideally I would want the PRUs synced Jun 16 18:50:30 what's the baudrate of that serial port and how many bytes is the command and the response? Jun 16 18:50:51 "synced" ? I have no idea what you could possibly mean by that in this context Jun 16 18:52:14 when my encoder count is being read I would want the weight at that exact moment Jun 16 18:52:16 or at least, the only interpretation possible doesn't really make sense Jun 16 18:52:32 so I guess syncing the decoder increments with the load cell readings Jun 16 18:52:39 The following Baud-rates can be setup: 9600, 14400, 19200, 38400, 57600, 115200, 230400 and Jun 16 18:52:39 460800Baud for the load cell Jun 16 18:53:20 okay so that's 21.7 microseconds per byte Jun 16 18:53:24 at the highest baudrate Jun 16 18:53:57 I am getting ahead of myself though. Right now I would just would want to read it and update a form Jun 16 18:54:08 the device uses two bytes to report the reading Jun 16 18:54:59 have a datasheet? Jun 16 18:56:06 anyway, with pru0 doing continuous decoding, pru1 can read the current position from memory in 3 pru cycles, i.e. 0.015 microseconds, which is completely negligible compared to the time it takes to poll the load cell Jun 16 18:56:21 https://www.flintec.com/media/downloads/em100-digital-datasheet-en.pdf Jun 16 18:56:26 mine is the G version Jun 16 18:56:55 ok Jun 16 18:57:10 I was going to have PRU do the PWM on the ecap Jun 16 18:57:14 what pwm frequency are you intending to use for the motor? Jun 16 18:57:17 so that will take up some time as well Jun 16 18:57:23 no clue yet Jun 16 18:57:28 should I do that first Jun 16 18:57:34 yes Jun 16 18:57:42 ok Jun 16 18:57:59 you have a full ecap example on your github Jun 16 18:58:01 the pwm frequency is also the obvious maximum rate at which you can update the motor pwm value Jun 16 18:58:04 so I should be able to run with that Jun 16 18:58:08 I do? Jun 16 18:58:12 pastebin you mean? Jun 16 18:58:31 yeah it was probably a pastebin Jun 16 18:58:51 I know I have code for that from you Jun 16 19:02:33 load cell has a maximum update rate of 1200 measurements per second (833.3 us per update) so you're really not in any hurry to get updates Jun 16 19:04:40 (that's with all averaging and filtering disabled) Jun 16 19:07:42 and it uses ascii commands and requires way more than 2 bytes for the response Jun 16 19:10:22 REGISTER compsci5s4j9s edaline.engmann@utexas.edu Jun 16 19:11:14 EdalineE: ehm, you forgot the / so you just pasted your password into chat Jun 16 19:11:28 forgot the /msg nickserv I mean Jun 16 19:11:29 I hate when that happens. Jun 16 19:12:56 MattB0ne: unfortunately the manual doesn't really explain what they mean by "send continuously" (for the auto-transmit commands in section 5.7), but I'm guessing that it'll send the update after each measurement (since it would obviously be pointless to send it more often than that) Jun 16 19:13:24 that's self humiliation. Oh well at least it's correctable. Jun 16 20:12:36 http://bash.org/?244321 Jun 16 20:58:42 huh, a colleague managed to fry a bbb and I have no idea what's going on with it... it manages to power up, supplies seem okay, it draws normal current, bootrom manages to load U-Boot SPL (both from eMMC and from SD), but SPL just hangs/crashes. One time it managed to load U-Boot which got as far as loading /boot/uEnv.txt and then froze Jun 16 21:01:46 something wrong with the ram or its power supply? Jun 16 21:03:19 you could probably cook up a simple ram tester running from sram Jun 16 21:04:19 yeah ram came to mind, but how does one manage to mistreat a bbb in such a way that ram breaks Jun 16 21:04:31 esd? Jun 16 21:04:44 overheating? Jun 16 21:04:51 I guess, but he's normally pretty esd-aware Jun 16 21:04:59 accidents happen Jun 16 21:05:41 that said, I can't remember when I last fried anything with esd Jun 16 21:06:48 yeah usually when a bbb dies it's due to I/O abuse, and the most common result is just a power led blip of doom Jun 16 21:07:50 I once managed to fry a few i/o pins on an imx6 without affecting the rest of the chip Jun 16 21:09:08 I've seen that too, an I/O that was permanently low Jun 16 21:10:33 I've also once seen one where bootrom was unable to access eMMC or SD because the VDD_3V3B was unusually low, and something on the board was starting to produce a crispy aroma (I think the eMMC) Jun 16 21:13:57 with your bbb, I guess the choices are to bin it or else start probing around from spl Jun 16 21:14:01 huh.. I'm puzzled why anyone would want to set NONBASETHRDENA=1 in ARMv7-M, and even more puzzled why ARMv8 made it permanently 1. Jun 16 21:14:26 *ARMv8-M Jun 16 21:15:52 https://developer.arm.com/docs/131328911/10/why-does-the-configuration-and-control-register-ccr-not-have-the-nonbasethrdena-bit-in-armv8-m Jun 16 21:15:57 not much of an answer Jun 16 21:16:40 no that just states that it is so, absolutely nothing about why Jun 16 21:16:50 exactly Jun 16 21:17:28 arm works in mysterious ways Jun 16 21:20:40 ah, it's used for being able to temporarily run in unprivileged mode inside a handler Jun 16 21:21:00 that seems like a pretty obscure use-case Jun 16 21:23:10 maybe a Very Important Customer requested it Jun 16 21:44:27 I find BASEPRI_MAX equally mysterious... I can't think of any situation where it's of any use. I'd want BASEPRI_MIN, to save me a compare and branch, but that doesn't exist Jun 16 21:45:08 (for a critical section that needs to temporarily raise the priority as a form of mutex) Jun 16 22:04:48 ah, it actually does what I want, the documentation is just confusing Jun 16 23:03:38 what happened Jun 16 23:06:21 likely a net split. Jun 16 23:06:37 netsplit or perhaps a reboot of one server Jun 16 23:07:01 I'm amazed IRC is as stable as it is. Jun 16 23:08:51 why? Jun 16 23:09:51 well in the 90's net splits happened a LOT like at times hourly. LOL Jun 16 23:10:39 by 2000 it wasn't too bad. I guess I am use to things going wrong ALL the time? Jun 16 23:10:43 reliable servers and connections are probably easier / more common now than in the 90s Jun 16 23:11:26 you are probably correct in that is likely most of the reason. Jun 17 01:09:56 Hi, anybody used BBAI UARTs? I am able to configure UART10 and UART3 only. For UART5/UART8 only TX works and i am getting gibberish on RX :( Jun 17 01:11:28 I am using minicom to receive data `minicom -b 115200 -o -D /dev/ttyO#` Jun 17 01:31:59 There are a number of 3P capes to support wireless. Digi-Key pushes the Nimbelink capes. Jun 17 02:09:28 jkridner[m]: are you aware that the u-boot currently included on bbai images still uses the original (completely nonsensical) default pinmux rather than the sane pinmux you worked on 7 months ago? Jun 17 02:17:49 lorforlinux: can you pastebin the output of my show-pins script: https://github.com/mvduin/bbb-pin-utils/tree/bbai-experimental#show-pins (note it uses 0-based indexing for everything, but for uarts so does the kernel) Jun 17 02:19:32 Are you guys sticking w/ google groups and keeping all the data or are you guys moving on from all that data? Jun 17 02:19:44 lorforlinux: things to watch out for would be: the uart rxd function being accidently muxed to multiple pins, or if the expansion header pin connects to two cpu pins (which is the case for most of them), make sure there's the other pin is set to safe mode or something harmless like gpio Jun 17 02:22:21 I am unable to set P9.11b what ever i do it's always set to vout1_d17. Jun 17 02:22:41 *installing the show-pins utility Jun 17 02:24:04 tool is showing this Jun 17 02:24:05 Caution: Uses peripheral names from . See README there for details.Died at /usr/local/sbin/show-pins line 152, <> line 60. Jun 17 02:24:32 Is it okay if i share the output of -> perl /opt/scripts/device/bone/show-pins.pl Jun 17 02:27:20 I tried changing the mux mode of P9.11b from overlay and directly from am5729-beaglebonai.dts file, one think i don't understand if it's set to gpio in am5729-beaglebonai.dts why it's showing itself as vout1_d17? Jun 17 02:27:32 I checked using perl /opt/scripts/device/bone/show-pins.pl Jun 17 02:34:03 lorforlinux: you can't paste multiline stuff into chat, use a paste service like pastebin.com Jun 17 02:34:36 that was all, tool is showing two lines only Jun 17 02:34:36 and please use my show-pins script, not the one in /opt Jun 17 02:34:53 oh I see, died Jun 17 02:34:59 hmm lemme check what now Jun 17 02:36:40 lorforlinux: can you pastebin your /proc/interrupts ? Jun 17 02:36:50 yes Jun 17 02:38:16 show-pins breaks every now and then when either some debugfs stuff has changed or it encounters something I simply hadn't seen before ;) I chose to make it parse strictly and throw an error if anything doesn't match the expected format rather than risking silently misparsing stuff Jun 17 02:39:07 https://pastebin.com/1ZLSXhue Jun 17 02:39:52 okay, that's cool Jun 17 02:41:32 what are you looking for, in /proc/interrupts ? Jun 17 02:41:55 whatever is causing it to throw that error Jun 17 02:42:03 ohh okay Jun 17 02:42:09 though I'm not really seeing it, it seems fine Jun 17 02:42:36 I'll reboot and try again. Jun 17 02:42:38 can you change the "or die;" on line 152 of the script to "or die $_;" Jun 17 02:42:43 no! Jun 17 02:43:02 okay doing that Jun 17 02:46:25 what error does it print now? Jun 17 02:46:33 Caution: Uses peripheral names from . See README there for details. 44: 9225 0 CBAR 100 Level at /usr/local/sbin/show-pins line 152, <> line 60. Jun 17 02:47:05 ah, the line number is somehow wrong Jun 17 02:47:29 okay just change it to "or next;", problem solved :P Jun 17 02:47:49 I'll figure out a better fix another time Jun 17 02:49:46 https://pastebin.com/q9nDyFaA Jun 17 02:50:26 okay sure will update the tool later when you fix the issue :) Jun 17 02:50:59 looks like that "vout" is part of the nonsensical default pinmux from u-boot Jun 17 02:51:32 normally that's fixed by a gigantic block of default pinmux in am5729-beaglebonai.dts Jun 17 02:51:53 (which is a disgusting hack and I have no idea why it's still here, I thought it was fixed 7 months ago) Jun 17 02:52:19 I think that's the case other than that i have tried changing it in am5729-beaglebonai.dts and in my overlay also, nothing is working. Jun 17 02:52:36 no doubt the pinmux block isn't being used due to conflicts Jun 17 02:52:46 you'll have errors about that in your kernel log Jun 17 02:54:16 as long as u-boot has this problem, you'll need to override the cape_pins_default node and give all unused pins a sensible default while making sure to omit any pin that's used elsewhere in your DT Jun 17 02:54:21 example: https://pastebin.com/qbEZXd3p Jun 17 02:57:11 why everyone is ignoring P9.13B ? I didn't see it rcn-ee code and it's not in your code too https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual Jun 17 02:57:25 it also means that during early boot, a whole bunch of pins are briefly being configured as outputs until the kernel can fix them Jun 17 02:57:30 so beware of that Jun 17 02:58:27 because P9.13 only connects to one cpu pin in the BBAI schematic Jun 17 02:59:09 so I don't know what its story is Jun 17 02:59:24 but SRM is showing two pins **** ENDING LOGGING AT Wed Jun 17 02:59:57 2020