You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have used the latest released firmware or have updated my ESP-AT branch (master or release) to the latest version and checked that the issue is present there.
I have searched the issue tracker for a similar issue and not found a similar issue.
AT+GMR
Due to the fact that the NimBLE config for persistent storage of the bonding information is not active in the release v4.0.0.0, we had to generate a custom build based of master branch, where this setting is active. It is strange that the persistent storage of bonding data is not active by default in the release version...
ESP-ROM:esp32c6-20220919
Build:Sep 19 2022
rst:0x1 (POWERON),boot:0x6f (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x4086c410,len:0xd2c
load:0x4086e610,len:0x2df0
load:0x40875728,len:0x17d8
SHA-256 comparison failed:
Calculated: f356853ee9de5b48f66989025102f1b96e1605b5ce06fd144e40f80d57e2ad70
Expected: 6e517dcbb71f9e1f11e7d0c897cbb9db17ec7e484f5cf7af3860027794b50b1d
Attempting to boot anyway...
entry 0x4086c410
I (42) boot: ESP-IDF v5.1.2-dirty 2nd stage bootloader
I (42) boot: compile time Jul 23 2024 17:35:26
I (43) boot: chip revision: v0.0
I (45) boot.esp32c6: SPI Speed : 80MHz
I (50) boot.esp32c6: SPI Mode : DIO
I (55) boot.esp32c6: SPI Flash Size : 4MB
I (60) boot: Enabling RNG early entropy source...
I (65) boot: Partition Table:
I (69) boot: ## Label Usage Type ST Offset Length
I (76) boot: 0 otadata OTA data 01 00 0000d000 00002000
I (83) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (91) boot: 2 nvs WiFi data 01 02 00010000 0000e000
I (98) boot: 3 at_customize unknown 40 00 0001e000 00042000
I (106) boot: 4 ota_0 OTA app 00 10 00060000 001d0000
I (113) boot: 5 ota_1 OTA app 00 11 00230000 001d0000
I (121) boot: End of partition table
I (125) esp_image: segment 0: paddr=00060020 vaddr=42150020 size=39080h (233600) map
I (182) esp_image: segment 1: paddr=000990a8 vaddr=40800000 size=06f70h ( 28528) load
I (189) esp_image: segment 2: paddr=000a0020 vaddr=42000020 size=14ef98h (1372056) map
I (473) esp_image: segment 3: paddr=001eefc0 vaddr=40806f70 size=12af4h ( 76532) load
I (491) esp_image: segment 4: paddr=00201abc vaddr=40819a70 size=03bd4h ( 15316) load
I (495) esp_image: segment 5: paddr=00205698 vaddr=50000000 size=00068h ( 104) load
I (503) boot: Loaded app from partition at offset 0x60000
I (503) boot: Disabling RNG early entropy source...
no external 32k oscillator, disable it now.
at param mode: 1
AT cmd port:uart1 tx:7 rx:6 cts:5 rts:4 baudrate:115200
module_name: ESP32C6-4MB
max tx power=78, ret=0
v4.1.0.0-dev
controller lib commit: [77d09ce]
ESP-AT Firmware Source
Official release bin (factory), as well as generated in Github Actions and also locally compiled binary
When mobile device connects, we start pairing process:
AT+BLEENC=0,3
Mobile device gets paired. After a while, gets disconnected. We do connect one or two more devices, get pairing process completed, and then after some time, disconnect.
We expect every device previously bonded to be connected and paired automatically.
What is the actual behavior?
At some point, the devices get connected but not paired. The MAC Address that we see reported in the +BLECONN is not the same as before (as if the address resolving mechanism didn't worked as before).
Probability of recurrence
It seems to appear one or two connections after the first reset of the module, specially when the last connected and automatically paired device is not the same that tries to connect after the reset.
AT+SYSRAM?
After initialization:
+SYSRAM:217436,214404
Steps to reproduce
Bonding info cleared, factory settings (AT+RESTORE)
Initialize with commands describe previoulsy
Connect first device (android or iOS). When connected, start pairing procedure (AT+BLEENC=0,3).
In mobile device, give pairing key, wait for pairing to be completed and confirmed by +BLEAUTHCMPL:0,0
After a few moments, disconnect. Enable advertising again
Connect a different device, when connected, start pairing procedure. In mobile device, complete process and wait for +BLEAUTHCMPL:0,0
After a few moments, disconnect. Check Bonding info contains 2 addresses (AT+BLEENDEV?)
Reset system (either Reset button on Board, or AT+RST, or disconnect and reconnect USB cable).
After ready message, send initialization commands again.
When advertisement is active, connect one of the previously paired devices. It should connect and pair automatically, but here the problem appears, and gets connected but not paired, and the MAC address reported is not same as before.
@JavierReyes945 The issue of encrypted pairing information not being saved in NVS has been resolved. You can download the latest master branch AT firmware for testing to confirm if the problem is fixed.
@JavierReyes945 The issue of encrypted pairing information not being saved in NVS has been resolved. You can download the latest master branch AT firmware for testing to confirm if the problem is fixed.
Thanks for the feedback, initial testing shows good results, we are currently testing in our end product. As soon as those tests are finished, we will update/close the ticket.
Answers checklist
AT+GMR
Due to the fact that the NimBLE config for persistent storage of the bonding information is not active in the release v4.0.0.0, we had to generate a custom build based of master branch, where this setting is active. It is strange that the persistent storage of bonding data is not active by default in the release version...
ESP-AT Firmware Source
Official release bin (factory), as well as generated in Github Actions and also locally compiled binary
Hardware Information
ESP32-C6-DevKitM-1
Power Supply used
USB
What is the expected behavior?
With following Initialization:
When mobile device connects, we start pairing process:
Mobile device gets paired. After a while, gets disconnected. We do connect one or two more devices, get pairing process completed, and then after some time, disconnect.
We expect every device previously bonded to be connected and paired automatically.
What is the actual behavior?
At some point, the devices get connected but not paired. The MAC Address that we see reported in the +BLECONN is not the same as before (as if the address resolving mechanism didn't worked as before).
Probability of recurrence
It seems to appear one or two connections after the first reset of the module, specially when the last connected and automatically paired device is not the same that tries to connect after the reset.
AT+SYSRAM?
After initialization:
+SYSRAM:217436,214404
Steps to reproduce
AT command port output
The text was updated successfully, but these errors were encountered: