Closed elgerg closed 1 week ago
We have confirmed that the capabilities mismatch issue occurs when running an older RCP version with a newer host version. Could you please build both the Host and RCP from the same IDF version and try again? You need to flash the RCP firmware to H2 directly.
We are currently working on a solution to safely upgrade the RCP firmware when new capabilities are enabled.
I have this problem also. I believe I'm using the same idf version for each, when I follow either https://docs.espressif.com/projects/esp-thread-br/en/latest/dev-guide/build_and_run.html or https://openthread.io/codelabs/esp-openthread-hardware#1 . When I activate idf, I see I have version 5.4. The fix here for me was to flash the RCP firmware to the H2 chip directly.
What needs to be made clearer also is that each USB-C port on the board connects to a different half of the chipset. That was a doh! idiot! moment for me ;) I couldn't work out how to flash the H2 part with the RCP separate from the BR on S3. LOL.
Thanks for the tip about flashing the H2 chip. That fixed it for me.
How do you flash to the H2 component, if it's USB-C port doesn't have a USB to UART chip, and therefore cannot communicate under normal USB use. Tried with two ”ESP Thread Border Router Boards" and verified they do not provide a USB device descriptor when connected.
Theres two USB-C ports on the board. Pick the other one. Each side is flashed independently. They don't tell you that in the instructions
It's marked that the upper half for H2, and the lower half for S3. The USB-C port is recognized as /dev/ttyACMx
in Ubuntu, you can use this port to flash firmware.
We've added a compatibility error callback in PR #10724, allowing the IDF to handle compatibility mismatch issues starting from commit f41b43d. So now the SDK can trigger RCP update process if compatibility mismatch, manual flashing of H2 is no longer necessary.
Closing the issue, feel free to contact us if any further questions.
Thank you!
Checklist
How often does this bug occurs?
always
Expected behavior
TBR to start and allow me to create a thread network
Actual behavior (suspected bug)
Reboot loop.
The reason I think the docs might be wrong is because here:
2.1.4. Build and Run the Thread Border Router Build and Flash the example to the host SoC.
idf.py -p ${PORT_TO_BR} flash monitor
There is no build step, so I added build before flash (maybe that was my issue?).
The other part that makes me think it might be incomplete is how does the built H2 binary get into the TBR firmware? It seems to be built in a different project then not referenced, I suspect that is what is causing my boot loop as the RCP hasnt had it's firmware updated.
Other things to mention is that the menuconfig stuff seems a little lacking in that you need to specify 12 IPv6 addresses per interface and the default is 8 and if you are using the Ethernet daughter board you must set auto connect on.
I think that there was one other issue but I cant remember what it was.
It would be useful if someone ran through the complete build steps (mine was done on a Raspberry Pi 5 if that matters?).
Thanks in advance!
Error logs or terminal output
Steps to reproduce the behavior
Follow the instructions here: https://docs.espressif.com/projects/esp-thread-br/en/latest/dev-guide/build_and_run.html
Project release version
latest
System architecture
ARM 64-bit (Apple M1/M2, Raspberry Pi 4/5)
Operating system
Linux
Operating system version
Raspberry Pi OS
Shell
Bash
Additional context
No response