1. All the registers of touch sensor 8 and 9 are mismatched except the ‘dac’ field in touch register of RTC IO
2. To swap the index for sensor 8 and 9 in APIs.
Reported from github:
https://github.com/espressif/esp-idf/issues/1219https://github.com/espressif/esp-idf/issues/1202
After providing a simple code to digital team, they confirmed that this is a hardware bug.
Root cause:
The fifo reset signal is incorrectly connected
If we want to reset tx fifo of UART2, we have to set txfifo_rst bit of both UART1 and UART2
If we want to reset rx fifo of UART2, we have to set rxfifo_rst bit of both UART1 and UART2
Workaround:
we don't use fifo rst bit in driver.
Documentation:
Digital team would update TRM and give more explanation about this issue.
1. move settings of WIFI_CLK_EN_REG for bluetooth into controller init/deinit APIs
2. modify the bit mask used in phy_rf init/deinit to use WIFI-BT shared bits
append adc support and api
- esp_err_t adc2_config_width(adc_bits_width_t width_bit);
- esp_err_t adc2_config_channel_atten(adc2_channel_t channel, adc_atten_t atten);
- int adc2_get_voltage(adc2_channel_t channel);
Reported from:
https://github.com/espressif/esp-idf/issues/703https://github.com/espressif/esp-idf/issues/917
In uart driver we didn't change the default value of tx idle num, so there would be a delay after tx FIFO is empty.
1. Add API to set tx idle interval before next data transmission. (The UART hardware can add an interval after tx FIFO is empty).
2. Set default tx idle interval to zero.
3. Add hardware disable in uart driver delete function.
Reported from different sources from github or bbs:
https://github.com/espressif/esp-idf/issues/680https://github.com/espressif/esp-idf/issues/922
We tested reading several sensor or other I2C slave devices, if the power and SDA/SCL wires are in proper condition, everything works find with reading the slave.
If we remove the power supply for the slave during I2C is reading, or directly connect SDA or SCL to ground, this would cause the I2C FSM get stuck in wrong state, all we can do is the reset the I2C hardware in this case.
After this commit, no matter whether the power supply of I2C slave is removed or SDA / SCL are shorted to ground, the driver can recover from wrong state.
We are not sure whether this the save issue with the reported one yet, but to make the driver more robust.
Further information:
1. For I2C master mode, we have tested different situations, e.g., to short the SDA/SCL directly to GND/VCC, to short the SDA to SCL, to un-plug the slave device, to power off the slave device. Under all of those situations, this version of driver can recover and keep working.
2. Some slave device will die by accident and keep the SDA in low level, in this case, master should send several clock to make the slave release the bus.
3. Slave mode of ESP32 might also get in wrong state that held the SDA low, in this case, master device could send a stop signal to make esp32 slave release the bus.
Modifications:
1. Disable I2C_MASTER_TRAN_COMP interrupt to void extra interrupt.
2. Disable un-used timeout interrupt for slave.
3. Add bus reset if error detected for master mode.
4. Add bus clear if SDA level is low when error detected.
5. Modify the argument type of i2c_set_pin.
6. add API to set timeout value
7. add parameter check for timing APIs
