Role switch fails with ESP32 & Wiimote

[Nick P]

Hi all,

I'm new to the mailgroup. I searched the history, but couldn't find a solution to my problem.

I'm trying to use a Wiimote (HID device) in combination with an ESP32 and BTstack.

I succeed in discovering the Wiimote with the ESP32, connecting to it, pair and get HID reports.

When turning off the Wiimote, that also gets reported in the ESP32.

When turning the Wiimote back on, it will send a connection request to the ESP32. The ESP32 accepts and asks for a role switch to become master. That fails however. The connection is made, but the role switch fails. After that the Wiimote turns itself back off.

The procedure works fine when done on a MacBook (with the standard OS functions to discover and connect Bluetooth devices). Wiimote requests a connection, the mac accepts with a request to switch roles and gets the master role.

The same seems to happen when I use a Dell mouse instead of the Wiimote.

I have searched many places, but couldn't find a solution. I also have no clue how to debug further. Can you give advice on what to look for?

Here is a piece of the ESP32 debug log:

[00:00:44.296] EVT <= 04 0A 9C 28 91 1D 19 00 04 25 00 01  --> incoming connection request

[00:00:44.296] LOG -- hci.c.2093: Connection_incoming: 00:19:1D:91:28:9C, type 1

[00:00:44.297] LOG -- hci.c.187: create_connection_for_addr 00:19:1D:91:28:9C, type ff

[00:00:44.305] LOG -- hci.c.3510: sending hci_accept_connection_request, remote eSCO 0

[00:00:44.313] CMD => 09 04 07 9C 28 91 1D 19 00 00  --> MacBook sends same reply AND reports later that it became master.

Connection request from: 00:19:1D:91:28:9C

[00:00:44.321] EVT <= 0F 04 00 05 09 04

** Unhandled HCI event: 0x0f : 0F 04 00 05 09 04

[00:00:44.329] LOG -- btstack_run_loop_freertos.c.214: RL: portMAX_DELAY 4294967295

[00:00:44.337] LOG -- btstack_run_loop_freertos.c.230: RL: wait with timeout 4294967295

[00:00:44.344] EVT <= 6E 00

** Unhandled HCI event: 0x6e : 6E 00

[00:00:44.350] LOG -- btstack_run_loop_freertos.c.214: RL: portMAX_DELAY 4294967295

[00:00:44.358] LOG -- btstack_run_loop_freertos.c.230: RL: wait with timeout 4294967295

[00:00:44.590] EVT <= 12 08 35 9C 28 91 1D 19 00 01  --> ESP reports the role switch failed and it stays slave.

role change 12 08 35 9C 28 91 1D 19 00 01

-- status: 0x35, role: 0x1

[00:00:44.591] LOG -- btstack_run_loop_freertos.c.214: RL: portMAX_DELAY 4294967295

[00:00:44.597] LOG -- btstack_run_loop_freertos.c.230: RL: wait with timeout 4294967295

[00:00:44.630] EVT <= 03 0B 00 80 00 9C 28 91 1D 19 00 01 00  --> connection OK

[00:00:44.630] LOG -- hci.c.2117: Connection_complete (status=0) 00:19:1D:91:28:9C

[00:00:44.632] LOG -- hci.c.2130: New connection: handle 128, 00:19:1D:91:28:9C

[00:00:44.639] LOG -- hci.c.4204: BTSTACK_EVENT_NR_CONNECTIONS_CHANGED 1

[00:00:44.645] EVT <= 61 01 01

** Unhandled HCI event: 0x61 : 61 01 01

HCI: Connected: 00:19:1D:91:28:9C

discovered device connecting back

can send: asking role switch

[00:00:44.660] CMD => 0B 08 07 9C 28 91 1D 19 00 00 --> Second attempt to ask for a role switch, but no effect

[00:00:44.665] EVT <= 0F 04 0C 05 0B 08

** Unhandled HCI event: 0x0f : 0F 04 0C 05 0B 08

[00:00:44.673] LOG -- btstack_run_loop_freertos.c.214: RL: portMAX_DELAY 4294967295

