I have a Linux embedded device using Linux kernel 3.17 and a WiLink 8 wireless module as Bluetooth device (uses UART) (see Gumstix AirStorm-y). Also, I have Qt 5.3.2 and Bluez 4.101 installed on it.
My problem is when I execute my Qt app, I can't get information on my bluetooth device using QBluetoothLocalDevice. For example, QBluetoothLocalDevice::allDevices() always returns an empty list and QBluetoothLocalDevice::address() always returns "00:00:00:00:00:00". If I try to execute the chat example, I get the 'Cannot bind chat server to "00:00:00:00:00:00"' error.
I'm sure my bluetooth device is up and running:
hci0:
Type: BR/EDR Bus: UART
BD Address: 5C:31:3E:CE:C3:CE ACL MTU: 1021:6 SCO MTU: 180:4
UP RUNNING PSCAN
RX bytes:657 acl:0 sco:0 events:37 errors:0
TX bytes:979 acl:0 sco:0 commands:37 errors:0
I can also do scan using hcitools.
Dbus is also running correctly, when I do dbus-send --system --dest=org.bluez --print-reply / org.bluez.Manager.DefaultAdapter I get:
method return sender=:1.5 -> dest=:1.12 reply_serial=2
object path "/org/bluez/1743/hci0"
In my app, everything else seems to work just fine (I a have a QTCPserver and file manager with QFileSystemWatcher), it's only the BLuetooth part I can't manage to make it worked.
Related
Trying to get Intel adapter E810-XXVDA2 to work with VPP (using vfio-pci driver) and cannot figure out the error. When I use the adapter outside of VPP/DPDK, it works just fine (uses ice driver).
Adapter: Intel(R) Ethernet Network Adapter E810-XXVDA2, driver: vfio-pci
VPP: v22.02
Linux: kernel 5.13.0-40-generic, Ubuntu focal 20.04.3 LTS
When interface is specified in /etc/vpp/startup.conf and started with vppctl:
vpp# show hardware-interfaces TwentyFiveGigabitEthernet37/0/0
Name Idx Link Hardware
TwentyFiveGigabitEthernet37/0/0 1 up TwentyFiveGigabitEthernet37/0/0
...
rx bytes ok 2613819
rx missed 18468
Errors:
rte_eth_dev_start[port:0, errno:-5]: Unknown error -5
rte_eth_dev_start[port:0, errno:-5]: Unknown error -5
What does the -5 (EIO) from dpdk mean? Thanks in advance!
EDIT:
I was able to get past this error. Going by the suggestion from #VipinVarghese, I turned on logging (which for VPP users means adding log-level pmd,8 to dpdk section and default-log-level debug in logging section of /etc/vpp/startup.conf).
There I saw that there was a second error which needed me to update ice driver. I was at 1.3.4, I moved it to 1.8.8. After that, both errors got resolved.
The errors were:
2022/05/04 19:58:48:594 error dpdk Interface TwentyFiveGigabitEthernet37/0/0 error -5: Unknown error -5
2022/05/04 19:58:48:594 error interface sw_set_flags_helper: dpdk_interface_admin_up_down: Interface start failed
2022/05/04 19:58:48:595 notice dpdk ice_tx_queue_start(): >>
2022/05/04 19:58:48:595 notice dpdk ice_rx_queue_start(): >>
2022/05/04 19:58:48:595 notice dpdk ice_program_hw_rx_queue(): Port (0) - Rx queue (0) is set with RXDID : 22
2022/05/04 19:58:48:595 notice dpdk ice_program_hw_rx_queue(): currently package doesn't support RXDID (22)
2022/05/04 19:58:48:595 notice dpdk ice_rx_queue_start(): fail to program RX queue 0
2022/05/04 19:58:48:595 notice dpdk ice_dev_start(): fail to start Rx queue 0
RXDID #22 (ICE_RXDID_COMMS_OVS) was not supported until later versions.
DPDK ICE (columibaville E810) PMD can return EIO at 2 different places
HW or device reset - hw->resetting
Traffic Manager configuration - hw->tm_conf
Hence to nail down on the exact problem, always run it with DPDK EAL_INIT option --log-level=pmd,8. This will help to capture more details with respect to PMD. I highly recommend to use the appropriate driver and firmware version against the DPDK version as mentioned in section 25.3.
[Update] updating the linux driver (which in turn houses the DDP and firmware) has solved the issue for #schugcove.
I'm using STM32Cube IDE which is based on Eclipse. Nothing fancy in my code just initializes an on board LED and turns it on in infinite loop. It built and debugged successfully the first time(the LED did turn on) but the second time it could build but cannot debug.
Here's the error I got.
>Open On-Chip Debugger 0.10.0+dev-00021-g524e8c8 (2019-06-12-13:13)
>Licensed under GNU GPL v2
>For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
none separate
>Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
>adapter speed: 8000 kHz
>adapter_nsrst_delay: 100
>Info : Listening on port 6666 for tcl connections
>Info : Listening on port 4444 for telnet connections
>Info : clock speed 8000 kHz
>Info : STLINK v2 JTAG v25 API v2 SWIM v0 VID 0x0483 PID 0x3748
>Info : using stlink api v2
>Info : Target voltage: 2.891943
>Error: init mode failed (unable to connect to the target)
>in procedure 'init'
>in procedure 'ocd_bouncer'
When I try st-info --probe (on linux) I got:
Found 1 stlink programmers
serial: 390069063058303044662143
openocd: "\x39\x00\x69\x06\x30\x58\x30\x30\x44\x66\x21\x43"
flash: 0 (pagesize: 0)
sram: 0
chipid: 0x0000
descr: unknown device
But before upload I got relevant data eg:
flash: 131072 (pagesize: 1024)
sram: 20480
chipid: 0x0410
descr: F1 Medium-density device
No way of uploading code into microcontroller any way again. When I try new board it works just for that one upload - after that board is killed and works no more :( First upload of program works even after restart (LED is still blinking), but does not report to the ST-LINK v2.
I tried reset to default settings but it didn't help either. Has anyone ran into similar problems?
Found solution on Stackexchange.
When you forget to configure your debug port in STM32CubeIDE and upload your code, ST-Link will stop working, because its waiting for debugger to attach, but its not defined.
You have to assign SYS debug port in IDE (Configuration file -> SYS -> Mode -> Serial Wire):
Setup image
You can make your STM32 work again by removing whole flash by ST-Link Utility (I tried that in linux but does not work because it does not support connect under reset). In ST-Link Utility go to Settings -> Mode -> Connect under reset. Then connect mcu with ST-Link and hold reset. After that click "connect to the target" in ST-link utility and you are ready to erase it.
Possibly a rogue breakpoint is causing GDB to mis-behave. Possible workarounds to get going again:
If you last built a debug build, try building a release build and load the code. Then delete/erase all breakpoints and reload your debug version
Without launching a debug session, from the Eclipse main menu select Run->Remove All Breakpoints
If you have a copy of ST-Link Utility installed, launch and erase your chip
Trying to debug my sample blink_led code on STM32L476 Nucleo-64 board but gdb can't connect to OpenOCD (connection drops almost instantly with error). I've read plenty of posts here and there but none of them helped. Tried adding commands to OpenOCD using -c but no change of behavior.
My code compiles both in Release and Debug config in Eclipse. I can flash the bin file using drag and drop (while the board has built-in STLink add-on) and looks the code runs perfectly on the board (LED blinks).
Cross compiling on Centos7 using the following versions:
Toolchain (gdb): gcc-arm-none-eabi-8-2018-q4-major
OpenOCD: 0.10.0-11-20190118-1134
As using eclipse didn't work I tried the command line,
(I'm not an experienced developer in this environment so I could not find any config file closer to my stm32l476 board than the stm32l4discovery.cfg, please let me know if there might be some issues using it)
./bin/openocd -f scripts/board/stm32l4discovery.cfg -c "init"
It starts,
GNU MCU Eclipse 64-bit Open On-Chip Debugger 0.10.0+dev-00462-gdd1d90111 (2019-01-18-11:37)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 500 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : clock speed 500 kHz
Info : STLINK V2J28M17 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.244386
Info : stm32l4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Then starting GDB:
./arm-none-eabi-gdb ~/eclipse-workspace/test-blink-led/Debug/test-blink-led.elf
then running the following command in gdb:
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
Remote connection closed
As it shows gdb connection drops instantly and OpenOCD prompts the following errors:
Info : accepting 'gdb' connection on tcp/3333
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080022e6 msp: 0x20017ff8
Info : device id = 0x10076415
Warn : STM32 flash size failed, probe inaccurate - assuming 1024k flash
Info : flash size = 1024kbytes
Error: auto_probe failed
Error: Connect failed. Consider setting up a gdb-attach event for the target to prepare target for GDB connect, or use 'gdb_memory_map disable'.
Error: attempted 'gdb' connection rejected
Error: jtag status contains invalid mode value - communication failure
Polling target stm32l4x.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 100ms
So from those geeks who do it on a similar platform on a daily basis, can anyone help and tell me where am I doing wrong. Does missing any compile-time flag might result in this problem?
I'm scratching my head for a couple of days now so please let me have your hints.
One of the reasons may be that your STLINK firmware seems pretty old (STLINK V2J28M17 as your log shows). I suggest downloading the STSW-LINK007 application to upgrade the firmware. The software is a multiplatform Java application. It works flawlessly in Debian GNU/Linux.
Currently, I use another gdb server texane/stlink for my debugging task with GDB without any problem on some Nucleo and also custom boards. I use target extended-remote command to join the port of the server. Maybe you can try to connect with this command also under OpenOCD.
Try
telnet localhost 4444
it worked for me, while 3333 didn't
When I use dpdk-devbind.py to bind a port of Network port of X710. I get error:
Error: bind failed for 0000:20.00.0 - Cannot bind to driver uio_pci_generic.
Error: unbind failed for 0000:20:00.0 - Cannot open /sys/bus/pci/drivers//unbind
The command was run by root user. Linux version is: 3.10.0-693.21.1.el7.x86_64. It is run in CentOS 7.3.
Same haredware, same command run in CentOS 7 (Linux: 3.10.0-123.el7.x86_64), the bind work well.
In addition, CentOS 7.3 with Intel X520 work well with dpdk.
Something else: before bind command from dpdp, in CentOS 7, ifconfig cannot view i40e port. but in CentOS 7.3, it can see the ports.
Looks like Linux Kernel problem, but when I upgrade kernel to 4.16 (mainline) or 4.4 (longterm), I get ERST: cannot request mem error. Anything else I can try?
you should bind with igb_uio , generic is not supported for this type of intel controller.
I want to link a Bluetooth barcode scanner (Gryphon GBT4400) in "client" mode to a Bluetooth-enabled PC with the serial port profile.
The Bluetooth PC adapter is Atheros Communications AR3012.
PC is running under Ubuntu Server 16.04.
I first run the following commands through bash script:
sdptool add --channel=22 SP > /dev/null
rfcomm watch /dev/rfcomm0 22 1>/dev/null 2>&1 &
Then with scanner I scan the barcode to link the scanner to the PC in Bluetooth (this barcode includes the MAC address of the Bluetooth interface of the PC).
It works well: PC and scanner are now connected.
Then I open the serial port through a QT/C++ application running on PC, built with QT 5.5.1, with following code:
pSerialPort = new QSerialPort("/dev/rfcomm0");
pSerialPort->open(QIODevice::ReadOnly);
At this step, this warning message is immediately displayed on PC:
Bluetooth: TIOCGSERIAL is not supported
Except this warning, everything works very well: the QT application retrieves correctly all the scanned barcode values.
I found almost nothing on the web.
Can someone help me to understand this warning message ?
You could remove all warning and error messages with:
qt_app 2>/dev/null
but that would hide other warnings that you might want to see. To hide just this one without having to change any source code and recompile, you can do:
qt_app 2>&1 | grep -v TIOCGSERIAL