Thanks for the traces - I'm trying to get my head around all the stuff in there! :roll: One thing I noticed is that there's a lot of failures looking for certain characteristics - I'm not sure if this is just being blocked because the authentication hasn't occurred, or if the phone was expecting the...

I can confirm the same. I will try to hookup bluetooth sniffer and see what is going on.

That would be awesome!

We've also tested a (new) Nokia and that works OK. Beginning to suspect its a bug on the Huawei..

Also seeing same behavior on Arduino using ESP-WROVER-KIT and:

https://raw.githubusercontent.com/choic ... ng_Key.ino

Works on Samsung, not on Huawei


Bottle of very nice whisky / vodka / rum etc to be posted to anyone with the answer!

We have an IDF 3.3 application that creates a BLE server which is based off a few of the existing demo sources available. We use passkey protection, so ESP32 shows a 6 digit key on LCD screen, mobile user enters that key on phone. Everything works fine when using my Samsung phone, but we've found th...

Thanks all for the info - we will do a manual fuse check first.

We have an application that uses the full secure boot procedure as documented in the manual - this all works great, and we rely on OTA updates after initial flash. Our flashing software calls esptool.py in the background with the following: esptool.py --port {0} -b 460800 --before default_reset --af...

I see this problem even on small packets when at 460800 baud. Using the ROM based uart_rx_one_char() seems reliable at that speed (although misses bytes when sending larger packets due to RTOS etc). 345600 works for smaller packets, but not reliable on YMODEM 230400 seems about the highest I can go ...

I now have my version of the driver working with various I2C devices at 100K, but it took some doing. Still not working at 400K but that could be electrical as I had quite a lot of stuff on the bus. I ended up writing some dedicated getByte / getWord functions to combine the write and receive parts ...

I got my version of the driver working now, and am using it with an I2C OLED no problem. Issue seems to be that when the driver populates the tx FIFO, the FIFO doesn't always catch the data byte, so the value stored in the I2C_CMD_WRITE command is more than the actual values in the TX FIFO, causing ...

If it helps, I've ported the Arduino i2c driver to a IDF FreeRTOS C project, and get similar results. I'm trying to write 2 bytes to a small OLED using i2cWrite(), and only see the address and first byte on the logic analyzer. Looking at the i2c registers, all the status bits look as expected, but t...