**** BEGIN LOGGING AT Wed Dec 12 03:00:00 2018 Dec 12 10:20:48 Having trouble using the RS485 interface of the CBB-Serial-r02 cape from LogicSupply. So far I succeeded in getting UART4 working with RTS signaling. Problem appears to be that when using RS485 the RTS should have inverse logic. Dec 12 10:21:06 Anyone able to help me getting the RTS-pin inverted? Dec 12 12:55:10 zmatt could you assist in a problem with alsa? i have a mic differentially hooked to MIC1LP and MICLM but i don't know how to configure audio routing in devicetree. Codec works so far, i can play sound without problems. Dec 12 12:55:26 using tlv320aic3104 codec Dec 12 15:14:10 Still working on this RS485 - Will I need to generate a custom kernel with OMAP serial drivers to get RS485 to work? Dec 12 15:27:37 I'm pretty sure both serial drivers support rs485, but I haven't looked at it recently Dec 12 15:28:12 iirc the DT syntax was slightly different for the two Dec 12 15:29:02 (with "both serial drivers" I mean 8250-omap and omap-serial) Dec 12 15:31:20 yeah 8250 definitely supports rs485 (driver enable via rts) Dec 12 15:35:14 zmatt, I've fighting this whole day - I'm not entirely sure how I get this to work right. I've now coupled a logic analyser and an oscilloscope on the board to see whats going on Dec 12 15:35:47 Should I change uEnv.txt? , I've tried quite a few combinations now, but to no avail Dec 12 15:35:48 I'm trying to find where the relevant data is obtained from DT Dec 12 15:37:04 also, "CBB-Serial-r02" ? but the only overlay I see is for -r01 Dec 12 15:37:12 Yes Dec 12 15:37:33 and I see nothing there for rs485 Dec 12 15:38:20 I don't think there is any significant change between r01 and r02 Dec 12 15:38:52 The manual for it references cape-CBB-Serial-r01.dtbo Dec 12 15:39:04 and BB-UART4-RTSCTS-00A0.dtbo Dec 12 15:39:33 have a link to that manual? Dec 12 15:40:13 How can I see which capes are loaded during boot? I've searched /var/log/ with no hits Dec 12 15:40:17 sec... Dec 12 15:40:39 they're loaded by u-boot, so it's only logged to the serial console Dec 12 15:41:09 https://www.logicsupply.com/cbb-serial/ for the board, and down the page you'll find https://docs.google.com/a/logicsupply.com/document/d/1sgurQ-7gLyn7g-Kg983NRM0aDkYEqHqy9dmrieX_RUM/edit Dec 12 15:45:53 I hope you didn't actually download their 5-year-old overlay dtbos (and in the process replaced the newer ones already present in /lib/firmware ) Dec 12 15:46:18 Nope, I'm using the one in the image Dec 12 15:46:23 ok good Dec 12 15:46:46 along with BB-UART4-RS485-00A0.dtbo ? Dec 12 15:46:50 ... and so far, no smoke :o) Dec 12 15:47:01 actually, hmm Dec 12 15:47:17 Don't think I loaded CBB and RS485 together - Tried RS485 with RTSCTS Dec 12 15:47:33 I'm just setting up debug serial port... Dec 12 15:47:41 what do you mean? RS485 and RTSCTS are mutually exclusive Dec 12 15:48:09 Probably why it didn't matter... Dec 12 15:48:13 I'm also wondering if you might be better off disabling the CBB-Serial-r01 overlay Dec 12 15:48:25 but I'm still looking at the overlay sources Dec 12 15:49:59 yeah, cape-CBB-Serial-r01 and BB-UART4-RS485-00A0 have conflicting pinmux Dec 12 15:56:41 zmatt, debug port is 115200 8N1, right? Dec 12 15:56:49 yep Dec 12 15:58:04 assuming the eeprom address selector is set to 00, try setting uboot_overlay_addr0=/lib/firmware/BB-UART4-RS485-00A0.dtbo Dec 12 15:58:16 in /boot/uEnv.txt Dec 12 15:59:10 both switches are in off position, so I assume that means 0 Dec 12 15:59:16 rebooting Dec 12 15:59:32 uboot_overlay_addr0=/lib/firmware/CBB-UART4-RS485-00A0.dtbo Dec 12 15:59:51 BB, not CBB Dec 12 16:00:31 DUH, thats something I tried... Dec 12 16:00:48 the manual for this cape seems pretty decent, it's just outdated Dec 12 16:01:07 but it's quite clear how to do the hardware setup and such, nice images Dec 12 16:01:22 yeah Dec 12 16:01:35 I purchased it a while ago for the same reason Dec 12 16:02:29 Ok booted and ready - How to test? Dec 12 16:02:38 just to be sure: J7 needs to be pin position 2 if you want to DE/RE to be auto-managed Dec 12 16:02:53 *be in position Dec 12 16:03:02 J7 is in UART4-RTS Dec 12 16:03:05 yes Dec 12 16:03:08 that Dec 12 16:03:14 J8 is in RS485 Dec 12 16:04:31 "./linux-serial-test -b 9600 -p /dev/ttyO4 -q 1 -r -c" gives a lot of traffic on RS232!, but nothing on RS485 Dec 12 16:05:25 I'll remount the logic-analyser, sec... Dec 12 16:09:00 zmatt, nope, RTS constant at logic Low Dec 12 16:09:10 UART is transmitting though Dec 12 16:14:49 Just checking the schematic: RS232 will transmit even if J8 is on RS485, so that good. J8 is just used to switch between RS232 RX/CTS and RS485 RX. Dec 12 16:16:00 Knaldgas: can you check your pin configuration using my show-pins utility? Dec 12 16:16:05 https://github.com/mvduin/bbb-pin-utils/#show-pins Dec 12 16:16:21 yep Dec 12 16:16:37 ohhhh wait hold on Dec 12 16:16:49 this cape is using a different pin Dec 12 16:16:52 * Knaldgas is holding on Dec 12 16:18:21 https://pastebin.com/yvbbxBqY Dec 12 16:19:27 UART4 TX on P9.13 and UART4 RTS on P8.33 Dec 12 16:19:57 for some reason the BB-UART4-RS485-00A0 overlay doesn't actually use the RTS pin Dec 12 16:20:03 instead it uses a gpio Dec 12 16:20:22 so, getting rs485 working may require a customized overlay Dec 12 16:20:35 I can help with that, but right now my attention is needed here at wrok Dec 12 16:20:37 *work Dec 12 16:20:51 That's why I made the CBB-UART4-RS485-00A0 version Dec 12 16:20:58 ah Dec 12 16:21:33 what does it source look like? Dec 12 16:21:36 *its Dec 12 16:21:42 https://pastebin.com/kvdphbb2 Dec 12 16:22:12 Just exchanged their GPIO with the P8.33 Dec 12 16:25:08 You need to work, I'll be off for an hour or so then... Dec 12 17:05:01 Knaldgas: whenever i see your nick, I always think you just did a typo... but then remember that l and d are not close together on any sane kbd layout and then I wonder what happend... Dec 12 17:12:55 Stupid dip-switch! Text on top "ON" Text on bottom "1" and "2", of course dips must be "UP" to be off=0 ... Dec 12 17:13:50 Now cape-CBB-Serial-r01.dtbo is actually disabled. Dec 12 17:18:59 <__hj__> Did beagle kernel reach 4.19 release ? Dec 12 17:20:19 __hj__, don't think so, I've got the latest recommended image, which is running 4.14.71 Dec 12 17:31:03 4.19-ti series is work in progress Dec 12 17:31:29 it's available already, but I don't know how far along it is in terms of features compared to 4.14 Dec 12 17:42:11 Knaldgas: I don't know if the current driver supports using rts-gpio, the overlay should configure the rts pin as rts, not as gpio Dec 12 17:53:07 Knaldgas: https://pastebin.com/HxvpMJ8T something like this maybe? Dec 12 18:28:34 zmatt, Hmm, cape-CBB-Serial-r01.dtbo *not* loaded, your CBB-UART4-RS485-00A0.dtbo is loaded: RTS is low most of the time, but shortly before transmitting, it pulses high for 6uS then going back low again Dec 12 18:29:39 it doesn't remain high during the whole transmission? that sounds pretty weird, and would be a kernel bug Dec 12 18:29:40 And that only if I use shell echo to device. If I use linux-serial-test, there is no RTS pulsing. Dec 12 18:29:48 ehhh Dec 12 18:30:18 I don't know what linux-serial-test is, but I'd be concerned about using shell echo Dec 12 18:30:35 it almost certainly closes the device while it's still transmitting, and who knows what effect that has Dec 12 18:30:48 I feel like it *shouldn't* matter, but that doesn't mean it *doesn't* matter ;) Dec 12 18:31:43 beware that rs485 mode is something that can be enabled or disabled in userspace, DT only selects the default Dec 12 18:32:10 programs that simply write to the port presumably won't mess with the setting, but maybe linux-serial-test does? Dec 12 18:32:59 brb Dec 12 18:34:19 zmatt, linux-serial-test does mess with some RS485 settings. Try see these two traces: http://knaldgas.dk/~pdj/RS485/TX_RTS_echo.png http://knaldgas.dk/~pdj/RS485/TX_RTS_echo2.png Dec 12 18:34:27 2. is zoomup of the first Dec 12 18:34:45 Result of running: # stty -F /dev/ttyO4 9600 crtscts; while true; do echo Hej >/dev/ttyO4; sleep 1; done Dec 12 18:35:36 ehh, setting crtscts sounds like a bad idea Dec 12 18:35:49 you almost certainly don't want to mess with that when it's in use by rs485 Dec 12 18:36:28 especially since hardware flow control might override software-control of the rts pin Dec 12 18:36:34 Right Dec 12 18:36:42 I'll reboot and try without Dec 12 18:37:02 (tried with -crtscts, but that didn't change anything) Dec 12 18:37:15 I did have a setup that used RTS the way I wanted, just with inverse polarity. Is it easy to inverse a pin, given that I find that setup again? Dec 12 18:37:39 polarity is configurable Dec 12 18:38:05 or at least it is in the latest kernel, dunno about 4.14 Dec 12 18:38:20 Heh, without crtscts, I get RTS low active during transmission, can we invert it? Dec 12 18:39:03 I'm a bit concerned about the TX to RTS release delay, but that may be configurable. Dec 12 18:39:09 that's weird, it should be active-high by default Dec 12 18:40:05 Maybe you're thinking of RS232 levels, they are opposite of TTL levels Dec 12 18:40:11 no I'm not Dec 12 18:40:14 Hmm Dec 12 18:40:23 https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/serial/rs485.txt#L15 Dec 12 18:40:30 Have to go for an hour :( Dec 12 18:40:41 yeah I'm also semi-away Dec 12 19:51:59 zmatt, It appears that 4.14 does not support this. Will it be enough to install linux-image-4.19.5-ti-r3, or must I upgrade other packages as well? Dec 12 20:03:16 installing the new kernel should suffice Dec 12 20:07:20 Didn't work: "[FAILED] Failed to start Load Kernel Modules.", now trying "/opt/scripts/tools/update_kernel.sh --bone-kernel --lts-4_19" Dec 12 20:07:38 what modules failed to load? Dec 12 20:08:05 [DEPEND] Dependency failed for robotcontrol. Dec 12 20:08:20 I guess that's the one failed (2 lines further down) Dec 12 20:08:36 that's not a failure, that means it didn't even try Dec 12 20:08:55 It's not a module I have requested... Dec 12 20:09:30 can you just pastebin the logs? (journalctl -b-0) you're not really giving remotely enough information so far Dec 12 20:09:39 I tried to insert the rs485-rts-active-low as option, but that didn't change anything Dec 12 20:09:48 on the 4.19 kernel? Dec 12 20:09:51 Of course Dec 12 20:11:09 the property definitely exists in 4.19 Dec 12 20:11:14 Yes Dec 12 20:14:43 wait, what, this code never seems to be called Dec 12 20:15:08 https://pastebin.com/mtrZAgiT for the log, and https://pastebin.com/0CyG1kD2 for the dts Dec 12 20:15:15 Oh? Dec 12 20:16:13 uart_get_rs485_mode(), which parses the OF properties, is defined by the generic serial core code, but only invoked from a few specific drivers, not the 8250 driver, even though it does rely on those properties Dec 12 20:17:16 it may be necessary to just configure it from userspace instead of in DT Dec 12 20:29:23 https://pastebin.com/r1rJFUfr Dec 12 20:30:22 (in which case there's also no reason to use 4.19 instead of 4.14) Dec 12 20:30:30 I see view this as a kernel bug though Dec 12 20:30:45 one that should be easy enough to fix Dec 12 20:32:46 brb Dec 12 20:53:36 Knaldgas: looks like things are going very wrong on that 4.19-bone kernel Dec 12 20:54:14 Oh? Dec 12 20:54:22 I'll go right back to 4.14 then Dec 12 20:54:23 you didn't notice the big traceback? Dec 12 20:55:31 lines 548-578 Dec 12 20:56:12 also, your paste seems to have two copies of the logs? more or less Dec 12 20:56:41 From earlier boot? Dec 12 20:57:03 Or is it cleared at each boot? Dec 12 20:57:26 No, I didn't notice the errors until now... Dec 12 20:58:07 date and time is the same, also "journalctl -b-0" (or I think just "journalctl -b" works too) asks for logs of the current boot only Dec 12 21:02:49 empty offset is like -0 (from man) Dec 12 21:03:37 So, the code from your latest pastebin is usermode, that should get called by the application during opening the device? Dec 12 21:17:03 yes, it's how you can configure a serial port's rs485 mode Dec 12 21:23:45 (untested, apart from checking that it compiles) Dec 12 21:26:39 Among the many things I've tried, this looks a bit like it, but I will certainly give it a new shot. Dec 12 21:27:05 The installation broke after removing the newer kernel images, so new and clean installation on its way... Dec 12 21:27:45 did you forget to make the old kernel the current one before removing the new kernel? Dec 12 21:28:06 maybe last time you tried it you didn't have correct pinmux yet? Dec 12 21:28:12 I thought apt-get remove would take care of that Dec 12 21:28:17 it doesn't Dec 12 21:28:29 It does call initramfs, etc. Dec 12 21:30:42 yes, but the kernel selection mechanism used on the beaglebone is extremely simplistic, it just updates the uname_r variable in /boot/uEnv.txt Dec 12 21:30:52 Ahh... Dec 12 21:32:25 I shoudl still use the CBB-UART4-RS485 dts together with the initialization code, right Dec 12 21:33:09 yes (or you could disable the overlays entirely and use config-pin instead if you prefer) Dec 12 21:33:31 the userspace initialization replaces the rs485-related properties Dec 12 21:33:42 but correct pinmux is of course still needed Dec 12 21:34:41 So, the RS485 dts is needed then Dec 12 21:34:48 That's no problem Dec 12 21:35:38 something that configures all three pins to uart mode Dec 12 21:36:00 mode 6, how about the correct polarity of that RTS? Dec 12 21:36:28 The init-code will take care of that, even with 4.14? Dec 12 21:40:06 yes, that's what the active_low argument in my example function is for Dec 12 21:41:37 Great, thanks zmatt, I will try give it another go tomorrow, thanks for all your help so far! Dec 12 21:41:55 btw, no need to reflash a beaglebone when it fails to boot for such a minor reason, it's pretty easy to recover Dec 12 21:44:07 If you know why :) Dec 12 21:44:35 well even something like reinstalling the intended kernel would have fixed it without knowing the mechanism Dec 12 21:45:20 Ok, so uninstalling the others, then reinstalling the original Dec 12 21:46:08 I think it's worth getting familiar with recovery. reflashing takes a lot of time, especially if it also undoes substantial work you've done Dec 12 21:46:18 or even reinstalling the latest already-installed kernel Dec 12 21:46:36 but yeah, fixing uname_r in /boot/uEnv.txt would have been even easier ;) Dec 12 21:47:10 Yes, it takes a little time. The good thing is that I document all steps as executable command lines, so that I can redo when I have forgotten all :o) Dec 12 21:47:33 So through the debug port, I could have edited uEnv.txt? Dec 12 21:48:14 e.g. in this case you could have figured out what was going on by noticing on the debug port that u-boot was still trying to load the 4.19 kernel, and since it takes its config from /boot/uEnv.txt you'd have found the kernel version being set there Dec 12 21:48:23 no just boot from sd card Dec 12 21:48:29 and mount the eMMC Dec 12 21:48:33 Ahh, then... yes Dec 12 21:49:08 you can even then "enter" the system on eMMC in a container-like environment, e.g. to be able to use apt Dec 12 21:49:12 using systemd-nspawn Dec 12 21:49:18 The SD-card has been setup to reflash on boot - Easy to fix of course Dec 12 21:49:32 yeah you'd need a standalone sd card Dec 12 21:49:57 having a flasher lying around seems dangerous anyway, you really don't want to boot from it by accident :) Dec 12 21:50:21 I would really just wanted to write some userspace ModBus code, but it takes me other places than expected :) Dec 12 21:50:30 No! :D Dec 12 21:50:56 I've heard the name modbus but don't really know anything about it Dec 12 21:51:28 I plan to monitor and control central heating and ventilation system through it Dec 12 21:51:37 Both comes with a ModBus interface Dec 12 21:51:49 RS485 as the media Dec 12 21:52:40 medium Dec 12 21:52:49 gtg, I'll get back to you tomorrow, with another plea of help, or perhaps a victory thanks :) Dec 12 21:53:01 hehe, ok **** ENDING LOGGING AT Thu Dec 13 03:00:01 2018