[00:00:44.680] LOG -- btstack_run_loop_freertos.c.218: RL: now 44680, expires 54633

[00:00:44.688] LOG -- btstack_run_loop_freertos.c.230: RL: wait with timeout 9953

[00:00:44.695] EVT <= 6E 00

** Unhandled HCI event: 0x6e : 6E 00

[00:00:44.701] CMD => 1B 04 02 80 00

[00:00:44.705] EVT <= 0F 04 00 05 1B 04

** Unhandled HCI event: 0x0f : 0F 04 00 05 1B 04

[00:00:44.712] EVT <= 0B 0B 00 80 00 BC 02 04 38 08 00 00 00

[00:00:44.718] LOG -- hci.c.2183: HCI_EVENT_READ_REMOTE_SUPPORTED_FEATURES_COMPLETE, bonding flags 2, eSCO 0

read remote supported features done

[00:00:44.731] LOG -- btstack_run_loop_freertos.c.214: RL: portMAX_DELAY 4294967295

[00:00:44.738] LOG -- btstack_run_loop_freertos.c.218: RL: now 44738, expires 54633

[00:00:44.745] LOG -- btstack_run_loop_freertos.c.230: RL: wait with timeout 9895

[00:00:44.753] EVT <= 6E 00

** Unhandled HCI event: 0x6e : 6E 00

[00:00:44.759] LOG -- btstack_run_loop_freertos.c.214: RL: portMAX_DELAY 4294967295

[00:00:44.766] LOG -- btstack_run_loop_freertos.c.218: RL: now 44766, expires 54633

[00:00:44.773] LOG -- btstack_run_loop_freertos.c.230: RL: wait with timeout 9867

[00:00:46.763] EVT <= 05 04 00 80 00 16

** Unhandled HCI event: 0x05 : 05 04 00 80 00 16

[00:00:46.763] LOG -- hci.c.929: Connection closed: handle 0x80, 00:19:1D:91:28:9C

[00:00:46.767] LOG -- hci.c.4204: BTSTACK_EVENT_NR_CONNECTIONS_CHANGED 0

[00:00:46.774] EVT <= 61 01 00

** Unhandled HCI event: 0x61 : 61 01 00

[00:00:46.780] LOG -- btstack_run_loop_freertos.c.214: RL: portMAX_DELAY 4294967295

[00:00:46.787] LOG -- btstack_run_loop_freertos.c.230: RL: wait with timeout 4294967295

Kr,

Nick

[Matthias Ringwald]

Hi Nick

Looks like you're doing everything correct. For further analysis, please disable LOG_DEBUG, it's really only helpful for internal bugs.
Then, please post-process the console output with btstack/tool/create_packet_log.py to avoid manually looking up HCI Commands and Events. Instead open the file in Wireshark.

From the log snippet, if this works on the Mac but not on the ESP32, it would mean that the ESP32 Bluetooth Controller isn't actually asking for a role switch during accept connection.

After sending the role switch request, you get a command status with status = COMMAND DISALLOWED (0x0C)
Not sure what this means, or why it would not be allowed at this time.

Anyway, could you make a new log of this, and then, could you try your code on another platform, e.g. libusb (mac/linux) or windows-winusb with an USB Bluetooth Dongle for comparison and post both for comparison? If it works with a USB Bluetooth Dongle but not on the ESP32, you could file an issue at the esp-idf github repo, reporting that role change during accept connection doesn't work although it works on others.

Cheers
Matthias

> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to btstack-dev...@googlegroups.com.
> To post to this group, send email to btsta...@googlegroups.com.
> Visit this group at https://groups.google.com/group/btstack-dev.
> To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/19b7a21d-dfb4-4510-92f5-7d5d4a11ed03%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Jackson Snowden]

I came here looking for help with the exact same issue. I wanted to point out that this only happens with the older Wiimotes which use the Broadcom hardware. Newer Wiimotes with CSR chips complete the role switch and will connect correctly. This seems like hardware-specific issue between the ESP32 and old Broadcom hardware.

