text:
ESP-IDF v4.4.5 Corrupting WiFi Routers / DHCP / WiFi connection  (IDFGH-10988)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.
release 4.4.5
Operating System used.
Windows
How did you build your project?
Command line with Make
If you are using Windows, please specify command line type.
None
Development Kit.
esp32 wrover ie
Power Supply used.
External 5V
What is the expected behavior?
We are facing serious issues with the V4.4.5 SDK on WiFi connection to WiFi routers where many devices are connected.
The WiFi Router simple stop to accept connections from the ESP32 and others devices such as notebooks and smartphones.
The problem only happen if there is more than 5 devices.
WiFi Routers happening this problem so far:
UniFi Ac Lite
U6 Lite
TP Link Deco M5, M9, X60
Mirastar GPT-2741GNAC-N1 (Fiber converter Telecom Router)
The sympton is the same, the router start to act slowing and than it simple drop all ESP32 connections, than stop provide DHCP. IF the router is rebooted the problem keep, the ESP32 doesnt connect anymore to this network, even if we power down and power on the ESP32, the ESP32 only connects to it if the SSID or Password is changed, so, the ESP32 is corrumpting sometrhing on it and act extremely weird in V4.4.5, so, if we build the firmware in V4.4.4 this doesnt happen.
ESP-IDF v4.4.5-dirty
downloaded from release v.4.4.5
sdkconfig-to-issue.txt
Total sizes:
Used static DRAM:   56420 bytes (  68160 remain, 45.3% used)
.data size:   23612 bytes
.bss  size:   32808 bytes
Used static IRAM:  128626 bytes (   2446 remain, 98.1% used)
.text size:  127599 bytes
.vectors size:    1027 bytes
Used Flash size : 1305029 bytes
.text     : 1147259 bytes
.rodata   :  157514 bytes
Total image size: 1457267 bytes (.bin may be padded larger)
We have add the SDKCONFIG and also the free information on the esp32 memory so far.
Can the problem be identified? Seens that LWIF is being corrupted .
We are trying to create one scenario to have th
Another Problem in the Past SDKs was:
Also there is another error happening in the same scenario, in the ESP IDF 3.4 to 4.3 some boards try to do a hanshake to have a online OTA HTTPS and the ESP32 simple abort the handshake, and than the router even forward the request to the server again, even rebooting the ESP32, so the router get corrupted by the lwip handshakes/mbed, but this doenst happen anymore in the v4.4.5. To allow this to work, we need to add a new wifi router that is old, really only old will work and set the device to connect to the this new old router acting as an wifi router with new IPs/dhcp/routing (so it is not as an accesspoint), and so, it will proceed and the handshake and mutual athentication will occurs perfect and the OTA update will conclude.
What is the actual behavior?
wifi handshake and connection working flawless without crashing the routers
Steps to reproduce.
not sure.
Debug Logs.
No response
More Information.
No response

hi, @filzek , thanks for your feedback, we will provide you a fix lib to see if it can solve your problem in coming days

hi, @filzek could you please provide some detial logs or are you convenient to capture wireless packets

I will try to make one special open firmware to collect serial data logs, we have a place to do the log capture where the problem happen, please let me know what logs and details do you want and I build the firmware special for it.

Also let me know which Wireshark packages do you want to be collected

@Xiehanxin @filzek Any update?

We have update to 4.4.6 and next week will push force an update for more than 1k devices, so after that we could collect new data to check if issue is solved.

@filzek Any update? Do you still hit the issue with v4.4.6?

@filzek any update? I am also curious to know if all things working perfectly.

@filzek any update? I am also curious to know if all things working perfectly.

We are working on this update yet, the firmware will be released next week, once it is published we will start to collect data.
What we have found so far on 4.4.5

device complete halt without and wifi/ble simple disable, freezes the tasks, and finally after about 48 hours (there was about 27k free memory) the memory completely exhausted and it reboots.

the wifi cannot connect to the AP, the wifi driver simple corrupts and it cannot connect to the wifi anymore.

sometimes there was a faulty ssl handshake and the connection simple drop, and when this happen then connection will never be done again, restart will let the handshake happen again, but some MCUs simple repeat the same problem, this doesn't happen with old routers, so using the old router in a device that the problem is persistent the problem end, in 4.4.6 this doesn't happen anymore.

the ble status sometimes has a problem and doesn't allow a stable connection after connect and start to send data packets over spp it simple drop the connection (behavior on 4.4.5), is quite random this problem.

There are a few more.
Item 1,2,4 aren't tested in 4.4.6 in large scale so we cannot assure it is fixed or not. Next week the new firmware will.be release and will be update in about a control group of 3 thousands devices in field.
So we can track and measure this faulty.
As the devices become irresponsive sometimes, we did create a way to check local behavior of it and create a side report, checking changes in BLE to see what's going on.

Ok, I'm looking forward to your further update.
I am also thinking of moving on 4.4.x SDK from 4.3.6.
I wonder if You used any 4.3.x SDK and do you have any thoughts on, whether should I upgrade 4.4.x or it is not necessary to upgrade SDK?
My application also contains WiFi and BLE components.

