I don't think the arduino-esp32 repo supports USB Host mode yet (I can only find Device mode examples). But it appears that IDF library included in arduino-esp32 is ESP-IDF v4.4, so you should have access to the ESP-IDF USB Host Library ( docs here ). The USB Host library is exposed via #include "us...

@Miraculix Could you post a copy of the error log (including the CPU register dump). Those might provide a few clues as to what's happening. Or if you like to have a go at it yourself, the IDF Fatal Errors Guide explains how to read those Guru Meditation Errors.

@karunt Build on ef98a363e35dbc6bfd1caadfab8706874930f278 works fine for me. As for the error "Failed to resolve component 'nghttp'.", please double check that... Both ESP-IDF and ESP-MDF submodules are updated (call "git status" to check for out of date submodules in both repos) Check that the exam...

Some background: Normally, when the ESP32 TWAI peripheral sends a message, it will automatically retry the message transmission until... Another node has acknowledged the message Or until the ESP32 TWAI peripheral enters bus off. Each failed transmission attempt increments the Transmit error counter...

Related viewtopic.php?f=13&t=27879

jr-test wrote: 现在遇到的情况就是向和自己id相同的设备发送数据，但是本身有时能接收到，有时不能接收。想知道这是为什么？有没有大佬能解惑一下

不是很懂问题。如果有节点 A, B, C 然后 A 发起传送，你意思是 B 和 C 接收不了，还是 A 无法接收自己刚发的包？

The RTC Watchdog will indeed it's interrupt line to HIGH when it timesout, however with the RTC WDT driver, you still need to manually route that interrupt line to one of the CPU's 32 interrupts and register and ISR to handle that interrupt. See rtc_isr_register() in "rtc_ctrl.h".

I am convinced that Iv'e set it up wrong as I still get a bunch of ID's that I dont need. That's because its impossible only filter for the exact 4 ID's listed above due to hardware limitations. The mask "11111111101" basically means don't care for all bits except for bit ID[1]. Combined with your ...

A stall on the control endpoint (EP0) generally indicates that a particular request is not supported. Double check the setup packet of the control transfer that triggered the halt on EP0.

Could you enable CONFIG_ESP_SYSTEM_PANIC_GDBSTUB in menuconfig to trigger GDBstub to run on panic, then use GDBstub to check the value of the spinlock's "lock->owner" field. If could be stack overflow (or some memory corruption) that is corrupting the spinlock contents.