[Nick P]

Hi,

Thanks for the replies. I finally found some time to work on this again..

I managed to port the code to linux. Initially, the connecting back also didn't work, but in the end I (with the insights from wireshark) managed to get it working on linux by adapting my code.

Going back with the same code to ESP32 however still fails. The issue still looks the same: the role switch fails when accepting the connection from the wiimote, although esp asks to become master.

I attach here the 2 packet logs for comparison. I use following filter in wireshark to see them cleaned up: bthci_cmd or bthci_evt or btl2cap

Look at following packet numbers:

esp1   linux

12   640 --> incoming event about connection request (happens when turning the wiimote back on)

13   644 --> send command to accept connection, looks identical to me, both ask to become master

19   650 --> incoming event about role change: esp32 reports failed, linux reports success

22   653 --> both report the connection is setup

After that there is some communication on both about supported features (I'm not sure where this is initiated, doesn't matter I think).

Then the esp reports the connection is closed (packet 34) and on linux (packet 669) I see the wiimote requesting for hid control channel (L2CAP).

On linux, then also the request for the hid interrupt is made and in the end I see packets coming in for the button presses. So that all looks fine and is what I'm after.

Any further ideas to troubleshoot? I'm not bluetooth specialist (learned a lot from this attempt..), but it indeed looks like the esp32 is not compatible with wiimote unless I'm missing something, somewhere in the initialisation.

