A couple of typos referencing tx_ring_buf when rx_ring_buf, slv_tx_mux
instead of slv_rx_mux.
Also, I2C_ENTER_CRITICAL()/I2C_EXIT_CRITICAL() usage was not consistent.
Only some of the _set_ functions had them. Most of the _get_ function
had them? It is my understanding that they should be wrapped around
writes, not reads? (I think we still need the lock for reading pairs of consistent values)
Also, the ticks_to_wait timeout handling in i2c_master_cmd_begin() would
not handle integer rollover correctly.
Merges https://github.com/espressif/esp-idf/pull/1180
Reported from github:
https://github.com/espressif/esp-idf/issues/1312https://github.com/espressif/esp-idf/issues/1193
Issues:
1. We used to use event group in the driver, which would cause:
a. longer operation time since the event group are based on FreeRTOS timer.
b. Operation fails if the timer queue is not long enough.
2. There might be some issue with event group, we will still try to provide a small test code in other branch.
modification:
1. use queue instead of event-bit for internal commands
2. use queue overwrite for cmd_done event
Previously SDSPI host driver would rely on retry count when waiting for
the card to read or write data. This caused different timeout times
depending on CPU frequency and card clock frequency. In practice, card
performance does not depend on these two factors.
This change uses timeout_ms field of sdmmc_command_t introduced
previously for SDMMC host.
Fixes https://esp32.com/viewtopic.php?f=2&t=3440&p=16037 and similar
issues related to SDSPI timeouts.
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
