Serial port usage, UART4 in BBB

I am trying to interface CC2530 (CC2530ZNP-Pro-Secure_Standard.hex) with Beaglebone Black using resin.io, the idea is launch the Z-STACK-LINUX-GATEWAY

It’s working ok in BBB with debian using UART4 TX/RX/CTS/RTS and GPIO 26

In Debian I enable UART4 adding the next line to uEnv.txt
cape_enable=capemgr.enable_partno=BB-UART4

It’ll be very helpful if someone can help me to enable UART4 in resin.io

Thanks

The zigbeeHAgw conf is
ZBEE_RESET_GPIO_LINE=26
ZBEE_SERIAL_PORT=ttyS4


e2e.ti.com/support/wireless_connectivity/f/158/t/436386
http://www.ti.com/tool/Z-Stack (Z-STACK-LINUX-GATEWAY)
github.com/TI-LPRF-Software/RemoTI-Linux/blob/master/Projects/tools/LinuxHost/configuration/BeagleBoneBlack/RemoTI_RNP_UART4_BBB.cfg

BB-UART4 TX/RX working

echo BB-UART4 > /sys/devices/platform/bone_capemgr/slots

tested with https://github.com/scottellis/serialecho

Now only need to know how to enable BB-UART4 RTS/CTS pin p8.33/p8.35

Thanks

Hello,

We are currently investigating the issue, I will make a reply post as soon as we have an update.

Hello,

I would like to inform you that we are testing some solutions, I will update you as soon as we have a solution ready :smile:

Sounds great, I just ran into the same issue.
Trying to implement an Modbus RTU -datalogger using resin.io, using this cape: http://www.logicsupply.com/cbb-serial/

Would be an ideal target to use resin, as the devices will be behind industrial firewalls and access is otherwise limited :slight_smile:

Hello,

I’ve tested CC2530 and docker in docker with http://archlinuxarm.org/platforms/armv7/ti/beaglebone-black and I need to use only UART4 TX/RX and GPIO26 for reset, isn’t necessary to use UART RTS/CTS

but when I try with resin.io show me a segmentation fault.

Thanks

Hello

Can you provide more info about the code that gives you segmentation fault?
Anything you can share, the dockerfile for example, can be very helpful for identifying the issue.

I’m using the npi server from [1] with the conf of [2] with binaries from [3]

Enable reset gpio and uart4

echo 26 > /sys/class/gpio/export
echo BB-UART4 > /sys/devices/platform/bone_capemgr/slots

Run npi server from [1]

./RemoTI-Linux/Projects/tools/LinuxHost/out/NPI_lnx_armBeagleBone_server ZNP_UART_BBB.cfg debugAll

ZLSZNP from [3], this command show segmentation fault [5]

./servers/ZLSZNP_arm 127.0.0.1:2533 servers/config.ini debugAll

start_netmgr from [3]

./servers/NWKMGR_SRVR_arm 127.0.0.1:2536

gateway from [3]

./servers/GATEWAY_SRVR_arm 127.0.0.1:2536 127.0.0.1:2540

app from [3]

./app/main.bin 127.0.0.1 2540 127.0.0.1 2541 127.0.0.1 2525

CC2530ZNP from [4]

CC2530ZNP-Pro-Secure_Standard.hex

[1] https://github.com/TI-LPRF-Software/RemoTI-Linux
[2] https://gist.github.com/jpizarrom/e636660ed4ae573f7ae5
[3] http://www.ti.com/tool/z-stack Stack_Linux_Gateway_1_0_1_installer.run
[4] http://www.ti.com/tool/z-stack Z-STACK-HOME
[5] https://gist.github.com/jpizarrom/a2bc7574102cf3fdd934

Ok I will try to reproduce the issue and find a fix. I will keep you updated :smile:

Can you let me know what kernel version has the arch linux you used and your app was working?
You can find out by running the command “-uname -r”.

I debugged this a bit, using a working configuration based on Debian Wheezy.

Seems like the issue is in the kernel, at least according to this document. It seems like the kernel doesn’t have RS485 -support enabled, as the exception raised by Python is

[Errno 25] Inappropriate ioctl for device

uname -a from the resin.io -image:

root@beaglebone:/app# uname -a
Linux beaglebone 4.1.4 #1 SMP PREEMPT Mon Sep 7 09:24:21 CEST 2015 armv7l GNU/Linux

The project itself can be found at Github. The code is based on this example and runs fine on the normal Debian-console image for BBB.

I tracked this down a bit further last night, and yes, it seems like the “serial_rs485” -module is missing.

Hello

From our investigation its seems that the issue you are having is closely related to the issue that the rts/cts can’t be used in beagle bone black with resin.
The problem is that pinmux owner is the HDMI even though HDMI is not enabled by default in Resin.
We are working in a fix and that should be available soon, of course I will update this thread as soon as that happens.

With the example project I’m currently running (linked before), the RTS/CTS is handled by the GPIO1_16 to work around the issue with HDMI. So in practice, the method should work, if the kernel module would be present.

Of course the preferable way is to use the real RTS/CTS -signal, this way it should work with every UART4 configuration utilizing flow control.

I will have to further investigate your issue then, once again I will give post as soon as I have an update.
Also thank you for posting your repo, it is very helpful.

I’m using 4.3.0-2-ARCH
Linux 4.3.0-2-ARCH #1 Thu Nov 12 18:55:08 MST 2015 armv7l GNU/Linux

BB-UART4 TX/RX without RTS/CTS is working

echo BB-UART4 > /sys/devices/platform/bone_capemgr/slots

tested with https://github.com/scottellis/serialecho2

root@beaglebone:/app/serialecho# ./serialecho -d /dev/ttyS4

--- ctrl-c to stop ---

Wrote: ABCDEFJHIJKLMNOPQRSTUVWXYZ1234567890abcdefjhijklmnopqrstuvwxyz
Read : ABCDEFJHIJKLMNOPQRSTUVWXYZ1234567890abcdefjhijklmnopqrstuvwxyz

Thanks

You are right, it is the rs485 kernel module. As it seems we support the rs485 kernel module but its not compiled.
I will make the necessary changes and I will let you know as soon its ready.

I have managed to enable RTS-CTS support for the UART4. The fix should be available soon. I will update this thread when it happens.

Sorry for the long delay. I have been working for a fix for rs485 support but I havent be able to find a solution yet.
I have added the kernel module but I still get the same error you had. I will need to further investigate in order to find a solution.