I did have to add this one 'hci_set_master_slave_policy(0);' before 'hci_power_control(HCI_POWER_ON);' so that the master role is explicitly requested during the connection accept (not requesting it also doesn't work on both, so it seems the wiimote expects the other side to request it).

byebye,

Nick

[Matthias Ringwald]

Hi Nick

Thanks for the details tests. Comparing both logs, it indicates a bug in the ESP32 Link Layer implementation. Did you browse their issue tracker (https://github.com/espressif/esp-idf/issues)? A quick search for 'role change' did not give me an open issues.

You've mentioned before that it only happens with older, Broadcom-based WiiMote, but not with a new CSR-based one. Is that correct? Could you double-check the CSR as you've used to HCI packet logs now?

After checking the older CSR-based version, I would suggest to post an issue on the ESP32 issue tracker, incl. full .pklg files

Cheers
Matthias

> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to btstack-dev...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/b846a2c7-594b-4989-a8f9-7aa94c5455d7%40googlegroups.com.
> <esp1.pklg><linuxdongle-ok.pklg>

[Nick Passchyn]

Hello,

Unfortunately I don't have a wiimote with CSR chip to compare, that was someone else who replied with that. I don't know if he is still following to show his logs.

I found another HID device laying around which seems to have a CSR chip. I will try with that.

Question remains where the issue is, in the esp32 or the wiimote (=its bluetooth chip). I got it working with a wiimote and a dongle on linux that has a very similar bluetooth chip as the wiimote (BCM-2042 and BCM-2045) (yup both pretty old.. but working, hence the reason I wanted to reuse it..). So maybe they suffer the same flaw, but working/compatible because of the same brand.

I also didn't find similar issues on the github esp-idf issue list. I will try with the CSR based device and after that report on the esp-idf list if I can find further suitable results to report.

Thanks for the help.

byebye,

Nick

You received this message because you are subscribed to a topic in the Google Groups "btstack-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/btstack-dev/eWqUROqFBV0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to btstack-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/D1CF4593-5901-42FB-9EA0-B020F33B0EEA%40gmail.com.

[Matthias Ringwald]

Hi Nick

I didn't follow closely, so I didn't realize who has which WiiMote...

What I'm interested is if ESP32 always fails to become master or only with some devices. If it always fails, that would be easier to reproduce, report, and potentially fix. If not, air traces would probably necessary, but require not-so-cheap Bluetooth sniffers. You can also use e.g. the spp-streamer + spp-streamer-client of BTstack with different dongles / ESP32 for comparison.

Best
Matthias

> To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/CANEu6eT1_s4Ox65fw9bx0Y%3D0cxvU%2BTjVpehLx_V0e1OTKfUqjg%40mail.gmail.com.

[Nick Passchyn]

Hello again,

Some update: I tested with 3 more devices:

- (Old) Dell mouse (also Broadcom chip, not sure which one): same issue

- Apple mouse (3-4 years old, reports Apple chip..): same issue

- Cheap Aliexpress device (reports name as VRtech, reports to have a csr chip): it works! (maybe it is less picky on the standard?)

LOGS:

Keep using 'bthci_cmd or bthci_evt or btl2cap' as filter for the logs. The other messages dumped in between are not all correct anymore. (Too much trial & error in my code due to all the attempts to get this to work.. huge clean-up to do now that it works with at least 1 device..)

Wiimote: see previous messages

Dell log:

620 Incoming connection

627 failed role switch

Apple mouse log:

514 Incoming connection

521 failed role switch

VRtech log:

1 Incoming connection

8 role switch ok

Summary:

All can be discovered, connected to and HID reports are received. When they are turned off, all of the devices I tested connect back, but fail on the role switch except the VRtech. (And as Jackson reported, the latest wiimotes with CSR chip also seem to work, but I lack that one to test that here.)

Kr,

Nick

To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/AF7F0229-5FA7-465E-A063-F08C3B69E552%40gmail.com.

[Ricardo Quesada]

Nick,

Just in case it helps, I have an ESP32 + wiimote working. Code here:

https://gitlab.com/ricardoquesada/unijoysticle2/tree/master/firmware

> > To unsubscribe from this group and stop receiving emails from it, send an email to btsta...@googlegroups.com.

> > To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/b846a2c7-594b-4989-a8f9-7aa94c5455d7%40googlegroups.com.
> > <esp1.pklg><linuxdongle-ok.pklg>
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "btstack-dev" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/btstack-dev/eWqUROqFBV0/unsubscribe.

> To unsubscribe from this group and all its topics, send an email to btsta...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/D1CF4593-5901-42FB-9EA0-B020F33B0EEA%40gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to btsta...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/CANEu6eT1_s4Ox65fw9bx0Y%3D0cxvU%2BTjVpehLx_V0e1OTKfUqjg%40mail.gmail.com.

--
You received this message because you are subscribed to a topic in the Google Groups "btstack-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/btstack-dev/eWqUROqFBV0/unsubscribe.

To unsubscribe from this group and all its topics, send an email to btsta...@googlegroups.com.

[Nick Passchyn]

Hello Ricardo,

Thanks for the code. I installed your latest binary, but it seems to suffer from the same issue: it can discover and connect to the wiimote, but when you power cycle the remote, the reconnect also fails. This is wat I get from the ESP monitor for your binary "Unijoysticle 2 - firmware v0.4":

--> GAP_EVENT_INQUIRY_COMPLETE
--> Scanning for new devices...
--> GAP_EVENT_INQUIRY_COMPLETE
--> Scanning for new devices...
L2CAP_EVENT_CHANNEL_CLOSED: 0x0042 (channel=0x0042)
device 00:19:1D:91:28:9C has new joystick port: 0
Invalid hid_interrupt_cid: 0
L2CAP_EVENT_CHANNEL_CLOSED: 0x0043 (channel=0x0043)
Couldn't not find hid_device for cid = 0x0043
--> HCI_EVENT_DISCONNECTION_COMPLETE
--> GAP_EVENT_INQUIRY_COMPLETE
--> Scanning for new devices...
--> GAP_EVENT_INQUIRY_COMPLETE
--> Scanning for new devices...
--> GAP_EVENT_INQUIRY_COMPLETE
--> Scanning for new devices...
--> GAP_EVENT_INQUIRY_COMPLETE
--> Scanning for new devices...
--> HCI_EVENT_CONNECTION_REQUEST: link_type = 1 <--
on_hci_connection_request from: address = 00:19:1D:91:28:9C, cod=0x2504
--> HCI_EVENT_ROLE_CHANGE
--> HCI_EVENT_CONNECTION_COMPLETE
--> HCI_EVENT_DISCONNECTION_COMPLETE
--> GAP_EVENT_INQUIRY_COMPLETE
--> Scanning for new devices...
--> HCI_EVENT_CONNECTION_REQUEST: link_type = 1 <--
on_hci_connection_request from: address = 00:19:1D:91:28:9C, cod=0x2504
--> HCI_EVENT_ROLE_CHANGE
--> HCI_EVENT_CONNECTION_COMPLETE
--> HCI_EVENT_DISCONNECTION_COMPLETE
--> GAP_EVENT_INQUIRY_COMPLETE
--> Scanning for new devices...
--> HCI_EVENT_CONNECTION_REQUEST: link_type = 1 <--
on_hci_connection_request from: address = 00:19:1D:91:28:9C, cod=0x2504
--> HCI_EVENT_ROLE_CHANGE
--> HCI_EVENT_CONNECTION_COMPLETE
--> HCI_EVENT_DISCONNECTION_COMPLETE
--> GAP_EVENT_INQUIRY_COMPLETE
--> Scanning for new devices...
--> GAP_EVENT_INQUIRY_COMPLETE

Kr,

Nick

To unsubscribe from this group and all its topics, send an email to btstack-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/806b6e3b-2083-401c-8d95-1bb2a0717331%40googlegroups.com.

[Ricardo Quesada]

mmm.... thanks. Probably I should double check what's wrong the
Nintendo reconnection as well.

> To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/CANEu6eSsrcDV7LVPSqD5iiUD%3DTMGCk2EXfaXvNfBEvDF41LjVQ%40mail.gmail.com.

[Matthias Ringwald]

Hi Nick

In your logs, BTstack always sends the same (correct) commands, but the Role Switch fails. From the sample data, it's not clear which side is at fault.
Nevertheless, I'd suggest you file an issue on the ESP-IDF GitHub project and also attach the log files below. It would be great if one of their engineers could reproduce this, as they could then check whats going on.

Which Apple Mouse did you use?

Cheers
Matthias

> To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/CANEu6eRitt-rwW2x-SEW7%2B%3DcF-jErcpbo3m_aMdbKyA8JV%3DDCA%40mail.gmail.com.
> <dellmouse-nok.pklg><applemouse2-nok.pklg><vr-ok2.pklg>

[Nick P]

Hello Matthias,

I launched the topic at Espressif: https://github.com/espressif/esp-idf/issues/4337

The used Apple mouse is one that came with a macbook pro some years ago. It has model no: A1296 3 Vdc on the bottom.

Thanks again for your help. I hope Espressif can clarify further.

byebye,

Nick

> > > To unsubscribe from this group and stop receiving emails from it, send an email to btsta...@googlegroups.com.

> > > To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/b846a2c7-594b-4989-a8f9-7aa94c5455d7%40googlegroups.com.
> > > <esp1.pklg><linuxdongle-ok.pklg>
> >
> > --
> > You received this message because you are subscribed to a topic in the Google Groups "btstack-dev" group.
> > To unsubscribe from this topic, visit https://groups.google.com/d/topic/btstack-dev/eWqUROqFBV0/unsubscribe.

> > To unsubscribe from this group and all its topics, send an email to btsta...@googlegroups.com.

> > To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/D1CF4593-5901-42FB-9EA0-B020F33B0EEA%40gmail.com.
> >
> > --
> > You received this message because you are subscribed to the Google Groups "btstack-dev" group.

> > To unsubscribe from this group and stop receiving emails from it, send an email to btsta...@googlegroups.com.

> > To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/CANEu6eT1_s4Ox65fw9bx0Y%3D0cxvU%2BTjVpehLx_V0e1OTKfUqjg%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "btstack-dev" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/btstack-dev/eWqUROqFBV0/unsubscribe.

> To unsubscribe from this group and all its topics, send an email to btsta...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/AF7F0229-5FA7-465E-A063-F08C3B69E552%40gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to btsta...@googlegroups.com.