Closed LaXiS96 closed 9 months ago
boblane1
commented
9 months ago Hi @LaXiS96,
It is unlikely that no ESP_SPP_CLOSE_EVT event comes when the client closes the serial port. I have tried with tio or cutecom, but neither could reproduce the issue. Could you please simplify your project to reproduce the issue and detail the sending behavior on client side?
Thanks.
LaXiS96
commented
9 months ago I can reproduce it outside my original project, but only on my Linux machine and not on Windows.
Based on code and logs below:
3766 the Linux client connects via Bluetooth and written data starts looping back to DATA_IND events already7226 I open the rfcomm0 serial port in CuteCom15226 I close the connection in CuteComI am noticing that the DATA_IND data contains the entire test message plus an additional ^J (which is the terminal representation of \n), it looks like the Linux client is actively sending back the data?
On Windows I have no such issue, closing the serial port logs this as expected:
W (47635) BT_RFCOMM: port_rfc_closed RFCOMM connection in server:1 state 2 closed: Closed (res: 19)
I (47645) spp: ESP_SPP_CLOSE_EVT
W (47655) BT_RFCOMM: rfc_find_lcid_mcb LCID reused LCID:0x40 current:0x0
W (47655) BT_RFCOMM: RFCOMM_DisconnectInd LCID:0x40@LaXiS96 I reproduce the issue in the following steps:
sudo rfcomm connect /dev/rfcomm0 xx:xx:xx:xx:xx:xx, the connection will be established, and the terminal client will loopback the received dataI think this issue is caused by rfcomm connect command. Try to use sudo rfcomm bind /dev/rfcomm0 xx:xx:xx:xx:xx:xx, open and close the /dev/rfcomm0 in cutecom, then you will receive the ESP_SPP_SRV_OPEN_EVT and ESP_SPP_CLOSE_EVT in ESP32.
LaXiS96
commented
9 months ago Huh, that was exactly it! I was using the blueman GUI to connect to the ESP32, and it looks like it does connect instead of bind.
I'll use the rfcomm CLI from now on; I don't understand why the connect implementation loops back data but I guess that's not a problem anymore.
Thank you for your help @boblane1
Answers checklist.
IDF version.
v5.1.2 release
Espressif SoC revision.
ESP32-D0WDQ6 (revision v1.0)
Operating System used.
Linux
How did you build your project?
VS Code IDE
If you are using Windows, please specify command line type.
None
Development Kit.
ESP32-DevKitC V4
Power Supply used.
USB
What is the expected behavior?
See implementation here (my repo). With the ESP32 accepting Bluetooth SPP connections, a Linux client connects to the RFCOMM serial port, opens it and then closes it without disconnecting from the ESP32. The expected behavior is that
ESP_SPP_DATA_IND_EVTevents should only be received when the connected client has the serial port open and is actually sending data.What is the actual behavior?
What happens instead is that after the serial port is closed,
ESP_SPP_DATA_IND_EVTevents are notified with the same data that is concurrently being written withesp_spp_writefrom another task. See the log below (BTtag):t55540D0E0A0D\rmessages (\rand^Gare ASCII control codes) are written to SPP every 2 seconds (after receiving them from CAN through SLCAN task)39691ms the client closes the serial port, no SPP "close" event is received butESP_SPP_DATA_IND_EVTevents start coming in, with the same data that was just written (see for example at39831ms, the SLCAN command value is the same that was sent above)Steps to reproduce.
/dev/rfcomm0device)tioor CuteCom)S6\randO\r, but a CANbus source is needed)Debug Logs.
More Information.
No response