Update freemodbus component file esp-idf/components/freemodbus/port/portserial.c to remove UART mode settings;
Move UART mode settings into esp-idf/examples/protocols/modbus_slave/main/freemodbus.c
Move UART pin settings from Component config into example Kconfig.projbuild file
Move setup of UART port pins from freemodbus component into example file
TW#27721
Closes https://github.com/espressif/esp-idf/issues/2784#issuecomment-443600157
This fix includes following changes:
1. Fix the bug that esp_restart()/esp_wifi_stop() sometimes fails in WiFi/BT coexist mode.
2. Add a timer for WiFi stop and stop WiFi forcibly once the timer expires.
1. start an esp_timer on entering sleep to acquire pm_lock before wake up from modem sleep
2. decrease the clock division of XTAL fed to bluetooth low power clock from 32us to 2us period to allow to work under 240MHz Max CPU frequency
3. decrease the minimum sleep duration threshold to allow shorter bluetooth modem sleep period, especially for BLE with short connection interval
4. reconfigure bluetooth baseband(BT-BB) settings after PHY/RF init upon waking up from modem sleep to avoid packet RX/TX performance degradation
When ethernet enable again after disable it before, phy init will report timeout.
The cause of this problem is that the enabling of emac clock is too late, and should be placed before phy init.
Introduced in 9c23b8e5 and 4f87a62f. To get higher speed, menuconfig
options are added to put ISR and other functions into the IRAM. The
interrupt flag ESP_INTR_FLAG_IRAM is also mistakenly set when the ISR is
put into the IRAM. However callbacks, which are wrote by the user, are
called in the master and slave ISR. The user may not be aware of that
these callbacks are not disabled during flash operations. Any cache miss
during flash operation will cause panic.
Essentially IRAM functions and intrrupt flag ESP_INTR_FLAG_IRAM are
different, the latter means not disabling the ISR during flash
operations. New bus_config flag intr_flags is offered to help set the
interrupt attribute, including priority level, SHARED, IRAM (not
disabled during flash operations). It introduced a small BREAK to
IDFv3.1 (but the same as IDFv3.0) that the user has to manually set IRAM
flag now (therefore he's aware of the IRAM thing) to void the ISR being
disabled during flash operations.
1. Fix interrupt watchdog timeout in bluetooth "btdm_bb_isr"
2. Fix BLE assert(512) or assert(1536) in rwble.c at line 222
3. Update librtc.a to fix BLE assert(512) in rwble.c at line 222
The #1 and #2 occurs random.
The #3 bug occurs in certain scenario:
1. If Wifi start softap and BLE is working
2. If wifi start station, but do not use normal station operation, such
as just use espnow, while BLE is working
3. Any other scenario, that wifi works without use software coexist
operation, while BLE is working(such as do advertising and ...)
4. update libcoexist.a version to v1.1.2
Fix some Wifi bugs:
1. Enable RX BAR
2. Fix the bug that ESP32 AP negotiates with iphone to 11g
3. Fix the bug that ESP32 STA has ap_loss because CMCC AP contains two SSID
1. fix failture of mesh stop caused by block-sending.
2. fix when FIXED_ROOT is set, 2nd layer devices can not receive mesh event ESP_ERR_MESH_NO_PARENT_FOUND.
3. fix when FIXED_ROOT is set and the root turns off mesh function, 2nd layer devices do not look for new parents.
4. add APIs esp_mesh_disconnect() and esp_mesh_connect().
5. disconnect from parent/router when the DSSS channel in received beacon is different from the home channel.
6. remove nvs task to release 3k bytes memory.
Having two different spinlocks is problematic due to possibly
different order in which the locks will be taken. Changing the order
would require significant restructuring of kernel code which is
undesirable.
An additional place where taking xTickCountMutex was needed was in
vApplicationSleep function. Not taking xTickCountMutex resulted in
other CPU sometimes possibly advancing tick count while light sleep
entry/exit was happening. Taking xTickCountMutex in addition to
xTaskQueueMutex has shown a problem that in different code paths,
these two spinlocks could be taken in different order, leading to
(unlikely, but possible) deadlocks.
