WiFi + Provision working simultaneously

[karunt]

Thanks. That's a good solution.

[karunt]

So I tried to first stop provisioning by calling

Code: Select all

wifi_prov_mgr_stop_provisioning()

, and then restart provisioning by calling

Code: Select all

ESP_ERROR_CHECK(wifi_prov_mgr_start_provisioning(security, pop, service_name, service_key))

. The problem with this approach is that

Code: Select all

wifi_prov_mgr_stop_provisioning()

causes the chip to terminate its connection with the client and stop advertising, making it impossible to send another signal to restart provisioning. Clearly, that won't work.

A second option I tried was to call

Code: Select all

ESP_ERROR_CHECK(wifi_prov_mgr_start_provisioning(security, pop, service_name, service_key))

to restart provisioning without first calling

Code: Select all

wifi_prov_mgr_stop_provisioning()

. While this approach accomplishes the task of restarting the provisioning process, it throws the following error:

Code: Select all

wifi_prov_mgr: Provisioning service already started

. It's because the prov_ctx->prov_state isn't WIFI_PROV_STATE_IDLE. This causes ESP_ERROR_CHECK to fail with ESP_ERR_INVALID_STATE state, causes the app to abort and reboot the chip.

So while this accomplishes the task (ie, allows me to re-provision the chip), is there a more elegant solution to this problem so I can accomplish the same task (re-starting the provisioning process) without encountering an error in the restart process and without aborting/rebooting the chip? For reference, here's what the log print out is like for the second approach which works with a reboot:

Code: Select all

E (9627) wifi_prov_mgr: Provisioning service already started
ESP_ERROR_CHECK failed: esp_err_t 0x103 (ESP_ERR_INVALID_STATE) at 0x4008ea90
0x4008ea90: _esp_error_check_failed at C:/Users/Karun/ESP/esp-idf/components/esp_common/src/esp_err.c:45

file: "../main/app_main.c" line 136
func: custom_prov_data_handler
expression: wifi_prov_mgr_start_provisioning(security, pop, service_name, service_key)

abort() was called at PC 0x4008ea93 on core 0
0x4008ea93: _esp_error_check_failed at C:/Users/Karun/ESP/esp-idf/components/esp_common/src/esp_err.c:46


Backtrace:0x4008ef03:0x3ffd5240 0x4008f5a1:0x3ffd5260 0x400961da:0x3ffd5280 0x4008ea93:0x3ffd52f0 0x400d4aa0:0x3ffd5310 0x400d8327:0x3ffd5350 0x400d9709:0x3ffd53a0 0x400e07c9:0x3ffd5410 0x400e080a:0x3ffd5440 0x400e6f33:0x3ffd5480 0x400e712f:0x3ffd54b0 0x400e7a49:0x3ffd54d0 0x400db859:0x3ffd5500 0x400db54e:0x3ffd5530 0x400daa69:0x3ffd5560 0x400daa7b:0x3ffd5580 0x400e33e6:0x3ffd55a0 0x400d91e6:0x3ffd55c0 0x4008f5a9:0x3ffd55e0
0x4008ef03: panic_abort at C:/Users/Karun/ESP/esp-idf/components/esp_system/panic.c:330

0x4008f5a1: esp_system_abort at C:/Users/Karun/ESP/esp-idf/components/esp_system/system_api.c:106

0x400961da: abort at C:/Users/Karun/ESP/esp-idf/components/newlib/abort.c:46

0x4008ea93: _esp_error_check_failed at C:/Users/Karun/ESP/esp-idf/components/esp_common/src/esp_err.c:46

0x400d4aa0: custom_prov_data_handler at c:\users\karun\esp\esp-idf\examples\provisioning\wifi_prov_mgr\build/../main/app_main.c:136 (discriminator 1)

0x400d8327: protocomm_req_handle at C:/Users/Karun/ESP/esp-idf/components/protocomm/src/common/protocomm.c:267

0x400d9709: gatt_svr_chr_access at C:/Users/Karun/ESP/esp-idf/components/protocomm/src/transports/protocomm_nimble.c:363

0x400e07c9: ble_gatts_val_access at C:/Users/Karun/ESP/esp-idf/components/bt/host/nimble/nimble/nimble/host/src/ble_gatts.c:395

0x400e080a: ble_gatts_chr_val_access at C:/Users/Karun/ESP/esp-idf/components/bt/host/nimble/nimble/nimble/host/src/ble_gatts.c:421

0x400e6f33: ble_att_svr_write at C:/Users/Karun/ESP/esp-idf/components/bt/host/nimble/nimble/nimble/host/src/ble_att_svr.c:524

0x400e712f: ble_att_svr_write_handle at C:/Users/Karun/ESP/esp-idf/components/bt/host/nimble/nimble/nimble/host/src/ble_att_svr.c:555

0x400e7a49: ble_att_svr_rx_write at C:/Users/Karun/ESP/esp-idf/components/bt/host/nimble/nimble/nimble/host/src/ble_att_svr.c:2036

0x400db859: ble_att_rx at C:/Users/Karun/ESP/esp-idf/components/bt/host/nimble/nimble/nimble/host/src/ble_att.c:503

0x400db54e: ble_hs_hci_evt_acl_process at C:/Users/Karun/ESP/esp-idf/components/bt/host/nimble/nimble/nimble/host/src/ble_hs_hci_evt.c:959

0x400daa69: ble_hs_process_rx_data_queue at C:/Users/Karun/ESP/esp-idf/components/bt/host/nimble/nimble/nimble/host/src/ble_hs.c:238

0x400daa7b: ble_hs_event_rx_data at C:/Users/Karun/ESP/esp-idf/components/bt/host/nimble/nimble/nimble/host/src/ble_hs.c:532

0x400e33e6: ble_npl_event_run at c:\users\karun\esp\esp-idf\examples\provisioning\wifi_prov_mgr\build/../../../../components/bt/host/nimble/nimble/porting/npl/freertos/include/nimble/nimble_npl_os.h:121
 (inlined by) nimble_port_run at C:/Users/Karun/ESP/esp-idf/components/bt/host/nimble/nimble/porting/nimble/src/nimble_port.c:81

0x400d91e6: nimble_host_task at C:/Users/Karun/ESP/esp-idf/components/protocomm/src/transports/protocomm_nimble.c:476

0x4008f5a9: vPortTaskWrapper at C:/Users/Karun/ESP/esp-idf/components/freertos/xtensa/port.c:143



ELF file SHA256: 65b31d36e8b7d9bb

Rebooting...
ets Jun  8 2016 00:22:57

[malachib]

+1 on this. I can't explicitly leave BLE provisioning mode without a number of problems.

- if I start BLE mode up again, I get a fault
- IP stack loses its DCHP IP address, and IP connectivity to the ESP32 is generally lost

[karunt]

I found a reasonable solution that works for me. Here are the general steps:

1. Send some sort of a reboot message from app (via BLE) to ESP32 (register a new custom characteristic and write to it via BLE)
2. Use the custom_prov_data_handler function code provided in the wifi_provisioning example to recognize this message and
a) post an event to a custom event loop (to be handled by custom_event_handler) provided for in the wifi_provisioning example code, and
b) provide a response, which can then be read by the app (using the same characteristic the app wrote to in step 1).
3. Use custom_event_handler code provided in the wifi_provisioning example to stop wifi provisioning after a brief delay, allowing the app time to read response provided in step 2(b) from the same characteristic before the chip stops advertising itself. This at least lets the front end app know that the message to reset the chip was sent and received successfully. The code looks like this:

Code: Select all

vTaskDelay(1000);
wifi_prov_mgr_stop_provisioning();
ESP_ERROR_CHECK(esp_wifi_restore());

Then set whatever data needs to be set again (such as service name, security, pop, service key, etc) before calling

Code: Select all

ESP_ERROR_CHECK(wifi_prov_mgr_start_provisioning(security, pop, service_name, service_key));