Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

ROS / Adlink CM2-BT2 (PC104-SBC) SMBus driver incompatibility

This question is getting super specific, but I would appreciate if anybody has seen something like this with other hardware?

Ubuntu 16.04.6 ROS Kinetic full install Adlink CM2-BT2 (PC104 SBC) Adlink's "SEMA" SM-Bus driver to access on-board-GPIO

I am having the problem where Adlink's GPIO example code is working as expected when running on the SBC without ROS. However, if a node is built using Adlink's shared library upon execution, a core-dump/memory trace occurs. This occurs without any manipulation of GPIO state simply attempting to execute a node build with the Adlink shared object.

The suspect test only contains ros::init() and is liked to the Adlink provided .so file as well as library header files. Simply linking in the .so seems to cause the node to fail. If either ros::init() or the .so are absent, the node will execute.

I am currently talking to one of their sales engineers, but I was curious if anybody has seen anything like this with other SBC's onboard GPIO?

Thanks in advance.

ROS / Adlink CM2-BT2 (PC104-SBC) SMBus driver incompatibility

This question is getting super specific, but I would appreciate if anybody has seen something like this with other hardware?

Ubuntu 16.04.6 ROS Kinetic full install Adlink CM2-BT2 (PC104 SBC) Adlink's "SEMA" SM-Bus driver to access on-board-GPIO

I am having the problem where Adlink's GPIO example code is working as expected when running on the SBC without ROS. However, if a node is built using Adlink's shared library upon execution, a core-dump/memory trace occurs. This occurs without any manipulation of GPIO state simply attempting to execute a node build with the Adlink shared object.

The suspect test only contains ros::init() and is liked to the Adlink provided .so file as well as library header files. Simply linking in the .so seems to cause the node to fail. If either ros::init() or the .so are absent, the node will execute.

I am currently talking to one of their sales engineers, but I was curious if anybody has seen anything like this with other SBC's onboard GPIO?

Thanks in advance.

ldd of libsemaeapi.so (as requested):

linux-vdso.so.1 =>  (0x00007ffc2dd82000)
libEApi_1.so.3 => /usr/local/SEMA/lib/libEApi_1.so.3 (0x00007fdba3110000)
libsema.so.3 => /usr/local/SEMA/lib/libsema.so.3 (0x00007fdba2ef3000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fdba2ceb000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fdba2ae7000)
liblog4cpp.so.5 => /usr/local/SEMA/lib/liblog4cpp.so.5 (0x00007fdba285a000)
libsema_hwlinux.so.1.7 => /usr/local/SEMA/lib/libsema_hwlinux.so.1.7 (0x00007fdba2650000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fdba22ce000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fdba1fc5000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fdba1daf000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdba19e5000)
/lib64/ld-linux-x86-64.so.2 (0x00007fdba3cd7000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fdba17c8000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007fdba15af000)

ROS / Adlink CM2-BT2 (PC104-SBC) SMBus driver incompatibility

This question is getting super specific, but I would appreciate if anybody has seen something like this with other hardware?

Ubuntu 16.04.6 ROS Kinetic full install Adlink CM2-BT2 (PC104 SBC) Adlink's "SEMA" SM-Bus driver to access on-board-GPIO

I am having the problem where Adlink's GPIO example code is working as expected when running on the SBC without ROS. However, if a node is built using Adlink's shared library upon execution, a core-dump/memory trace occurs. This occurs without any manipulation of GPIO state simply attempting to execute a node build with the Adlink shared object.

The suspect test only contains ros::init() and is liked to the Adlink provided .so file as well as library header files. Simply linking in the .so seems to cause the node to fail. If either ros::init() or the .so are absent, the node will execute.

I am currently talking to one of their sales engineers, but I was curious if anybody has seen anything like this with other SBC's onboard GPIO?

Thanks in advance.

ldd


Edit: ldd of libsemaeapi.so libsemaeapi.so (as requested):

linux-vdso.so.1 =>  (0x00007ffc2dd82000)
/lib64/ld-linux-x86-64.so.2 (0x00007fdba3cd7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdba19e5000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fdba2ae7000)
libEApi_1.so.3 => /usr/local/SEMA/lib/libEApi_1.so.3 (0x00007fdba3110000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fdba1daf000)
liblog4cpp.so.5 => /usr/local/SEMA/lib/liblog4cpp.so.5 (0x00007fdba285a000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fdba1fc5000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007fdba15af000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fdba17c8000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fdba2ceb000)
libsema.so.3 => /usr/local/SEMA/lib/libsema.so.3 (0x00007fdba2ef3000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fdba2ceb000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fdba2ae7000)
liblog4cpp.so.5 => /usr/local/SEMA/lib/liblog4cpp.so.5 (0x00007fdba285a000)
libsema_hwlinux.so.1.7 => /usr/local/SEMA/lib/libsema_hwlinux.so.1.7 (0x00007fdba2650000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fdba22ce000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fdba1fc5000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fdba1daf000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdba19e5000)
/lib64/ld-linux-x86-64.so.2 (0x00007fdba3cd7000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fdba17c8000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007fdba15af000)
linux-vdso.so.1 =>  (0x00007ffc2dd82000)