@Dhruvan1
v4.3 branch will be EOL by 15 Dec (https://github.com/espressif/esp-idf#esp-idf-release-support-schedule),
so I think you have to migrate to newer sdk version anyway.

We have update the SDK to 4.4.6 and the problem still happen, the log as below,
The problem traced happen direct to a problem in the SDK, if some routine that invokes something related to httpd service, http or websocket and it returns and reboot of a crash, the rebooted device doesnt work the WIFI interface anymore, it will keep forever to try to connect to the AP. The crash example is listed below:
E (57515) esp-tGuru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.

Core  1 register dump:
PC      : 0x4016a62e  PS      : 0x00060e30  A0      : 0x800ff0ba  A1      : 0x3fff9600
0x4016a62e: esp_event_loop_run at D:/Dropbox/esp-idf/components/esp_event/esp_event.c:595 (discriminator 3)

A2      : 0x3fff4988  A3      : 0x00000000  A4      : 0x00000000  A5      : 0x00000001
A6      : 0x00000001  A7      : 0x00000000  A8      : 0xb33fffff  A9      : 0x00000000
A10     : 0x00000003  A11     : 0x00000000  A12     : 0x3f41865a  A13     : 0x00000003
A14     : 0x3fffcaa8  A15     : 0x3fff4d9c  SAR     : 0x00000014  EXCCAUSE: 0x0000001c
EXCVADDR: 0xb33fffff  LBEG    : 0x40095b71  LEND    : 0x40095b81  LCOUNT  : 0xffffffe8
0x40095b71: strlen at /builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/xtensa-esp32-elf/src/newlib/newlib/libc/machine/xtensa/strlen.S:84

0x40095b81: strlen at /builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/xtensa-esp32-elf/src/newlib/newlib/libc/machine/xtensa/strlen.S:96

Backtrace: 0x4016a62b:0x3fff9600 0x400ff0b7:0x3fff9660 0x400ff4f5:0x3fff96a0
0x4016a62b: esp_event_loop_run at D:/Dropbox/esp-idf/components/esp_event/esp_event.c:595

0x400ff0b7: esp_websocket_client_dispatch_event at D:/Dropbox/esp-idf/components/esp_websocket_client/esp_websocket_client.c:155
 (inlined by) esp_websocket_client_dispatch_event at D:/Dropbox/esp-idf/components/esp_websocket_client/esp_websocket_client.c:132

0x400ff4f5: esp_websocket_client_recv at D:/Dropbox/esp-idf/components/esp_websocket_client/esp_websocket_client.c:555
 (inlined by) esp_websocket_client_task at D:/Dropbox/esp-idf/components/esp_websocket_client/esp_websocket_client.c:657

ELF file SHA256: 00678a6fa4558105

Rebooting...

So, after the crash, the system reboot it self.
I (1834) cpu_start: cpu freq: 240000000
I (1834) cpu_start: Application information:
I (1838) cpu_start: Project name:     WiseHomeSwitch
I (1847) cpu_start: App version:      10001028
I (1855) cpu_start: Compile time:     Nov 14 2023 11:43:17
I (1866) cpu_start: ELF file SHA256:  00678a6fa4558105...
I (1876) cpu_start: ESP-IDF:          v4.4.6-dirty
I (1885) cpu_start: Min chip rev:     v0.0
I (1893) cpu_start: Max chip rev:     v3.99
I (1901) cpu_start: Chip rev:         v3.0

The firmware boots complete normal, read the flash, do all operations, but the WiFi/Ble interface never came up and keep forever like the log below.
D (131565) esp_netif_lwip: esp_netif_update_default_netif_lwip 0x3ffd9378
D (131585) esp_netif_lwip: call api in lwip: ret=0x0, give sem
D (131585) event: running post WIFI_EVENT:5 with handler 0x400e0350 and context 0x3ffd9948 on loop 0x3ffd84b4
0x400e0350: event_handler at D:/Dropbox/esp-idf/Dev/PRODUCAO/main/user_main.c:5001

D (131615) wifi:Start wifi connect
D (131615) wifi:connect status 3 -> 0
D (131635) wifi:connect chan=0
D (131635) wifi:first chan=1
D (131635) wifi:connect status 0 -> 1
D (131655) wifi:filter: set rx policy=3
D (131655) wifi:clear scan ap list
D (131655) wifi:start scan: type=0x50f, priority=2, cb=0x401b8158, arg=0x0, ss_state=0x1, time=127776596, index=0
0x401b8158: cnx_start_handoff_cb at ??:?

D (131675) wifi:perform scan: ss_state=0x9, chan<1,0>, dur<0,120>
D (131705) event: running post WIFI_EVENT:5 with handler 0x4014bc04 and context 0x3fff0e84 on loop 0x3ffd84b4
0x4014bc04: event_handler at D:/Dropbox/esp-idf/components/mdns/mdns.c:4760

D (131825) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (131825) wifi:perform scan: ss_state=0x9, chan<2,0>, dur<0,120>
D (131945) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (131945) wifi:perform scan: ss_state=0x9, chan<3,0>, dur<0,120>
D (132065) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (132075) wifi:perform scan: ss_state=0x9, chan<4,0>, dur<0,120>
D (132195) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (132195) wifi:perform scan: ss_state=0x9, chan<5,0>, dur<0,120>
D (132315) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (132315) wifi:perform scan: ss_state=0x9, chan<6,0>, dur<0,120>
D (132445) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (132445) wifi:perform scan: ss_state=0x9, chan<7,0>, dur<0,120>
D (132565) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (132565) wifi:perform scan: ss_state=0x9, chan<8,0>, dur<0,120>
D (132685) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (132685) wifi:perform scan: ss_state=0x9, chan<9,0>, dur<0,120>
D (132815) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (132815) wifi:perform scan: ss_state=0x9, chan<10,0>, dur<0,120>
D (132935) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (132935) wifi:perform scan: ss_state=0x9, chan<11,0>, dur<0,120>
D (133065) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (133065) wifi:perform scan: ss_state=0x9, chan<12,0>, dur<360,360>
D (133425) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (133425) wifi:perform scan: ss_state=0x9, chan<13,0>, dur<360,360>
D (133785) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (133785) wifi:perform scan: ss_state=0x9, chan<14,0>, dur<360,360>
W (133955) wifi:Haven't to connect to a suitable AP now!
D (134145) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (134155) wifi:filter: set rx policy=4
D (134155) wifi:first chan=1
D (134155) wifi:handoff_cb: status=0
D (134175) wifi:clear rc list
D (134175) wifi:clear blacklist
D (134175) wifi:Send disconnect event, reason=201
D (134195) wifi:connect status 1 -> 3
D (134195) wifi:disable connect timer
D (134195) wifi:clear scan ap list
D (134195) event: running post WIFI_EVENT:5 with handler 0x4016c40c and context 0x3ffd9688 on loop 0x3ffd84b4
0x4016c40c: wifi_default_action_sta_disconnected at D:/Dropbox/esp-idf/components/esp_wifi/src/wifi_default.c:100

D (134225) esp_netif_handlers: esp_netif action disconnected with netif0x3ffd9378 from event_id=5
D (134245) esp_netif_lwip: check: remote, if=0x3ffd9378 fn=0x401693b4
0x401693b4: esp_netif_down_api at D:/Dropbox/esp-idf/components/esp_netif/lwip/esp_netif_lwip.c:1363

D (134265) esp_netif_lwip: esp_netif_down_api esp_netif:0x3ffd9378
D (134265) esp_netif_lwip: esp_netif_start_ip_lost_timer esp_netif:0x3ffd9378
D (134285) esp_netif_lwip: if0x3ffd9378 start ip lost tmr: no need start because netif=0x3ffd93f8 interval=60 ip=0
D (134305) esp_netif_lwip: check: local, if=0x3ffd9378 fn=0x40169e38
0x40169e38: esp_netif_update_default_netif_lwip at D:/Dropbox/esp-idf/components/esp_netif/lwip/esp_netif_lwip.c:219

D (134305) esp_netif_lwip: esp_netif_update_default_netif_lwip 0x3ffd9378
D (134325) esp_netif_lwip: call api in lwip: ret=0x0, give sem
D (134335) event: running post WIFI_EVENT:5 with handler 0x400e0350 and context 0x3ffd9948 on loop 0x3ffd84b4
0x400e0350: event_handler at D:/Dropbox/esp-idf/Dev/PRODUCAO/main/user_main.c:5001

D (134355) wifi:Start wifi connect
D (134355) wifi:connect status 3 -> 0
D (134375) wifi:connect chan=0
D (134375) wifi:first chan=1
D (134375) wifi:connect status 0 -> 1
D (134395) wifi:filter: set rx policy=3
D (134395) wifi:clear scan ap list
D (134395) wifi:start scan: type=0x50f, priority=2, cb=0x401b8158, arg=0x0, ss_state=0x1, time=130519004, index=0
0x401b8158: cnx_start_handoff_cb at ??:?

D (134425) wifi:perform scan: ss_state=0x9, chan<1,0>, dur<0,120>
D (134445) event: running post WIFI_EVENT:5 with handler 0x4014bc04 and context 0x3fff0e84 on loop 0x3ffd84b4
0x4014bc04: event_handler at D:/Dropbox/esp-idf/components/mdns/mdns.c:4760

D (134565) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (134565) wifi:perform scan: ss_state=0x9, chan<2,0>, dur<0,120>
D (134685) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (134685) wifi:perform scan: ss_state=0x9, chan<3,0>, dur<0,120>
D (134815) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (134815) wifi:perform scan: ss_state=0x9, chan<4,0>, dur<0,120>
D (134935) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (134935) wifi:perform scan: ss_state=0x9, chan<5,0>, dur<0,120>
D (135055) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (135055) wifi:perform scan: ss_state=0x9, chan<6,0>, dur<0,120>
D (135185) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (135185) wifi:perform scan: ss_state=0x9, chan<7,0>, dur<0,120>
D (135305) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (135305) wifi:perform scan: ss_state=0x9, chan<8,0>, dur<0,120>
D (135425) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (135435) wifi:perform scan: ss_state=0x9, chan<9,0>, dur<0,120>
D (135555) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (135555) wifi:perform scan: ss_state=0x9, chan<10,0>, dur<0,120>
D (135675) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (135675) wifi:perform scan: ss_state=0x9, chan<11,0>, dur<0,120>
D (135805) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (135805) wifi:perform scan: ss_state=0x9, chan<12,0>, dur<360,360>
D (136165) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (136165) wifi:perform scan: ss_state=0x9, chan<13,0>, dur<360,360>
D (136525) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (136525) wifi:perform scan: ss_state=0x9, chan<14,0>, dur<360,360>
D (136895) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (136895) wifi:filter: set rx policy=4
D (136895) wifi:first chan=1
D (136895) wifi:handoff_cb: status=0
D (136915) wifi:clear rc list
D (136915) wifi:clear blacklist
D (136915) wifi:Send disconnect event, reason=201
D (136935) wifi:connect status 1 -> 3
D (136935) wifi:disable connect timer
D (136935) wifi:clear scan ap list
D (136935) event: running post WIFI_EVENT:5 with handler 0x4016c40c and context 0x3ffd9688 on loop 0x3ffd84b4
0x4016c40c: wifi_default_action_sta_disconnected at D:/Dropbox/esp-idf/components/esp_wifi/src/wifi_default.c:100

D (136965) esp_netif_handlers: esp_netif action disconnected with netif0x3ffd9378 from event_id=5
D (136985) esp_netif_lwip: check: remote, if=0x3ffd9378 fn=0x401693b4
0x401693b4: esp_netif_down_api at D:/Dropbox/esp-idf/components/esp_netif/lwip/esp_netif_lwip.c:1363

D (137005) esp_netif_lwip: esp_netif_down_api esp_netif:0x3ffd9378
D (137005) esp_netif_lwip: esp_netif_start_ip_lost_timer esp_netif:0x3ffd9378
D (137025) esp_netif_lwip: if0x3ffd9378 start ip lost tmr: no need start because netif=0x3ffd93f8 interval=60 ip=0
D (137045) esp_netif_lwip: check: local, if=0x3ffd9378 fn=0x40169e38
0x40169e38: esp_netif_update_default_netif_lwip at D:/Dropbox/esp-idf/components/esp_netif/lwip/esp_netif_lwip.c:219

D (137055) esp_netif_lwip: esp_netif_update_default_netif_lwip 0x3ffd9378
D (137075) esp_netif_lwip: call api in lwip: ret=0x0, give sem
D (137075) event: running post WIFI_EVENT:5 with handler 0x400e0350 and context 0x3ffd9948 on loop 0x3ffd84b4
0x400e0350: event_handler at D:/Dropbox/esp-idf/Dev/PRODUCAO/main/user_main.c:5001

D (137095) wifi:Start wifi connect
D (137095) wifi:connect status 3 -> 0
D (137115) wifi:connect chan=0
D (137115) wifi:first chan=1
D (137115) wifi:connect status 0 -> 1
D (137115) wifi:filter: set rx policy=3
D (137135) wifi:clear scan ap list
D (137145) wifi:start scan: type=0x50f, priority=2, cb=0x401b8158, arg=0x0, ss_state=0x1, time=133260911, index=0
0x401b8158: cnx_start_handoff_cb at ??:?

D (137165) wifi:perform scan: ss_state=0x9, chan<1,0>, dur<0,120>
D (137165) event: running post WIFI_EVENT:5 with handler 0x4014bc04 and context 0x3fff0e84 on loop 0x3ffd84b4
0x4014bc04: event_handler at D:/Dropbox/esp-idf/components/mdns/mdns.c:4760

D (137285) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (137285) wifi:perform scan: ss_state=0x9, chan<2,0>, dur<0,120>
D (137405) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (137415) wifi:perform scan: ss_state=0x9, chan<3,0>, dur<0,120>
D (137535) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (137535) wifi:perform scan: ss_state=0x9, chan<4,0>, dur<0,120>
D (137655) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (137655) wifi:perform scan: ss_state=0x9, chan<5,0>, dur<0,120>
D (137775) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (137785) wifi:perform scan: ss_state=0x9, chan<6,0>, dur<0,120>
D (137905) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (137905) wifi:perform scan: ss_state=0x9, chan<7,0>, dur<0,120>
D (138025) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (138025) wifi:perform scan: ss_state=0x9, chan<8,0>, dur<0,120>
D (138155) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (138155) wifi:perform scan: ss_state=0x9, chan<9,0>, dur<0,120>
D (138275) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (138275) wifi:perform scan: ss_state=0x9, chan<10,0>, dur<0,120>
D (138395) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (138405) wifi:perform scan: ss_state=0x9, chan<11,0>, dur<0,120>
D (138525) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (138525) wifi:perform scan: ss_state=0x9, chan<12,0>, dur<360,360>
D (138885) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (138885) wifi:perform scan: ss_state=0x9, chan<13,0>, dur<360,360>
D (139245) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (139255) wifi:perform scan: ss_state=0x9, chan<14,0>, dur<360,360>
D (139615) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (139615) wifi:filter: set rx policy=4
D (139615) wifi:first chan=1
D (139615) wifi:handoff_cb: status=0
D (139635) wifi:clear rc list
D (139635) wifi:clear blacklist
D (139635) wifi:Send disconnect event, reason=201
D (139655) wifi:connect status 1 -> 3
D (139665) wifi:disable connect timer
D (139665) wifi:clear scan ap list
D (139665) event: running post WIFI_EVENT:5 with handler 0x4016c40c and context 0x3ffd9688 on loop 0x3ffd84b4
0x4016c40c: wifi_default_action_sta_disconnected at D:/Dropbox/esp-idf/components/esp_wifi/src/wifi_default.c:100

D (139685) esp_netif_handlers: esp_netif action disconnected with netif0x3ffd9378 from event_id=5
D (139705) esp_netif_lwip: check: remote, if=0x3ffd9378 fn=0x401693b4
0x401693b4: esp_netif_down_api at D:/Dropbox/esp-idf/components/esp_netif/lwip/esp_netif_lwip.c:1363

D (139725) esp_netif_lwip: esp_netif_down_api esp_netif:0x3ffd9378
D (139725) esp_netif_lwip: esp_netif_start_ip_lost_timer esp_netif:0x3ffd9378
D (139745) esp_netif_lwip: if0x3ffd9378 start ip lost tmr: no need start because netif=0x3ffd93f8 interval=60 ip=0
D (139775) esp_netif_lwip: check: local, if=0x3ffd9378 fn=0x40169e38
0x40169e38: esp_netif_update_default_netif_lwip at D:/Dropbox/esp-idf/components/esp_netif/lwip/esp_netif_lwip.c:219

D (139775) esp_netif_lwip: esp_netif_update_default_netif_lwip 0x3ffd9378
D (139795) esp_netif_lwip: call api in lwip: ret=0x0, give sem
D (139795) event: running post WIFI_EVENT:5 with handler 0x400e0350 and context 0x3ffd9948 on loop 0x3ffd84b4
0x400e0350: event_handler at D:/Dropbox/esp-idf/Dev/PRODUCAO/main/user_main.c:5001

D (139815) wifi:Start wifi connect
D (139815) wifi:connect status 3 -> 0
D (139835) wifi:connect chan=0
D (139835) wifi:first chan=1
D (139835) wifi:connect status 0 -> 1
D (139865) wifi:filter: set rx policy=3
D (139865) wifi:clear scan ap list
D (139865) wifi:start scan: type=0x50f, priority=2, cb=0x401b8158, arg=0x0, ss_state=0x1, time=135981715, index=0
0x401b8158: cnx_start_handoff_cb at ??:?

D (139885) wifi:perform scan: ss_state=0x9, chan<1,0>, dur<0,120>
D (139905) event: running post WIFI_EVENT:5 with handler 0x4014bc04 and context 0x3fff0e84 on loop 0x3ffd84b4
0x4014bc04: event_handler at D:/Dropbox/esp-idf/components/mdns/mdns.c:4760

D (140025) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (140025) wifi:perform scan: ss_state=0x9, chan<2,0>, dur<0,120>
D (140155) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (140155) wifi:perform scan: ss_state=0x9, chan<3,0>, dur<0,120>
D (140275) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (140275) wifi:perform scan: ss_state=0x9, chan<4,0>, dur<0,120>
D (140395) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (140395) wifi:perform scan: ss_state=0x9, chan<5,0>, dur<0,120>
D (140525) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (140525) wifi:perform scan: ss_state=0x9, chan<6,0>, dur<0,120>
D (140645) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (140645) wifi:perform scan: ss_state=0x9, chan<7,0>, dur<0,120>
D (140765) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (140775) wifi:perform scan: ss_state=0x9, chan<8,0>, dur<0,120>
D (140895) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (140895) wifi:perform scan: ss_state=0x9, chan<9,0>, dur<0,120>
D (141015) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (141015) wifi:perform scan: ss_state=0x9, chan<10,0>, dur<0,120>
D (141145) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (141145) wifi:perform scan: ss_state=0x9, chan<11,0>, dur<0,120>
D (141265) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (141265) wifi:perform scan: ss_state=0x9, chan<12,0>, dur<360,360>
D (141625) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (141635) wifi:perform scan: ss_state=0x9, chan<13,0>, dur<360,360>
D (141995) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (141995) wifi:perform scan: ss_state=0x9, chan<14,0>, dur<360,360>
D (142355) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (142355) wifi:filter: set rx policy=4
D (142355) wifi:first chan=1
D (142355) wifi:handoff_cb: status=0
D (142375) wifi:clear rc list
D (142385) wifi:clear blacklist
D (142385) wifi:Send disconnect event, reason=201
D (142405) wifi:connect status 1 -> 3
D (142405) wifi:disable connect timer
D (142405) wifi:clear scan ap list
D (142405) event: running post WIFI_EVENT:5 with handler 0x4016c40c and context 0x3ffd9688 on loop 0x3ffd84b4
0x4016c40c: wifi_default_action_sta_disconnected at D:/Dropbox/esp-idf/components/esp_wifi/src/wifi_default.c:100

D (142425) esp_netif_handlers: esp_netif action disconnected with netif0x3ffd9378 from event_id=5
D (142445) esp_netif_lwip: check: remote, if=0x3ffd9378 fn=0x401693b4
0x401693b4: esp_netif_down_api at D:/Dropbox/esp-idf/components/esp_netif/lwip/esp_netif_lwip.c:1363

D (142465) esp_netif_lwip: esp_netif_down_api esp_netif:0x3ffd9378
D (142475) esp_netif_lwip: esp_netif_start_ip_lost_timer esp_netif:0x3ffd9378
D (142495) esp_netif_lwip: if0x3ffd9378 start ip lost tmr: no need start because netif=0x3ffd93f8 interval=60 ip=0
D (142515) esp_netif_lwip: check: local, if=0x3ffd9378 fn=0x40169e38
0x40169e38: esp_netif_update_default_netif_lwip at D:/Dropbox/esp-idf/components/esp_netif/lwip/esp_netif_lwip.c:219

D (142515) esp_netif_lwip: esp_netif_update_default_netif_lwip 0x3ffd9378
D (142535) esp_netif_lwip: call api in lwip: ret=0x0, give sem
D (142535) event: running post WIFI_EVENT:5 with handler 0x400e0350 and context 0x3ffd9948 on loop 0x3ffd84b4
0x400e0350: event_handler at D:/Dropbox/esp-idf/Dev/PRODUCAO/main/user_main.c:5001

D (142555) wifi:Start wifi connect
D (142555) wifi:connect status 3 -> 0
D (142585) wifi:connect chan=0
D (142585) wifi:first chan=1
D (142585) wifi:connect status 0 -> 1
D (142605) wifi:filter: set rx policy=3
D (142605) wifi:clear scan ap list
D (142605) wifi:start scan: type=0x50f, priority=2, cb=0x401b8158, arg=0x0, ss_state=0x1, time=138724377, index=0
0x401b8158: cnx_start_handoff_cb at ??:?

D (142625) wifi:perform scan: ss_state=0x9, chan<1,0>, dur<0,120>
D (142645) event: running post WIFI_EVENT:5 with handler 0x4014bc04 and context 0x3fff0e84 on loop 0x3ffd84b4
0x4014bc04: event_handler at D:/Dropbox/esp-idf/components/mdns/mdns.c:4760

D (142765) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (142765) wifi:perform scan: ss_state=0x9, chan<2,0>, dur<0,120>
D (142895) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (142895) wifi:perform scan: ss_state=0x9, chan<3,0>, dur<0,120>
D (143015) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (143015) wifi:perform scan: ss_state=0x9, chan<4,0>, dur<0,120>
D (143145) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (143145) wifi:perform scan: ss_state=0x9, chan<5,0>, dur<0,120>
D (143265) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (143265) wifi:perform scan: ss_state=0x9, chan<6,0>, dur<0,120>
D (143385) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (143395) wifi:perform scan: ss_state=0x9, chan<7,0>, dur<0,120>
D (143515) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (143515) wifi:perform scan: ss_state=0x9, chan<8,0>, dur<0,120>
D (143635) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (143635) wifi:perform scan: ss_state=0x9, chan<9,0>, dur<0,120>
D (143765) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (143765) wifi:perform scan: ss_state=0x9, chan<10,0>, dur<0,120>
D (143885) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (143885) wifi:perform scan: ss_state=0x9, chan<11,0>, dur<0,120>
D (144005) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (144005) wifi:perform scan: ss_state=0x9, chan<12,0>, dur<360,360>
D (144375) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (144375) wifi:perform scan: ss_state=0x9, chan<13,0>, dur<360,360>
D (144735) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (144735) wifi:perform scan: ss_state=0x9, chan<14,0>, dur<360,360>
D (145095) wifi:scan end: arg=0x0, status=0, ss_state=0x3
D (145105) wifi:filter: set rx policy=4
D (145105) wifi:first chan=1
D (145105) wifi:handoff_cb: status=0
D (145125) wifi:clear rc list
D (145125) wifi:clear blacklist
D (145125) wifi:Send disconnect event, reason=201
D (145145) wifi:connect status 1 -> 3
D (145145) wifi:disable connect timer
D (145145) wifi:clear scan ap list
D (145145) event: running post WIFI_EVENT:5 with handler 0x4016c40c and context 0x3ffd9688 on loop 0x3ffd84b4
0x4016c40c: wifi_default_action_sta_disconnected at D:/Dropbox/esp-idf/components/esp_wifi/src/wifi_default.c:100

D (145165) esp_netif_handlers: esp_netif action disconnected with netif0x3ffd9378 from event_id=5
D (145195) esp_netif_lwip: check: remote, if=0x3ffd9378 fn=0x401693b4
0x401693b4: esp_netif_down_api at D:/Dropbox/esp-idf/components/esp_netif/lwip/esp_netif_lwip.c:1363

But, if manually turn OFF the device and turn it ON again the device will get back to connect to the WiFi normally.
So there is some ESP32 anomaly happen in the Silicon level that keep the WiFi irresponsible even with a "Rebooting" after a problem happen.
Please @igrr maybve you can take a better look why this happen.
The problem start to happen in SDK 4.4.2 and up still the current 4.4.6

@Xiehanxin one simple way to bring the error to force the HTTP/Wifi layer to halt and make the esp32 to reboot is to use the websocket client and from the handler destroy it, so the ESP32 will crash and reboot, so, after that the ESP32 will have trouble to connect to wifi.
Steps are:

initiate the wifi esp_wifi_set_mode(WIFI_MODE_STA);
esp_wifi_set_storage(WIFI_STORAGE_RAM);
esp_wifi_start();
initiate the Bluetooth with BLE as bluedroid
esp_wifi_set_ps(WIFI_PS_NONE);
set the wifi sta sssid and password
connect wifi
once IP got connect the WSS websocket, and tell in the handle to stop/destroy it
system will crash as same as above log.

system reboot

System become instable and will not pass the item 5 connect to wifi.
Somethng related to the inside fuses/settings of ESP32 mcu being locked so far and will only get back to work after a POWER CYCLE on it.

@filzek
If https://github.com/espressif/esp-idf/issues/12178#issuecomment-1818007780 is 100% reproducable, maybe you can run git bisect to find the first bad commit.

@filzek If #12178 (comment) is 100% reproducable, maybe you can run git bisect to find the first bad commit.

We can't do it as the wifi lib is closed binary, only Espressif team can findout why the cpu isn't working correctly after the crash reboot

@filzek If #12178 (comment) is 100% reproducable, maybe you can run git bisect to find the first bad commit.

We can't do it as the wifi lib is closed binary, only Espressif team can findout why the cpu isn't working correctly after the crash reboot

You can do that by "git bisect",although only espressif knows that is changed in the bad commit.

we cant as the firmware has change a lot and will not build past versions, so we cant find where it is bugged, but as I meant before the bug is very easy reprodutible in any environment.

@Xiehanxin one simple way to bring the error to force the HTTP/Wifi layer to halt and make the esp32 to reboot is to use the websocket client and from the handler destroy it, so the ESP32 will crash and reboot, so, after that the ESP32 will have trouble to connect to wifi.
Steps are:

initiate the wifi esp_wifi_set_mode(WIFI_MODE_STA);
esp_wifi_set_storage(WIFI_STORAGE_RAM);
esp_wifi_start();
initiate the Bluetooth with BLE as bluedroid
esp_wifi_set_ps(WIFI_PS_NONE);

The document says "Disabling modem sleep entirely is not possible for Wi-Fi and Bluetooth coexist mode".
https://docs.espressif.com/projects/esp-idf/en/v4.4.6/esp32/api-guides/wifi.html
I think you cannot call esp_wifi_set_ps(WIFI_PS_NONE) if both Wi-Fi and BT are used.

We have removed the esp_wifi_set_ps(WIFI_PS_NONE);
same problem
we have set a read for reboot reason, even if we ask for a new reboot to cleart the reboot reason, the wifi doenst connect.
the station doenst connect to the AP anymore until a physical power off and power on.
this is a huge problem

What we have found so far is that happen any crash in esp32 and it reboots the wifi stack will be complete broken and the registers will be locked to work with STA, so, the STA will not work anymore until a full power down to reset it!
the wifi sta will never connecto to the AP anymore until a full cycle power down and on.
@AxelLin please we request full support in this as this is full huge problem to everyone.

hi, @filzek , thanks for your feedback, we will provide you a fix lib to see if it can solve your problem in coming days

@Xiehanxin Any update for the fix?

What we have found so far is that happen any crash in esp32 and it reboots the wifi stack will be complete broken and the registers will be locked to work with STA, so, the STA will not work anymore until a full power down to reset it!
the wifi sta will never connecto to the AP anymore until a full cycle power down and on.
@AxelLin please we request full support in this as this is full huge problem to everyone.

@filzek
I don't work for espressif, I'm just a normal user/developer using esp-idf.
But I can see this is a big issue if you already have more than 1K devices running.

Hi @filzek
From the logs， seems after reboot, the h/w status is not correct and WiFi can not works now.
Can you get in touch with espressif business department? This way, we can provide more prompt and efficient technical support.
Communication and feedback on GitHub are not very convenient.
Thanks.

hi @filzek ，you can directly send email to sales@espressif.com and add the github link

Hi @filzek
From the logs， seems after reboot, the h/w status is not correct and WiFi can not works now.
Can you get in touch with espressif business department? This way, we can provide more prompt and efficient technical support. Communication and feedback on GitHub are not very convenient. Thanks.

Already did,
Thanks and awaiting feedback,

@filzek Do you get further feedback?

@AxelLin we have communicated by email, and there is a similar issue might for reference: https://github.com/espressif/esp-idf/issues/12654

@filzek Could you confirm if the changes in https://github.com/espressif/esp-idf/issues/12654#issuecomment-1870155044 fixes your issue?

We have tested today with the two new libphy to use in replace of esp32 lib and rhe probvlem
log.txt
As you can see, when the crash happen the esp32 reboots, and sometimes (not all the time) it enter in a state that the wifi interface seens to become complete deaf, so, it cannot find the wifi router anymore, even if read the reboot reason and so reboot it again, the problem still happen, but, if turn the power down and on again it works perfect until any crash happen again.
Until January 08 2024 still no solution for the esp32 crash bug so far.
Cant solve this by our side as it is a bug in the sdk.
We can test any solution provided, can run any debug code that is inquired us to run as well.

Sometimes after 10 minutes, 30 minutes, of sometimes never, the wifi interface listen and connect again, this is a complete odd behavior after the crash with any bug that print and reboot, so, still awaiting to test any new solutiuon offered.

We have tested today with the two new libphy to use in replace of esp32 lib and the problem still happen.

@filzek
Did you test the modified code as suggested in https://github.com/espressif/esp-idf/issues/12654#issuecomment-1870155044 ?

Also, I have add this to phy_init.c file
void esp_phy_load_cal_and_init(void)
{
CLEAR_PERI_REG_MASK(RTC_CNTL_DIG_PWC_REG, RTC_CNTL_WIFI_FORCE_PD);
CLEAR_PERI_REG_MASK(RTC_CNTL_DIG_ISO_REG, RTC_CNTL_WIFI_FORCE_ISO);
char * phy_version = get_phy_version_str();
ESP_LOGI(TAG, "phy_version %s", phy_version);

also in
void esp_phy_enable(void)
{
    _lock_acquire(&s_phy_access_lock);

    if (s_phy_access_ref == 0) {
#if CONFIG_IDF_TARGET_ESP32
        CLEAR_PERI_REG_MASK(RTC_CNTL_DIG_PWC_REG, RTC_CNTL_WIFI_FORCE_PD);
        CLEAR_PERI_REG_MASK(RTC_CNTL_DIG_ISO_REG, RTC_CNTL_WIFI_FORCE_ISO);
        // Update time stamp
        s_phy_rf_en_ts = esp_timer_get_time();
        // Update WiFi MAC time before WiFi/BT common clock is enabled
        phy_update_wifi_mac_time(false, s_phy_rf_en_ts);
#endif

@AxelLin we have communicated by email, and there is a similar issue might for reference: #12654

@Xiehanxin @MaxwellAlan
Looks like that does not help, see https://github.com/espressif/esp-idf/issues/12178#issuecomment-1881114939 https://github.com/espressif/esp-idf/issues/12178#issuecomment-1883117133
Any further comments?

@AxelLin we have communicated by email, and there is a similar issue might for reference: #12654

@Xiehanxin @MaxwellAlan Looks like that does not help, see #12178 (comment) #12178 (comment) Any further comments?

I will try to checkout the release/v4.4 dirty and check if it can also fix the problem, okay:?

I will try to checkout the release/v4.4 dirty and check if it can also fix the problem, okay:?

@filzek
According to your report, v4.4.4 is good, but v4.4.5 has issue.
I do suggest you to run git bisect.
There should be no API changes between v4.4.4 and v4.4.5.
(Even if you hit compile error, I believe you can temporary fix it in your application code)
I think this is the fast way to find the commit causing the issue.
That would be helpful to address the issue.

I will try to checkout the release/v4.4 dirty and check if it can also fix the problem, okay:?

@filzek
According to your report, v4.4.4 is good, but v4.4.5 has issue. I do suggest you to run git bisect. There should be no API changes between v4.4.4 and v4.4.5. (Even if you hit compile error, I believe you can temporary fix it in your application code) I think this is the fast way to find the commit causing the issue. That would be helpful to address the issue.
BTW, in #12178 (comment) you mentioned the problem start to happen in SDK 4.4.2. So maybe you need to confirm which release is good. prior 4.4.2 or v4.4.4?

I am not sure if v4.4.4 is really good, but I can test all brunchs tomorrow and feedback it.

@filzek

print before crash periph clk fffc8000 periph clk fffc8000
print after crash and reboot is periph clk ffff8fcf periph clk ffff8fcf

Could you also check the normal power on reset the clk value ? Does it same with the abnormal crash and reboot clk value?

@filzek

print before crash periph clk fffc8000 periph clk fffc8000
print after crash and reboot is periph clk ffff8fcf periph clk ffff8fcf

Could you also check the normal power on reset the clk value ? Does it same with the abnormal crash and reboot clk value?

The power on is fffc8000
The after crash power reboot is ffff8fcf
I will test the connection and reboot without crash Register, but only can do it in 9 hours.

@MaxwellAlan please let me know all the prints needed to show all info, and I can collect it

Hi @filzek
Could you do below test and upload the full logs:

Using the new libphy version 4780 libphy.zip
add below code in esp_phy_load_cal_and_init func before register_chipv7_phy called.
extern void phy_reg_check(void);
phy_reg_check();

And then upload the full logs both for normal power on reboot and crash reboot.

Done,
I have attached the FULL LOG since boot for all operations.
Log Normal Power On.txt -> This is the normal power on log
Log Normal Power On.txt
Log After Crash - Reboot.txt -> This is the log after a proposital crash to reboot the system, this dispatch the bug of the wifi become deaf.
Log After Crash - Reboot.txt

Hi @filzek
Plz use the attachment of new phy lib: esp32-phy-lib.zip (unzip password: espressif, libphy version: 4791, 2c4672b) to do the compared test and also send the normal log and abnormal log to us.
Thanks

New logs here:
Log After Crash - Reboot - phy_version 4791,2c4672b.txt
Log Normal Power On - phy_version 4791,2c4672b.txt
logs collected, same problem running.

Hi @filzek
Check the latest logs, we found this issue is different we have met before. So we still have to do some more test for this.
Could you please add below debug code still using phy v4791 lib.
1.before phy init:
phy_reg_check();
phy_i2c_check();
phy_cal_print();
2.after phy init:
phy_reg_check();
phy_i2c_check();
phy_cal_print();

And then also upload the full normal and abnormal logs.

Hi @filzek
Check the latest logs, we found this issue is different we have met before. So we still have to do some more test for this.
Could you please add below debug code still using phy v4791 lib.
1.before phy init: phy_reg_check(); phy_i2c_check(); phy_cal_print(); 2.after phy init: phy_reg_check(); phy_i2c_check(); phy_cal_print();
And then also upload the full normal and abnormal logs.

The phy_i2c_check(); cant run in the TOP part of the code as produced the error
Log Normal Power On - phy_version 4791,2c4672b - Crash in phy_i2c_check();.txt
So, comment it and than it runs to produces the debug files per requested.
Log Normal Power On - phy_version 4791,2c4672b - remove phy_i2c_check in top
Log Normal Power On - phy_version 4791,2c4672b - remove phy_i2c_check in top.txt
Log After Crash - Reboot - phy_version 4791,2c4672b - remove phy_i2c_check in top
Log After Crash - Reboot - phy_version 4791,2c4672b - remove phy_i2c_check in top.txt

Hi @filzek
Compared the logs, we found that the calibration value of PHY used is abnormal when crashed reboot. But still not know how this happened. What are the peripherals that may be used in your APP?  Did you used something like ADC or tsensor which may affect the PHY calibration. Or did your test env the temperature changed very frequently？
And still need do the compared test with the latest attachment of PHY libs(ESP32_libphy_debug_20240117.zip unzip password: espressif), then also send the logs to us.
Thanks.

Hi @AxelLin,
We run a adc read every 22000us on 6 channels with a 100 reads on each, dispatch by a timer, but even disable the adc reading the problem is exact the same.
We do not have any i2c device connected to the esp32.
Also the device running is one certified by the Espressif hardware certification program, I think it was the first device certified by Espressif using esp32 module on it.
attached are the new logs per request.
Log After Crash - Reboot - phy_version 4791,a278e18 - remove phy_i2c_check in top.txt
Log Normal Power On - phy_version 4791,a278e18 - remove phy_i2c_check in top.txt

Hi @filzek

We run a adc read every 22000us on 6 channels with a 100 reads on each, dispatch by a timer, but even disable the adc reading the problem is exact the same.

Could you try a test not only disable the ADC reading, but also do not init the ADC module?
And could you provide a list of all the peripherals that used in your APP? And you can also try to not init some of them to find which may affect the PHY module.

Hi @MaxwellAlan,
This is the log with the adc not initiated.
Log Normal Power On - phy_version 4791,a278e18 - remove phy_i2c_check in top - NO ADC INIT AT ALL.txt
Log After Crash - Reboot - phy_version 4791,a278e18 - remove phy_i2c_check in top - NO ADC INIT AT ALL.txt
there is no peripherals used, only gpio config with some isr.
below are the logs without any ADC or ISR
Log Normal Power On - phy_version 4791,a278e18 - remove phy_i2c_check in top - NO ADC INIT AT ALL - NO ISR.txt
Log After Crash - Reboot - phy_version 4791,a278e18 - remove phy_i2c_check in top - NO ADC INIT AT ALL - NO ISR.txt
below are the logs without any ADC or ISR or bluetooth initiated
Log Normal Power On - phy_version 4791,a278e18 - remove phy_i2c_check in top - NO ADC INIT AT ALL - NO ISR - NO BLE.txt
Log After Crash - Reboot - phy_version 4791,a278e18 - remove phy_i2c_check in top - NO ADC INIT AT ALL - NO ISR.txt
below are the logs THERE IS NOTHING initiated, just WIFI
Log Normal Power On - phy_version 4791,a278e18 - remove phy_i2c_check in top - THERE IS NOTHING initiated, just WIFI.txt
Log After Crash - Reboot - phy_version 4791,a278e18 - remove phy_i2c_check in top -THERE IS NOTHING initiated, just WIFI.txt
So, the problem are direct related to the phy part of it, there is no peripherals, no adc, no isr, nothing, not even iniate a BLE, just the wifi and websocket, no matter if use websocket or httprequest, is any crash happen it cause the same problem, the wifi after the restart doesnt connect to the wifi ssid, it becomes deaf to any wifi.

@MaxwellAlan
Any finding in https://github.com/espressif/esp-idf/issues/12178#issuecomment-1898736386?

Hi @AxelLin
Sorry, forget to update this issue.
We have communicated in the email.

We have analyzed all the comparative test logs you provided and identified some peculiar occurrences. For instance, there are anomalies in the PHY calibration values in the logs of normal startup, yet the system still functions correctly.
As we are currently unable to pinpoint the root cause definitively, we hope that you can provide a virtual environment for us to compile locally and also share your test hardware for further testing and analysis.

PS: Did you try run this test example in ESP official boards ? Or did you try disconnect all the GPIO pins and not init the GPIO modules. Our PHY team suspect that the GPIO may affect the PHY calibration reference voltage level.

@filzek Did you try ESP official boards?

This Hardware project was validated by the Espressif team, it uses original Espressif module on it, wrover ie.
We do not have the same wrover ie 3.0 module apart, but I can ask my hardware enginner to remove one module and attach it to some other espressif original module to make sure the IC is the same.

@filzek @MaxwellAlan
How is the status now?

The problem remains present in SDK V4 and extends to all later versions, up to and including the most recent updates and fixes. Consequently, users working with SDK V4 will encounter significant issues and bugs on the ESP32, regardless of their intended application. Specifically, when the system experiences a halt and reboot, it can cause the WiFi to crash, disrupting internal system registers and rendering the WiFi interface inoperative. But....
We are pleased to report that in SDK v5.2, there are no issues with Nimble BLE and WiFi registration. Our comprehensive testing failed to replicate any of the bugs found in SDK v4. The team has made significant efforts to resolve the predominant issues with ESP32, especially those related to register malfunctions during system halts, and these efforts have been highly successful!

@filzek @MaxwellAlan How is the status now?

Move to SDK v5.2 and problem is solved!!!

Hi @AxelLin
Sorry, forget to update this issue. We have communicated in the email.

We have analyzed all the comparative test logs you provided and identified some peculiar occurrences. For instance, there are anomalies in the PHY calibration values in the logs of normal startup, yet the system still functions correctly.
As we are currently unable to pinpoint the root cause definitively, we hope that you can provide a virtual environment for us to compile locally and also share your test hardware for further testing and analysis.

PS: Did you try run this test example in ESP official boards ? Or did you try disconnect all the GPIO pins and not init the GPIO modules. Our PHY team suspect that the GPIO may affect the PHY calibration reference voltage level.

@filzek Did you try ESP official boards?

Later reply we ported all to SDK V5.2 and there is no such problem, so, SDK v4 is broken somehow. I will close this in the end of this week.

no solved so far for old sdk 4.4.7 same registers lock upon reboot on error, no lucky to solve this. moved to sdk 5.2.1 no problem at all, passed all the situation that 4.4~4.4.7 has.

no solved so far for old sdk 4.4.7 same registers lock upon reboot on error, no lucky to solve this. moved to sdk 5.2.1 no problem at all, passed all the situation that 4.4~4.4.7 has.

Hi @filzek
How about v5.0 and v5.1 branches? Do you hit this issue on v5.0/v5.1 branches?

authors: AxelLin Dhruvan1 MaxwellAlan Xiehanxin filzek

repo: espressif/esp-idf


text:
[TW#27570] SPI flash FAT partition corruption with esp-idf master

Environment

Development Kit:      none
Kit version (for WroverKit/PicoKit/DevKitC): none
Module or chip used:  ESP32-WROVER 16MB
IDF version (run git describe --tags to find it): v3.2-beta1-208-g0d7f2d77c
Build System:         make
Compiler version (run xtensa-esp32-elf-gcc --version to find it): (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a) 5.2.0
Operating System:     macOS
Power Supply:         USB

Problem Description
TLDR: Between May and July 2018 a change was made to esp idf master that is causing corruption on FAT filesystems mounted on SPI flash.
Our project uses a partitions.csv as follows:
# Name,   Type, SubType, Offset,   Size
nvs,      data, nvs,     0x9000,  0x4000
otadata,  data, ota,     0xd000,  0x2000
phy_init, data, phy,     0xf000,  0x1000
factory,  app,  factory, 0x10000,  4M
ota_0,    app,  ota_0,   ,         4M
ota_1,    app,  ota_1,   ,         4M
store,    data, fat,     ,         1M

The 'store' partition is formatted as FAT, as follows:
esp_vfs_fat_mount_config_t m_store_fat;
wl_handle_t m_store_wlh;
memset(&m_store_fat,0,sizeof(esp_vfs_fat_sdmmc_mount_config_t));
m_store_fat.format_if_mount_failed = true;
m_store_fat.max_files = 5;
esp_vfs_fat_spiflash_mount("/store", "store", &m_store_fat, &m_store_wlh);

We have previously used a clone of esp idf master, dated around May 22 2018, without issues. The partition is very reliable.
However, on Jul 6 2018, we updated our clone to use the latest esp idf master at that time. Shortly afterwards, users started to report that their 'store' filesystem contents were corrupted. We rolled back.
We have now tried again (updating on Oct 20 2018 to v3.2-beta1-208-g0d7f2d77c) and immediately had the same issue. Random corruption of FAT filesystem in SPI flash.
Expected Behavior
No corruption of FAT filesystem.
Actual Behavior
Corruption of FAT filesystem.
Steps to reproduce

Create a partition in SPI flash, and mount FAT filesystem
Read and write to files on FAT filesystem
Reboot
Observe random corruption and unmountable filesystem

Code to reproduce this issue
esp_vfs_fat_mount_config_t m_store_fat;
wl_handle_t m_store_wlh;
memset(&m_store_fat,0,sizeof(esp_vfs_fat_sdmmc_mount_config_t));
m_store_fat.format_if_mount_failed = true;
m_store_fat.max_files = 5;
esp_vfs_fat_spiflash_mount("/store", "store", &m_store_fat, &m_store_wlh);

Debug Logs
n/a
Other items if possible
Please advise if you need anything further.

Hi @markwj if the issue is reproducible, could you please raise log level to Verbose and share relevant logs (where corruption happens and partition is not mountable)? Also, when you say "random corruption", does this only mean that the partition is not mountable, or that partition is mountable but data inside files is corrupted?

Also could you possibly attach your sdkconfig? Interested in wear_levelling and FATFS configuration items.

Hi @markwj , I have some additional questions:
how easy is to reproduce the problem, how you check the filesystem and could you please provide a log in debug mode?
We have tried it, and we are not able to reproduce the problem. We need your help.
Regards,
Dmitry

Issue is hard to reproduce. It seems random. If we deploy to a dozen devices, it seems that one or two report the corruption within a week. We don't often write to the 'store' FAT partition. Mostly reads (and very few of those).
Corruption seems to make partition unmountable. We think the 'format_if_mount_failed = true' option causes it to be re-formatted on mount so wipes all data.
We will try to reproduce in the lab, By turning off the format_if_mount_failed option, we should be able to see what is going on. But may take some time. Attached is our sdkconfig.
sdkconfig.txt

Boot log with level verbose attached. Look for "ovms_main: Mounting CONFIG..."
The mount succeeds on the first boot, the partition is operational.
It fails on the second and all further boots. Last boot in the log is a cold reboot (marked).
config-corruption.log

I'll do some bisecting now to narrow this down.

Due to the nature of the bug, this is very time consuming; the bug sometimes just disappears, the hardware then needs to be kept powered off for some hours to get it back.
Intermediate status: the bug should originate within this range of commits:
balzer@leela:~/esp/esp-idf> git rev-list 9d609af54c63e7f949a4fbc43d4f1c13b57f49d8 ^9d2f7c60d9aef9860c61c2756318ada68c80fddf
9d609af54c63e7f949a4fbc43d4f1c13b57f49d8
f392727abf7d56490c2f33127a59bfac42c937e0
e834d6fffc23a6fcfc0d2e871c9235417a7fb48f
35842d02abb5f574aaab466d46081a232fdd20a6
f05f3fbde87a9ce45c6818f71b49cd13888fd457
a6d6c58ecadb9759a0bacf35cd7332ac641e598d
321b1e02052de95db60ddce87eecce5f9e04e9b8
40486c872345584d34949b3ce83f9e956a7eea13

…with 9d609af54c63e7f949a4fbc43d4f1c13b57f49d8 being the last identified bad commit, and 9d2f7c60d9aef9860c61c2756318ada68c80fddf being the last good.
I'll try to continue the hunt tomorrow.

Thank you @dexterbg, the place is clear.

Thanks for the fast reply @dmitry1945. Tell me if you'd like me to test a fix.

Hi guys!
@dexterbg, @markwj do you see this problem after reset that interrupts access to the file system?

Our reboot procedure takes care to finish all file system accesses and do proper umounts before executing the actual reset -- you can see that shutdown process in the log.
Sometimes we get a FreeRTOS crash esp-idf/components/freertos/queue.c:620 (xQueueTakeMutexRecursive)- assert failed! when shutting down, and I had several other crashes during shutdown while testing the different commit stages.
None of these crashes made a difference for this bug, if it was there before, it persisted, if it wasn't it wouldn't appear from the crash.

OK. Thanks, @dexterbg.

Note that our application doesn't write to the partition very often. It is primarily used to store configuration values and scripts, so gets written very infrequently (often not for months). Configurations are also cached in ram, so not often accessed. I don't think the issue is related to an unclean shutdown, although this being an embedded system we have very little control over that.

Hi guys,
I need your help with reproducing the problem.
For that, could you please make next changes and test the result?
I file WL_Flash.cpp line 183:
        result = this->updateVersion();

please change to

//        result = this->updateVersion();
        result = ESP_FAIL;

The final code should looks so:
        //result = this->updateVersion();
        result = ESP_FAIL;
        if (result == ESP_FAIL) {
            ESP_LOGD(TAG, "%s: init flash sections", __func__);
            result = this->initSections();
            WL_RESULT_CHECK(result);
        }
        result = this->recoverPos();
        WL_RESULT_CHECK(result);

That means that we disable the version check just to be sure that the problem is not there.
Thanks,
Dmitry

Dmitry, sorry for the delay, my module hasn't produced the bug since sunday, so I currently can't verify the workaround. I'll check with the other developers.

Thank you, Michael.

Dmitry, sorry for the long delay, I finally managed to reproduce this.
Assuming this is related to the flash version update I tried specifically formatting with the old idf version and then booting into the new one, and that reliably triggers the bug.
Unpatched new version, first boot:
I (665) ovms_main: Mounting CONFIG...
V (665) wl_flash: config start_addr=0x00000000, full_mem_size=0x00100000, page_size=0x00001000, sector_size=0x00001000, updaterate=0x00000010, wr_size=0x00000010, version=0x00000002, temp_buff
_size=0x00000020
D (675) wl_flash: config - config result: state_size=0x00002000, cfg_size=0x00001000, addr_cfg=0x000ff000, addr_state1=0x000fb000, addr_state2=0x000fd000, flash_size=0x000fa000
D (695) wl_flash: init - config ID=2, stored ID=1, access_count=0, block_size=4096, max_count=16, pos=0, move_count=0x00000000
D (705) wl_flash: init starts: crc1= 0x07031690, crc2 = 0x07031690, this->state.crc= 0xabba1234, state_copy->crc= 0xabba1234, version=2, read_version=1
D (725) wl_flash: init: try to update version - crc1= 0x07031690, crc2 = 0x07031690, result= 0x00000000
V (725) wl_flash: updateV1_V2 start
D (735) wl_flash: updateV1_V2 - process crc1=0x4c4ef2a6, crc2=0x4c4ef2a6, v1_crc1=0x4c4ef2a6, v1_crc2=0x4c4ef2a6, version=1
I (745) wl_flash: updateV1_V2 Update from V1 to V2, crc=0x4c4ef2a6,
V (755) wl_flash: updateV1_V2- result= 0x00000000, pos= 0, pos_bits= 0x000000ff
I (755) wl_flash: updateV1_V2 max_pos=251, pos=0, state.ver=1, state2.ver=1
V (885) wl_partition: erase_range - start_address=0x000fb000, size=0x00002000, result=0x00000000
V (995) wl_partition: erase_range - start_address=0x000fd000, size=0x00002000, result=0x00000000
D (995) wl_flash: updateV1_V2 - move_count= 0x00000000, pos= 0x00000000
I (995) wl_flash: updateV1_V2 update result ver=2, pos=0
V (1005) wl_flash: recoverPos start
V (1005) wl_flash: recoverPos - check pos: result=0x00000000, position= 0, pos_bits= 0x00000001
V (1015) wl_flash: recoverPos - check pos: result=0x00000000, position= 1, pos_bits= 0x00000000
D (1025) wl_flash: recoverPos - this->state.pos= 0x00000001, position= 0x00000001, result= 0x00000000, max_pos= 0x000000fb
V (1035) wl_flash: recoverPos done

Unpatched new version, second boot: it tries to update V1→V2 again, failing to do so:
I (665) ovms_main: Mounting CONFIG...
V (665) wl_flash: config start_addr=0x00000000, full_mem_size=0x00100000, page_size=0x00001000, sector_size=0x00001000, updaterate=0x00000010, wr_size=0x00000010, version=0x00000002, temp_buff
_size=0x00000020
D (685) wl_flash: config - config result: state_size=0x00002000, cfg_size=0x00001000, addr_cfg=0x000ff000, addr_state1=0x000fb000, addr_state2=0x000fd000, flash_size=0x000fa000
D (695) wl_flash: init - config ID=2, stored ID=2, access_count=0, block_size=4096, max_count=16, pos=0, move_count=0x00000000
D (705) wl_flash: init starts: crc1= 0x2de60512, crc2 = 0x2de60512, this->state.crc= 0x63e36d6e, state_copy->crc= 0x63e36d6e, version=2, read_version=2
D (725) wl_flash: init: try to update version - crc1= 0x2de60512, crc2 = 0x2de60512, result= 0x00000000
V (735) wl_flash: updateV1_V2 start
D (735) wl_flash: updateV1_V2 - process crc1=0x5efb5d48, crc2=0x5efb5d48, v1_crc1=0xef1fee53, v1_crc2=0xef1fee53, version=2
D (745) wl_flash: init: init flash sections
V (865) wl_partition: erase_range - start_address=0x000fb000, size=0x00002000, result=0x00000000
V (965) wl_partition: erase_range - start_address=0x000fd000, size=0x00002000, result=0x00000000
V (1015) wl_partition: erase_range - start_address=0x000ff000, size=0x00001000, result=0x00000000
D (1015) wl_flash: initSections - this->state->max_count= 0x00000010, this->state->max_pos= 0x000000fb
D (1015) wl_flash: initSections - result= 0x00000000
V (1025) wl_flash: recoverPos start
V (1025) wl_flash: recoverPos - check pos: result=0x00000000, position= 0, pos_bits= 0x00000000
D (1035) wl_flash: recoverPos - this->state.pos= 0x00000000, position= 0x00000000, result= 0x00000000, max_pos= 0x000000fb
V (1045) wl_flash: recoverPos done
D (1045) wl_flash: init - move_count= 0x00000000
D (1055) vfs_fat_spiflash: using pdrv=0
V (1055) ff_diskio_spiflash: ff_wl_ioctl: cmd=2

V (1065) ff_diskio_spiflash: ff_wl_read - pdrv=0, sector=0, count=1

D (1065) wl_flash: read - src_addr= 0x00000000, size= 0x00001000
V (1075) wl_flash: calcAddr - addr= 0x00000000 -> result= 0x00001000, dummy_addr= 0x00000000
W (1085) vfs_fat_spiflash: f_mount failed (13)
I (1085) vfs_fat_spiflash: Formatting FATFS partition, allocation unit size=4096

Patched new version: patch applied as you suggested, booting with a V1 formatted flash does this:
I (664) ovms_main: Mounting CONFIG...
V (664) wl_flash: config start_addr=0x00000000, full_mem_size=0x00100000, page_size=0x00001000, sector_size=0x00001000, updaterate=0x00000010, wr_size=0x00000010, version=0x00000002, temp_buff
_size=0x00000020
D (674) wl_flash: config - config result: state_size=0x00002000, cfg_size=0x00001000, addr_cfg=0x000ff000, addr_state1=0x000fb000, addr_state2=0x000fd000, flash_size=0x000fa000
D (694) wl_flash: init - config ID=2, stored ID=1, access_count=0, block_size=4096, max_count=16, pos=0, move_count=0x00000000
D (704) wl_flash: init starts: crc1= 0xa57a9f09, crc2 = 0xa57a9f09, this->state.crc= 0xffffffff, state_copy->crc= 0xffffffff, version=2, read_version=1
D (724) wl_flash: init: try to update version - crc1= 0xa57a9f09, crc2 = 0xa57a9f09, result= 0x00000000
D (724) wl_flash: init: init flash sections
V (854) wl_partition: erase_range - start_address=0x000fb000, size=0x00002000, result=0x00000000
V (954) wl_partition: erase_range - start_address=0x000fd000, size=0x00002000, result=0x00000000
V (1014) wl_partition: erase_range - start_address=0x000ff000, size=0x00001000, result=0x00000000
D (1014) wl_flash: initSections - this->state->max_count= 0x00000010, this->state->max_pos= 0x000000fb
D (1014) wl_flash: initSections - result= 0x00000000
V (1024) wl_flash: recoverPos start
V (1024) wl_flash: recoverPos - check pos: result=0x00000000, position= 0, pos_bits= 0x00000000
D (1034) wl_flash: recoverPos - this->state.pos= 0x00000000, position= 0x00000000, result= 0x00000000, max_pos= 0x000000fb
V (1044) wl_flash: recoverPos done
D (1044) wl_flash: init - move_count= 0x00000000
D (1054) vfs_fat_spiflash: using pdrv=0
V (1054) ff_diskio_spiflash: ff_wl_ioctl: cmd=2

V (1064) ff_diskio_spiflash: ff_wl_read - pdrv=0, sector=0, count=1

D (1064) wl_flash: read - src_addr= 0x00000000, size= 0x00001000
V (1074) wl_flash: calcAddr - addr= 0x00000000 -> result= 0x00001000, dummy_addr= 0x00000000
V (1084) ff_diskio_spiflash: ff_wl_read - pdrv=0, sector=2, count=1

…and everything is working and keeps working over reboots.
So you're right, it's a failure of the V1→V2 update.
I can now easily and reliably reproduce the bug by switching boot partitions, please tell me if you need another test.
Regards,
Michael

Thank you Michael,
I will check.

source: gharchive/issue

authors: dexterbg dmitry1945 igrr markwj

license_type: permissive

license_source: github-api


text:
请问什么时候mesh模块可以合并到master上？ (IDFGH-1057)

请问什么时候mesh模块可以合并到master上？

@xiaodingding Thanks for reporting the issue. Would you please help provide more details as suggested in the issue template? Thanks.

@xiaodingding Thanks for reporting the issue. Would you please help provide more details as suggested in the issue template? Thanks.

@xiaodingding Feel free to reopen the issue, but please help provide more details, thanks.


text:
NimBLE - how to cleanly close BLE stack (IDFGH-1161)

Hello -
I have been using the ESP32/NimBLE preview branch and have had good success getting our BLE central and peripheral apps running with the NimBLE APIs. Everything I've tried works as expected. It is also great that the stack requires less RAM compared to the Bluedroid implementation. In my testing we get back about 29 KB RAM.
One issue we have bumped into is not knowing how to cleanly shutdown the ESP32+NimBLE stack. All the example apps loop forever with no apparent cleanup. In our case, we need the ability to shutdown BLE while the app is running to conserve energy and RAM. Then on-demand we re-initialize BLE to perform certain functions.
The APIs to terminate the ESP32/Bluedroid stack are well documented and we use them. I didn't see anything similar for the ESP32/NimBLE stack. Could you please let us know the calls required to shutdown the ESP32/NimBLE stack, such that the stack can be restarted at some point later on-demand? For reference, here are the calls we currently use to initialize the NimBLE stack for a BLE server:
esp_nimble_hci_and_controller_init();
nimble_port_init();

ble_hs_cfg.reset_cb = nimble_on_reset;
ble_hs_cfg.sync_cb = nimble_on_sync;
ble_hs_cfg.gatts_register_cb = nimble_on_register;

ble_svc_gatt_init();
nimble_port_freertos_init(ble_host_task);

void nimble_host_task(void *param)
{
	nimble_port_run();
}

void ble_host_task(void *param)
{
	nimble_host_task(param);
}

Best regards,
Brian

@bfriedkin Thanks for the overall feedback.
I understand that disabling and then enabling Bluetooth is a valid use case. There is an API to stop the host ble_hs_stop() in the NimBLE code, but currently there seems to be no provision to stop and restart different ports (FreeRTOS, Linux etc.) it supports. We will soon be working on this.

@bfriedkin Please pull the latest feature/nimble-preview branch and update the NimBLE submodule too. We have added the support to cleanly close the NimBLE stack. Please refer the documentation here and try it out: https://github.com/espressif/esp-idf/blob/127caf3a04c603b8c289a67d36849c3ef9f269d7/components/nimble/esp-hci/include/esp_nimble_hci.h#L100

@dhrishi -
Thank you for the heads-up. I was able to confirm that the APIs work as expected.
In the esp_nimble_hci.h file, I think there's a typo here:
 *      ret = esp_nimble_hci_and_controller_deinit();
 *      if (ret != ESP_OK) {
            ESP_LOGE(TAG, "esp_nimble_hci_and_controller_init() failed with error: %d", ret);
 *      }

Inside the ESP_LOGE, I believe the string should be esp_nimble_hci_and_controller_deinit().
Regards,
Brian

@bfriedkin Oops. I will fix it. Thanks!

Hi @dhrishi ,
Thanks for supporting us with amazing jobs. I am stuck in such a situation that I used the example of esp-idf blehr and simply modified the write & notify operation. Nimble Bluetooth initialization was as it is. There is no problem with data transmission. But the problem is I can not completely clean the BLE task which gives me lots of errors. then I dug down the problem and found that maybe I am not getting the sequences of things I need to deinitialize/stop to clean everything about Nimble.  can you help me out?
my code part of initializing ble:
        nimble_port_init();                        // 3 - Initialize the host stack
	ble_svc_gap_init();     // 4 - Initialize NimBLE configuration - gap service
	ble_svc_gatt_init();   // 4 - Initialize NimBLE configuration - gatt service
	ble_gatts_count_cfg(gatt_svcs); // 4 - Initialize NimBLE configuration - config gatt services
	ble_gatts_add_svcs(gatt_svcs); // 4 - Initialize NimBLE configuration - queues gatt services.
	ble_hs_cfg.sync_cb = ble_app_on_sync;      // 5 - Initialize application
	nimble_port_freertos_init(host_task);

I hope I get proper guidance from you (could be a proper documentation/link etc).

Hi @TheSnowFall ,
Please refer to this example code that shows to initialise and deinitialise stack .

Hi @rahult-github ,
Thanks for answering. It is really helpful for me to have an answer so quickly. I am so delighted that someone is here to help me. Because I was feeling so helpless.
here is my code to stop nimble that I used in my code:
void nim_ble_stop(void){

	int ret = nimble_port_stop();
	if (ret == 0) {
	     nimble_port_deinit();

	     ret = esp_nimble_deinit();
	     if (ret != ESP_OK) {
	         ESP_LOGE(BLE_TAG, "esp_nimble_hci_and_controller_deinit() failed with error: %d", ret);
	     }
	}
}

Then here is my implementation of the nim_ble_stop() code :
if(JSON_packet_parser((char*) cb_ble_buffer)==ESP_OK){
		ESP_LOGI(BLE_TAG, "NIM BLE Stoping");

		nim_ble_stop();
		ESP_LOGI(BLE_TAG, "NIM BLE Stopped");
		vTaskDelay(20000/portTICK_PERIOD_MS);
		ESP_LOGI(BLE_TAG, "NIM BLE re_starting");
		xTaskCreate(nim_BLE_init, "BT", 2048, NULL, 10, NULL);

	}

The serial terminal output:
I (26046) BLE: NIM BLE Stoping
I (26056) NimBLE: GAP procedure initiated: stop advertising.

I (26066) NimBLE: GAP procedure initiated: terminate connection; conn_handle=1 hci_reason=19

seems that my log print in code ESP_LOGI(BLE_TAG, "NIM BLE re_starting"); does not execute i.e the program is stuck inside nim_ble_stop(). I need help regarding this issue. Can you please?

Hi @TheSnowFall ,
Are you invoking esp_nimble_deinit() inside your  nim_ble_stop function ?. If yes, then you should not.
As pointed in the code , you will need to invoke  nimble_port_stop and nimble_port_deinit for  stopping stack and  nimble_port_init and nimble_port_freertos_init to restart the stack. No other functions are needed to be invoked.
You can try the blecent example once with the flag enabled to check the working .

Hello @rahult-github ,
Thanks for giving me a way to explore.
I mentioned in my 1st comment about my appmain() function. At the end of the app main() code I added:
```

for(; ;){
if(BLE_reconnect_flag == 1){
nimble_port_stop();
nimble_port_deinit();
			vTaskDelay(100);

			        rc = nimble_port_init();
			        if (rc != ESP_OK) {
			            ESP_LOGI(BLE_TAG, "Failed to init nimble %d ", rc);
			            break;
			        }

			        nimble_port_freertos_init(blecent_host_task);
			        BLE_reconnect_flag=0;
			break;

		}

     vTaskDelay(20);
	}

I am controlling the reinitializing with BLE_reconnect_flag.
Deinitialization is ok but before reinitiating serial monitor says an error:

I (14147) NimBLE: GAP procedure initiated: stop advertising.
I (14157) NimBLE: GAP procedure initiated: terminate connection; conn_handle=1 hci_reason=19
I (34147) BLE: NIM BLE re_starting
I (34147) GAP: BLE GAP EVENT DISCONNECTED
E (34147) NimBLE: ble_hs_stop_terminate_timeout_cb,0 connection(s) still up
[nimble]Nimble started
W (34157) BLE_INIT: invalid controller state
E (34157) BLE_INIT: controller init failed
E (34167) BLE: BLE PORT Initilized Failed
assertion:ev->event
line:107,function:npl_freertos_event_deinit
assert failed: npl_freertos_event_deinit npl_os_freertos.c:107 (0)
Core  0 register dump:
MEPC    : 0x40380608  RA      : 0x40388e60  SP      : 0x3fcdd8a0  GP      : 0x3fcaeed0
0x40380608: panic_abort at C:/Espressif/frameworks/esp-idf-v5.1.1/components/esp_system/panic.c:452
0x40388e60: __ubsan_include at C:/Espressif/frameworks/esp-idf-v5.1.1/components/esp_system/ubsan.c:313
TP      : 0x3fcc5f9c  T0      : 0x37363534  T1      : 0x7271706f  T2      : 0x33323130
S0/FP   : 0x00000085  S1      : 0x00000001  A0      : 0x3fcdd8dc  A1      : 0x3fcaf9d5
A2      : 0x00000001  A3      : 0x00000029  A4      : 0x00000001  A5      : 0x3fcb1000
A6      : 0x0000000c  A7      : 0x76757473  S2      : 0x00000009  S3      : 0x3fcdd9f2
S4      : 0x3fcaf9d4  S5      : 0x00000000  S6      : 0x00000000  S7      : 0x00000000
S8      : 0x00000000  S9      : 0x00000000  S10     : 0x00000000  S11     : 0x00000000
T3      : 0x6e6d6c6b  T4      : 0x6a696867  T5      : 0x66656463  T6      : 0x62613938
MSTATUS : 0x00001881  MTVEC   : 0x40380001  MCAUSE  : 0x00000007  MTVAL   : 0x00000000
0x40380001: _vector_table at ??:?
MHARTID : 0x00000000
Stack memory:
3fcdd8a0: 0x3fcdd9bc 0x0000006b 0x3c045678 0x4038d1fa 0x3fcafcd4 0x3c045678 0x3fcafcb8 0x3c045305
0x4038d1fa: newlib_include_assert_impl at C:/Espressif/frameworks/esp-idf-v5.1.1/components/newlib/assert.c:93
3fcdd8c0: 0x3fcafce4 0x3fcdd8d4 0x3fcafce8 0x3c041954 0x3fcaf9d4 0x00373031 0x3fcdd920 0x65737361
3fcdd8e0: 0x66207472 0x656c6961 0x6e203a64 0x665f6c70 0x72656572 0x5f736f74 0x6e657665 0x65645f74
3fcdd900: 0x74696e69 0x6c706e20 0x5f736f5f 0x65657266 0x736f7472 0x313a632e 0x28203730 0x00002930
3fcdd920: 0x00373031 0x00000003 0x00000000 0x00000000 0x00000003 0x00000035 0x3f302073 0x4038cef0
0x4038cef0: _multi_heap_unlock at C:/Espressif/frameworks/esp-idf-v5.1.1/components/heap/multi_heap.c:94 (discriminator 1)
3fcdd940: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fcdd960: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x3c045000 0x400546c4
0x400546c4: rf_rw_rssi_convert in ROM
3fcdd980: 0x3c043b74 0x3c0438f4 0x00000000 0x4038cef0 0x00000000 0x00000000 0x00000000 0x3fcdd9b4
0x4038cef0: _multi_heap_unlock at C:/Espressif/frameworks/esp-idf-v5.1.1/components/heap/multi_heap.c:94 (discriminator 1)
3fcdd9a0: 0x3fce0000 0x00000000 0x00000000 0x40000000 0x00000000 0x0000006b 0x00000000 0x00000000
0x40000000: _WindowOverflow4 in ROM
3fcdd9c0: 0x00000000 0x00000000 0x3c045000 0x40382484 0x00000000 0x00000000 0x3fcb1000 0x42008974
0x40382484: npl_freertos_eventq_get at C:/Espressif/frameworks/esp-idf-v5.1.1/components/bt/porting/npl/freertos/src/npl_os_freertos.c:184
0x42008974: ble_mqueue_deinit at C:/Espressif/frameworks/esp-idf-v5.1.1/components/bt/host/nimble/nimble/nimble/host/src/ble_hs_mqueue.c:36
3fcdd9e0: 0x00000000 0x00000000 0x3fcb1000 0x42008004 0x00000000 0x00000000 0x00000000 0x42011042
0x42008004: ble_hs_deinit at C:/Espressif/frameworks/esp-idf-v5.1.1/components/bt/host/nimble/nimble/nimble/host/src/ble_hs.c:863
0x42011042: esp_nimble_deinit at C:/Espressif/frameworks/esp-idf-v5.1.1/components/bt/host/nimble/nimble/porting/nimble/src/nimble_port.c:135
3fcdda00: 0x0000ce00 0x00000000 0x00000000 0x420111e6 0x00000000 0x00000000 0x00000000 0x42006b44
0x420111e6: nimble_port_deinit at C:/Espressif/frameworks/esp-idf-v5.1.1/components/bt/host/nimble/nimble/porting/nimble/src/nimble_port.c:187
0x42006b44: nim_BLE_init at C:/Users/MN/Documents/GitHub/SLA_SP_Skeleton/SLa_skeleton_to_production/main/nim_ble.c:254
3fcdda20: 0x00000000 0x00000000 0x00000000 0x4038b3b8 0x00000000 0x00000000 0x00000000 0x00000000
0x4038b3b8: vPortTaskWrapper at C:/Espressif/frameworks/esp-idf-v5.1.1/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:205
3fcdda40: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
3fcdda60: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0x00000154 0x3fcdd850 0x3fcdcb84 0x3fcdebe8
3fcdda80: 0x3fcb0768 0x3fcdda74 0x3fcb0760 0x0000000f 0x4038b506 0x4038b530 0x3fcdda74 0x00000000
0x4038b506: vPortClearInterruptMask at C:/Espressif/frameworks/esp-idf-v5.1.1/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:385
0x4038b530: vPortExitCritical at C:/Espressif/frameworks/esp-idf-v5.1.1/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:339
3fcddaa0: 0x0000000a 0x3fcdd270 0x00005442 0x00000000 0x3fcddb78 0x00cddb78 0x00000000 0x3fcdda60
3fcddac0: 0x0000000a 0x00000000 0x00000000 0x00000000 0x00000000 0x3fcb2d24 0x3fcb2d8c 0x3fcb2df4
3fcddae0: 0x00000000 0x00000000 0x00000001 0x00000000 0x00000000 0x00000000 0x4203d01a 0x00000000
0x4203d01a: _cleanup_r at /builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/riscv32-esp-elf/src/newlib/newlib/libc/stdio/findfp.c:229
3fcddb00: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fcddb20: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fcddb40: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fcddb60: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fcddb80: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fcddba0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fcddbc0: 0x00000000 0x3f000000 0x00000101 0x3fcdcb84 0x3fcdcb84 0x00000000 0x3fcb2d24 0x3fcb2d8c
3fcddbe0: 0x3fcb2df4 0x00000000 0x00000000 0x00000001 0x00000000 0x00000000 0x00000000 0x4203d01a
0x4203d01a: _cleanup_r at /builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/riscv32-esp-elf/src/newlib/newlib/libc/stdio/findfp.c:229
3fcddc00: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fcddc20: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fcddc40: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fcddc60: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
3fcddc80: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000

Hi @rahult-github ,
Thanks for the help. It is working great.
I was just looping myself with the api's . Now I know how to do it. i appreciate your help.

authors: TheSnowFall bfriedkin dhrishi rahult-github


text:
esp32 s2 tiny usb driver lost complete interrupt  during concurrent IN & OUT  test  (IDFGH-6285)

Environment
verion:esp-idf-4.3-beta3
EPS32 S2  as a usb device
host : centos7
Describe your problem
esp-idf-4.3-beta3\esp-idf-4.3-beta3\components\tinyusb\tinyusb\src\portable\espressif\esp32s2\dcd_esp32s2.c
when concurrent issue USB IN & OUT transcation in stress test. it seem lost complete interrupt  that cause USB can't work.
(USB0.out_ep_reg[n].doepint & USB_XFERCOMPL0_M)  or(USB0.in_ep_reg[n].diepint & USB_D_XFERCOMPL0_M) can't ocurr in bad case.
I suspect the esp-idf tiny usb have known limitation beacuse the IOT project use a Semphore for switch IN or OUT transfer.
refer:
esp-iot-solution\components\usb\tinyusb\additions\tusb\src\class\net\net_device.c
3.  my queston:
is that it's a limitation for usb transfer? or it's a bug ?

let me update status .
my diy project is a usb 802.11 wireless network card with esp32s2,
the  root cause maybe the wifi EMI affect the USB transfer that cause esp32s2 usb transfer failed.  and the esp32s2 usb tinyusb seem doesn't have any error recovery flow, then the USB endpoint work abnormal.
the USB recieve the data from host, then issue the data to wifi interface, then wifi start transmit, and the wifi also input data to host, then the EMI affect the USB transfer.
I doesn't have the USB sniffer now, maybe 202201 got one . i will check the bus status .

Hello @chuanjinpang sorry for such a long delay.
this may be the same case as https://github.com/espressif/esp-idf/issues/7404 and https://github.com/espressif/esp-idf/issues/8241
Could you please try your code on latest master branch of esp-idf?

Thanks for reporting, will close due to short of feedback, feel free to reopen with more updates. Thanks.

authors: Alvin1Zhang chuanjinpang tore-espressif


text:
esp-netif: esp_netif_is_netif_up should also check netif_is_link_up (IDFGH-3171)

Otherwise esp_netif_update_default_netif_lwip() may select wrong interface
as default route. e.g. calling esp_netif_is_netif_up() for ppp interface before
dialing up returns true without this patch then it's selected as the default
route due to higher priority.
Signed-off-by: Axel Lin axel.lin@gmail.com

@AxelLin Thanks for your contribution. @david-cermak

source: gharchive/pull-request


text:
ESP32S3 with W5500 LAN Chipset

Our demo board with W5500 and the built-in Ethernet library from ESP-IDF works perfectly.
However if we start matter, it fails to initialise the chip stack:
E (831) esp_matter_core: Failed to initialize CHIP stack
E (831) esp_matter_core: Error initializing matter
E (831) matter_init: Matter start failed: -1

Any idea why that could be? Is there any way to run matter just for pairing and control, without commissioning a network connection?

Matter is loading into SRAM and you have run out. We are also struggling with forcing Matter to load into PSRAM.

@mgoeller Can you try moving the NimBLE (BLE host) and mbedTLS to PSRAM. This should free up some internal memory. Steps:
idf.py menuconfig

Component config -> ESP32S3-Specific -> Support for external, SPI-connected RAM

Component config -> Bluetooth -> NimBLE Options -> Memory allocation strategy -> External SPIRAM

Component config -> mbedTLS -> Memory allocation strategy -> External SPIRAM

Is there any way to run matter just for pairing and control, without commissioning a network connection?

Do you mean not doing the "network/Wi-Fi connection" and carrying out commissioning on the IP network directly?

That is not enough to fix this issue. You need to also move BSS / DATA into PSRAM.

Do you mean not doing the "network/Wi-Fi connection" and carrying out commissioning on the IP network directly?

Correct. That is exactly what I am looking for. However I don't think the problem has to do with PSRAM. Because the WiFi example runs fine.
The problem is rather:
In my lan_start() routine I called the function esp_netif_init(), which should only be called once. This function is also called in PlatformManagerImpl.cpp via Matter. Once out-commenting the line in my code, then calling esp_matter::start() first, and afterwards initialising ethernet via my routine, I successfully get an IP. This only works when wifi is deactivated in the matter settings in menuconfig.
Even though in my understanding, Bluetooth is not needed when using a fixed Ethernet connection (since no comissioning of the WiFi settings), I can't disable Bluetooth in menuconfig. Otherwise the code doesn't compile.
Leaving Bluetooth activated, I can pair the accessory with Google Home (via Bluetooth), however get an immediate "No Response" in the App afterwards. With Apple Home pairing doesn't work at all.

Even though in my understanding, Bluetooth is not needed when using a fixed Ethernet connection (since no comissioning of the WiFi settings), I can't disable Bluetooth in menuconfig. Otherwise the code doesn't compile.

@mgoeller We have fixed the issue. Please pull the latest codebase and then disable Bluetooth from menuconfig. You should be able to compile and you should have significant amount of memory.

authors: dhrishi jonsmirl mgoeller

repo: espressif/esp-matter


text:
Add choozi

This is a new app for Bangle.js.
It chooses people or things at random with a fun animation. For example, you can use it to decide who goes first in a board game. There's a video demo here: https://www.youtube.com/watch?v=4cqOLNM5ei8
I hope I did everything right, please let me know what to fix if not.
I also included a fix for a typo (nu => no) in the README.
It is inspired by "Chwazi" for Android.

This looks great, thanks! Merging now. If anything it's just a shame that the video you made can't be seen by those browsing apps. I guess if you made a README you could link it there though if you wanted?

Thanks! I've created a new pull request to add a README.

authors: gfwilliams jes

repo: espruino/BangleApps

license: MIT


text:
Filter out more messages than the ones to Gadgetbridge

Apps printing stuff in boot makes the app loader practically useless without a codeless reboot of the watch.
This ignores all messages that don't start with ###COMMS### to filter those lines out.

Thanks - what happens if the uploaded line actually fails with an error and "###COMMS###-OK" is never sent though? Does it just crash?
Also, what apps are there that are causing problems?
Also, I'd stick with the standard 'OK' - since we're quite limited on bandwidth we don't want to be sending/receiving sometimes 100x extra characters for ###COMMS###- and it'll hurt upload speed.

I assume that the buffered lines would run out faster than can be delivered via BLE. Then the promise would be rejected. But i didn't test that theory.
As for the ###COMMS### being to long, i understand that. Probably one or two non-ASCII characters would do the job of removing enough collisions just fine.

Closing this now as...

I've now added some extra message filtering
We now call a bunch of functions to disable timeouts/etc when restarting, so hopefully nothing else should be running in the background

authors: gfwilliams halemmerich

repo: espruino/EspruinoAppLoaderCore


text:
NVIDIAドライバを使用しているとヘルプが表示されない

画面がまっしろのままになってしまう。
see https://bugs.webkit.org/show_bug.cgi?id=261874

done at c7b93ca271c6a5876c291cf652a88b47575bf10d

repo: esrille/ibus-hiragana


text:
小晨旭

services.Configure(Configuration.GetSection("WeChatPay"));
请问如何配置支持多种支付渠道，
如果WeChatPay中AppId配置的小程序的AppId，则小程序、PC扫码支付都没有问题。但是微信内浏览器因为需要走公众号支付，就会出错，因为微信内的openid和WechatPay中的appid是没有关联关系的

services.Configure(Configuration.GetSection("WeChatPay"));
请问如何配置支持多种支付渠道，
如果WeChatPay中AppId配置的小程序的AppId，则小程序、PC扫码支付都没有问题。但是微信内浏览器因为需要走公众号支付，就会出错，因为微信内的openid和WechatPay中的appid是没有关联关系的

我想你应该补习一下 ASP.NET Core 中的选项模式

repo: essensoft/paylink


text:
Is there a default Database being installed?

I have successfully installed on my local machine using Maven. Is there a default DB being installed?

The current config file (1) tells the framework (Apache Isis) to use an in-memory db. This works for demo / testing. We recommend using Postgre for production when using OS.
More information you find on (2)
(1)
https://github.com/estatio/estatio/blob/master/estatioapp/webapp/src/main/webapp/WEB-INF/persistor.properties#L27
(2)
http://isis.apache.org/guides/rgcfg.html#3.-configuration-files
http://isis.apache.org/guides/ugbtb.html#6.-datanucleus

repo: estatio/estatio

license_source: bigquery


text:
Comodo SSL cert issue

Unfortunately the app cannot connect to my home assistant due to a certificate verification error. I use a public wildcard certificate from Comodo and it seems that this CA or the sub CA isn't trusted by the app. The log shows "unable to get local issuer certificate(handshake.cc:352))"
Is there any workaround to get this fixed. Because disabling TLS isn't an option for me, I'm not able to use the app.

I think I have the same issue, just not with a Comodo certificate but with one created by mkcert.
0407 22:19:15 [Debug] :  AppLifecycleState.inactive
0407 22:19:15 [Debug] :  AppLifecycleState.resumed
0407 22:19:15 [Debug] :  Use lovelace is true
0407 22:19:15 [Debug] :  Socket connecting...
0407 22:19:16 [Error] :  Socket stream Error: WebSocketChannelException: WebSocketChannelException: HandshakeException: Handshake error in client (OS Error:
	CERTIFICATE_VERIFY_FAILED: unable to get local issuer certificate(handshake.cc:352))
0407 22:19:16 [Debug] :  Automatic reconnect is false

Not strictly Comodo SSL issue - I have the same issue with the same error, just on a wildcard AlphaSSL certificate.

My solution to this issue was to have my Home Assistant server offer the full certificate chain. How you do that may vary between issuers, but in my case I created a file file that contained the original certificate, followed by the contents of the 'bundle' file that was included with it and then pointed my HA configuration against it.

I'm serving a full chain (my cert, followed by the bundle in one file) - and that doesn't work.

I'm having the same issue. I'm using a with a Let's Encrypt Authority X3 certificate using TLS 1.2
Chrome 74.0.3729.157 connects and accepts the SSL certificate through the browser on the same device running Android 9.
0530 15:16:11 [Debug] :  Socket connecting...
0530 15:16:11 [Error] :  Socket stream Error: WebSocketChannelException:
WebSocketChannelException: HandshakeException: Handshake error in client (OS Error:
	CERTIFICATE_VERIFY_FAILED: unable to get local issuer certificate(handshake.cc:352))
0530 15:16:11 [Debug] :  Automatic reconnect is false
0530 15:16:14 [Debug] :  Socket sink closed
The app works really well without SSL. Very responsive and stable. I appreciate all your work on this and am eagerly anticipating device tracking and push notifications.

I'm getting the same error. With self created CA (added to trusted in android) and certificate signed by this CA with SAN - IP. Chrome accepts this certificated without issues.

@estevez-dev I saw your post https://community.home-assistant.io/t/beta-ha-client-native-android-client-for-home-assistant/69912/153 . May this be applied to your app: https://developer.android.com/training/articles/security-config ?
According to it from API 24 there is no <certificates src="user" /> in the default configuration. Could we add this to the default app configuration, since HA is about home, and home is self-made stuff (CAs in this case). Moreover Chrome accepts certificates from user's cert store.
Here is an example: https://github.com/flutter/plugins/blob/master/packages/video_player/example/android/app/src/main/res/xml/network_security_config.xml

Thanks @urusha I'll try to add it for the 0.7.3 release

Same issue with latest 0.7.3 ...

This is sad. Will continue my investigations here.

@naamah75 that commit wasn't aimed to solve your issue, it was about mine. But that didn't work for me too. Seems there is another common issue with certificates.

Merging this issue with #180

authors: JanSchnacki MTrab RockWest estevez-dev gladdiieh naamah75 urusha warrenseymour


text:
Import Order Breaks Other Objects Before Client() (Kotlin)

Not sure how to put this, but I just spent the better part of the past few days hitting my head on the wall to figure this out (new to Kotlin), so maybe this will be beneficial to others, maybe it's an obscure bug, Idk.
Here's the signup sample code, verbatim, from the docs:
import com.etebase.client.*
import okhttp3.OkHttpClient;

val httpClient: OkHttpClient = Builder().build()

val user = User("username", "text@example.com")
// serverUrl can obtained from the dashboard (or null for default)
val client = Client.create(httpClient, serverUrl)
val etebase = Account.signup(client, user, "password")

However, there is a project that this is for which uses strict styleCheck asserts that fail if importing with asterisks.  Thus, my import looks more like this:
import com.etebase.client.Account
import com.etebase.client.Client
import com.etebase.client.User
import com.etebase.client.Utils.randomBytes
import com.etebase.client.Utils.toBase64
import okhttp3.OkHttpClient
...

This caused the User() method to fail, not knowing what to do with the abstract code that Flapigen generated (User.java):
E/i.[].debu: No implementation found for long com.etebase.client.User.init(java.lang.String, java.lang.String) (tried Java_com_etebase_client_User_init and Java_com_etebase_client_User_init__Ljava_lang_String_2Ljava_lang_String_2)
E/ACRA: ACRA caught a UnsatisfiedLinkError for []
    java.lang.UnsatisfiedLinkError: No implementation found for long com.etebase.client.User.init(java.lang.String, java.lang.String) (tried Java_com_etebase_client_User_init and Java_com_etebase_client_User_init__Ljava_lang_String_2Ljava_lang_String_2)

This drove me absolutely nuts for a long time, even to the point of skipping class to try to knock it out.  Several hours later, after so many reinstalls and searching the web without rest, I finally decided to try putting the User() call under the Client() call.  It worked but then I got another error, which prompted me to try also putting toBase64() under Client(), and then I suddenly (finally) had my first successful account registration.  Why this works, don't ask me.  I assume maybe it's common sense to Kotlin experts, but I nearly gave up on the project when I hit this wall.
Also, this:
...
        val httpClient: OkHttpClient = Builder().build()
...

Gets some complaints because there are apparently hundreds of Builder() classes.  Meaning, you have to do one of two things:
import okhttp3.OkHttpClient
import okhttp3.OkHttpClient.Builder

... or:
...
        val httpClient: OkHttpClient = okhttp3.OkHttpClient.Builder().build()
...

... which looks a bit tacky and many stylists would complain about in an official repo.
Anyway, I was just laying down this information because I was asked to, and maybe someone will find it useful.

Wrong repo...  let's not talk about this...

repo: etesync/etebase-js


text:
fix ETEBASE_UTILS_PRETTY_FINGERPRINT_SIZE value

Fixes #7

I wonder how it came to be. Have we changed the signature format? Or why did it happen?

repo: etesync/libetebase


text:
Implement better patches

As suggested in  #52 , use split_inclusive and raw_lines consistently.
Add some flags to regex patches so they are multi-line, and smartly pad insertions to avoid accidentally concatenating to identifiers (they can still be intentionally concatenated to using explicit capturing of the identifier)
Implement multi-line pattern patches

It looks like you used rustfmt on some files? To be honest the whole thing should be standardized with rustfmt

hey, sorry. I'll take a second look at the logic, not just formatting, later. the rustfmt changes are just a bit annoying, but I can deal

It looks like you used rustfmt on some files? To be honest the whole thing should be standardized with rustfmt

Yes, I did.

hey, your PR is great- I am pretty particular about style, sorry. Do need to do the check for bad concatenation last though

How is this looking right now?

Anything more?

Chatted with @english5040, your changes look good. Excellent work!

repo: ethangreen-dev/lovely-injector


text:
Churn schedule active row

In the Churn Schedule table, highlight the table row which corresponds to the current active validator count.

Great addition! Sorry for the delay, my notifications were somehow turned off for this repo 🙈

Great addition! Sorry for the delay, my notifications were somehow turned off for this repo 🙈

Thank you! Happy to contribute in whatever small way. Great service you've got here :)

authors: adamgall hanniabu

repo: etheralpha/validatorqueue-com


text:
デザイン-スマホ対応（ヘッダー）

・上の赤枠
メニューの間隔が狭くタップしづらい
間隔（line-height？）はを広げたい
お問い合わせと言語アイコンはそのままでは違和感があるので、「お知らせ」と同じプレーンなテキストにできますか？
・下の赤枠
スマホ（iPhone8）では寺が出ないので、いっそ黒背景にアイコンとテキストをtext-aligh="center"で表示したい

ツールチップも同様に、タップ領域が狭いので行間を開けたい

こんな感じでどうでしょうか？
寺画像の件ですが、
あと、私の方では、寺画像が表示されていました。
後ほどコミットしたときに再度寺画像の確認いただけますか？

こんな感じでどうでしょうか？
寺画像の件ですが、
あと、私の方では、寺画像が表示されていました。
後ほどコミットしたときに再度寺画像の確認いただけますか？

@couger-ito
大丈夫です、ありがとうございます
「日本語/English」をクリックした場合も、ツールチップが出る挙動でよいでしょうか

@couger-ito
大丈夫です、ありがとうございます
「日本語/English」をクリックした場合も、ツールチップが出る挙動でよいでしょうか

@couger-ito
大丈夫です、ありがとうございます
「日本語/English」をクリックした場合も、ツールチップが出る挙動でよいでしょうか

それぞれの言語のTOPページへの、テキストリンクとなっております。

@couger-ito
大丈夫です、ありがとうございます
「日本語/English」をクリックした場合も、ツールチップが出る挙動でよいでしょうか

それぞれの言語のTOPページへの、テキストリンクとなっております。

@couger-ito
挙動はそれで大丈夫です
ただ、寺は出てこないので、アイコン・テキストの中央寄せか、寺が出るよう調整をお願い致します
端末がiPhone8という以外の情報が必要でしたら、仰ってください

@couger-ito
挙動はそれで大丈夫です
ただ、寺は出てこないので、アイコン・テキストの中央寄せか、寺が出るよう調整をお願い致します
端末がiPhone8という以外の情報が必要でしたら、仰ってください

@Keita-Shimizu135
寺画像が出ない原因がわからなかったので、
アイコン・テキストの中央寄せで対応しました。

@Keita-Shimizu135
寺画像が出ない原因がわからなかったので、
アイコン・テキストの中央寄せで対応しました。


text:
Extract static analysis component into npm module

The static analysis modules should be usable as part of a CI run. Because of that, they should have their own npm module and should work without any UI dependencies.
A quick look at the code showed that yo-yo is used, but it should be easy to remove that. Furthemore, some utility functions are used which are probably also quite easy to replace.

Noticed AST walking was one of those utilities, which has only a couple of functions in it.
I have also noticed that the current format is generated using something called legacy mode in the json converter. This only seem to supports legacy mode.

hmm yes depending on the remix repo only because of the ast walker is too much :)
well I think we should start to split up the remix repo first... (or just keep the remix dependency for now).
for the yo-yo dependency, we use it to avoid script injection  ( warning is html formatted ) . but that totally fine to use another structure for warning (like a json which describe the warning).

I could start to split up the remix repo when I get some time

authors: androlo chriseth yann300

repo: ethereum/browser-solidity

license: mit


text:
ModuleNotFoundError: No module named 'py_ecc'

Followed all steps and have ubuntu 18.04 with
python3.7 --version
Python 3.7.8
pip3 --version
pip 9.0.1 from /usr/lib/python3/dist-packages (python 3.7)
git clone https://github.com/ethereum/eth2.0-deposit-cli.git
cd eth2.0-deposit-cli
pip3 install -r requirements.txt
python3.7 setup.py install
#all above worked without issues
python3.7 ./eth2deposit/deposit.py --num_validators 1 --chain medalla
Traceback (most recent call last):
File "./eth2deposit/deposit.py", line 5, in
from eth2deposit.credentials import (
File "/usr/local/lib/python3.7/dist-packages/eth2deposit-0.2.1-py3.7.egg/eth2deposit/credentials.py", line 5, in
from py_ecc.bls import G2ProofOfPossession as bls
ModuleNotFoundError: No module named 'py_ecc'

I had similar issue a moment ago. Do you have any compilation errors while executing   pip3 install -r requirements.txt ?
In my case it helped when I installed headers and static libs in correct version. For you it should probably be sudo apt-get install python3.7-dev. Then try to rebuild.

Thanks, that helps

authors: davidfrothin piotrbednarczyk


text:
Run pyupgrade on the codebase and clean things up.

What is wrong?
We have some things in the codebase that could be fixed automatically by pyupgrade
How can it be fixed
See: https://github.com/ethereum/py-evm/pull/1789

@pipermerriam I have to pyupgrade on every file in the repo?

@Patil2099 I believe you can apply it to whole directories.

:+1: to @iamonuwa

@iamonuwa you're good to go on this one! Sorry about that @sprimage there should be some other Python issues up that are good fits though :)

@pipermerriam can I continue with the PR or create a new one?

@iamonuwa whatever you'd like to do is fine

@pipermerriam there is a PR waiting for you 😁

Hi guys,
Am I eligible to receive the bounty for this issue?
@pipermerriam @ceresstation

@pipermerriam Can this be closed because of #1859?

@Swixx I think so. Thanks for the hint.

authors: Patil2099 Swixx cburgdorf ceresstation iamonuwa imwatsi pipermerriam

repo: ethereum/py-evm