BLE error due to invalid MTU size on esp32c6 #3
Comments
|
I just checked and I'm pretty sure the If you are getting this right after starting the firmware: ... this is not caused by the MTU size and seem to happen randomly. Just restarting the MCU fixes it for me. I think it is a bug in Can you paste here the error you are seeing at the end of the BT provisioning? This is actually not expected. |
|
What I'm getting is this: But you are right, I was too quick in drawing a conclusion. When I restart the device one or two times it works randomly. I just had "luck" when removing the cfg that it worked next time. So I guess the cfg is working properly and 255 is used in both cases, the error is just not deterministic. |
|
Yours is even different than mine, but I still think this is a bug in |
|
But the question is: what is the error you are getting at the end of the provisioning? I would not expect an error there? |
|
Currently trying to reproduce that so I can copy the logs, but I'm hitting different errors each time. I'll write that up shortly |
|
BTW, the c3 works in a much more stable fashion. Also the s3 and even the stock esp32. c6 seems to be the most unstable of all (and is the newest one anyway). |
|
Good point. I might have some S3s laying around somewhere, I'll test those later |
|
I've done some runs now on the C6, here are the results. Unfortunately I didn't encounter the original error again, which was some kind of radio panic. Apparently a very rare one :( - if it happens again, I'll post it here. Ignoring the runs that panic due to BLE HCI parameters in the beginning, which is about one failure in three tries, there are several different cases I encounter when I start commissioning via my Pixel 9 to Home Assistant. After thinking about it for a bit, I presume that the main issue is that my networks are separated, which may just be unsupported by matter? I usually have a I do encounter some weird issues when I try to use the I hoped the matter commissioning would allow me to pick a wifi network which the device should use, but alas it seems to me like I am doing something which is unsupported. There's probably nothing you can do either, I'm just leaving it here for future reference.
|
|
Thank you for your feedback. I think we should push it until it works for you. Digression: First of all, your LAN setup w.r.t. Home Assistant is not unique. I have the exact same setup for my own HA installation:
HA is multi-homed and is present in all 3 VLANs. === Onto your issues:
( With that said, it could be that your phone during commissioning needs Internet (for whatever reasons?). What app do you use on your phone for commissioning to HA?
This must work, but I just tested with esp32c6 and I think this is a problem with the Wifi BLOB + esp32c6 on baremetal (it works for me with all other esps!). I'll try to figure out what is going on with mDNS and esp32c6. |
|
UPDATE: I'm pretty sure now the problem is not simply with multicast traffic on the esp32c6 but with ALL IP traffic on the esp32c6 when BLE is also active. I left the device running after the provisioning failed for me (it got 192.168.10.100 from DHCP) and observe: It is simply not reachable most of the time, on an IP level. @bjoernQ: Once I have a smaller repro case, I'll open a bug at |
@ivmarkov Probably you don't need to create a reproducer - seems like the |
|
You mean, you already reproduced it on the c6 with coex enabled, and now want to test on the c2 as well? |
|
Yes it's easily reproducible on C6 - I would like to know if it's a general issue with newer chips (which use a Nimble based BLE driver - currently we have C2 and C6 here). But anyways you can just create an issue for esp-hal (or I can do it - whatever is more convenient to you) |
|
Ok - I was able to run the example on C2 while pressing down and holding the USB-connector in a special way ... works fine so C6 is the only affected chip. I will create an issue for this and link it here |
|
Here is the issue in esp-hal: esp-rs/esp-hal#3079 |
|
@oddlama I just pushed a power-boosting fix to |
|
@ivmarkov Indeed, thank you very much! It works great when I am in my devices network, in the end I just have to switch back to my home wifi on my phone and wait a bit for the home assistant app to recognize that the connectivity has been restored, then I can add the matter device and complete the setup! When I try with the non-internet connected IoT network, it still fails when generating the device credentials, but I presume this is linked to the esp-wifi issue above? |
No, the
|
Oh sorry, I missed that. I'm using the default app on my device which is the google play services app, it let's me choose whether I want to commission against google home (which I don't have) or another app where I can select HA. But who knows what google is doing there exactly, I'll definitely try another app for commissioning. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi there, thanks for this great project! I noticed that you set the BLE MTU size dynamically based on the crate configuration here
rs-matter-embassy/rs-matter-embassy/src/ble.rs
Lines 37 to 43 in 0c1c4b1
but for esp32c6 this still results in an MTU of 131 which causes the BLE initialization to fail. I'm not entirely sure why the first cfg doesn't trigger for the esp32c6, I did set the feature and target arch just like you described in the example readme. When I remove the conditional and hardcode
255the example boots flawlessly until i run into an unrelated BLE panic later on at the end of commissioning, which I assume is still WIP.The text was updated successfully, but these errors were encountered: