During BLE Mesh Provisioner initialization, the stack will restore
the nodes information if settings storage is enabled.
Previously when a failure happens (e.g. found the same uuid) during
the restore procedure, the information of the following nodes will
not be restored and error will be directly returned.
But this will introduce some problem with user experience, because
some newly provisioned nodes information will not be restored and
Provisioner will not be able to control those nodes.
So we change the operation here, when a failure happens during the
restore procedure, Provisioner will only ignore the information of
the current node and continue restoring other nodes information.
With this change, if a Provisioner has provisioned the maximum
number of nodes, it can still report the unprovisioned device
beacon from other nodes to the application layer. And this will
be more reasonable compared with the previous implementation.
Previously when the node array of Provisioner is full, no beacon
from unprovisioned devices will be reported, only some warning
logs will be given.
Previously only check the node address when it is assigned by the
application layer. Here we also check the address when the address
is allocated internally. And this will be useful when some mesh
internal tests are performed.
Previously the BLE_MESH_MAX_STORED_NODES option is added for
internal mesh test, which will be a little confusing for the
users to understand.
Here we remove this option, instead the BLE_MESH_MAX_PROV_NODES
will be used for all the cases. For mesh internal test, when
the test function is called to add some nodes info, the info
will be stored in the array of provisioned nodes directly.
The replay protection list of Provisioner should be at least equal
to the number of nodes with the precondition that each node contains
only one element.
The help information of replay protection list is updated, and the
maximum number of nodes for Provisioner is adjusted based on the
replay protection list size.
On Xtensa, backtrace can not recover the two most significant bits of
the address, as the window call size is encoded in these bits.
Because of this, __builtin_return_address modifies these MSBs to
match those of the callee, "fixing" the address. An unfortunate side
effect is that the zero return address, which usually terminates the
backtrace, gets converted to 0x40000000. While there is a valid
instruction at this address, its occurrence in the backtrace is
highly unlikely: this is the first instruction of WindowOverflow4
vector, and IDF apps switch VECBASE to an IRAM location very early at
startup.
Commit fc03161f updated esp_ota_get_app_elf_sha256 to store and return
X number of bytes of the hash, but the test case still expected 64 bytes.
Updated test case to use CONFIG value for expected length.
This is a regression from earlier commit related to TLSV12 which used
sha functions that are currently declared static.
Solution: Follow upstream code structure and resolve the errors.
1. add enable PSRAM 2T mode function
2. abort when himem and 2T mode are enabled meanwhile
3. set SPIRAM_2T_MODE as "n" by default, enable it when needed
1. Fix WiFi log print level
2. Optimize WiFi/BT coexist sleep
- If any data tx/rx in WiFi slice, fore wakeup next TBTT
- Increase active timeout time to coex TBTT interval to avoid sleep in WiFi slice
3. Fix esp_wifi_stop() crash
esp_wifi_stop() crashes if it's called when WiFi is not initialized.
4. Fix esp_wifi_stop() leads to memory leak
5. esp_wifi_sta_get_ap_info() returns actual values of group ciphers
