-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
i2c emulation bug (QEMU-228) #110
Comments
Debugging from the firmware side - wdt reset comes from the line in i2c_isr_receive_handler() in i2c_master.c in IDF:
The counter part in qemu is esp32_i2c.c function static uint32_t esp32_i2c_get_status_reg(). Making this function always return 0 kinda solves the problem. I don't think this is proper solution and rather nasty hack. I tried to trace the i2c emulation from qemu side but failed. The code is awkward and without any comments. |
No. while(i2c_ll_is_bus_busy(hal->dev)){} is busy loop inside ISR handler in IDF. There is no timeout so firmware waits there indefinitely. |
PR says it was tested writing to emulated display controller. Write works correctly. The reading part is failing to clear status flags. |
Hello 👋 , imo its a ESP-IDF issue. I tried to run the program with the latest version of qemu and ESP-IDF v5.2.1 and i was able to reproduce the bug.
However I am wondering, are we able to control the data sent by the simulated sensor ? Best regards, Romain |
Yes you can control data sent by the sensor. First you need to add option -qmp unix:/tmp/qmp.sock,server,nowait to the qemu args. Then you have to search for emulated i2c device in qemu object hierarchy using scripts/qmp/qom-list -s /tmp/qmp.sock (I personally grep for 'temperature' property as object hierarchy is pretty long). Then you can use qom-set -s /tmp/qmp.sock object.property value to set value returned by the sensor. However there is known bug which allows setting only string properties this way so you need to hack qom-set to send int instead of string. Can't find the patch right now but it is pretty trivial. Python backtrace will guide you. Regarding IDF vs qemu issue. This is qemu issue revealed by IDF. Reading path of i2c emulation incorrectly returns busy status of the bus BUT indefinitely waiting for some flag in ISR is definitely bad practice. |
Checklist
How often does this bug occurs?
always
Expected behavior
Successful communication with virtual i2c device (tmp105).
Actual behavior (suspected bug)
WDT reset
Error logs or terminal output
Steps to reproduce the behavior
Firmware source:
`
#include <stdio.h>
#include <string.h>
#include "freertos/FreeRTOS.h"
#include "driver/i2c_master.h"
#include "esp_log.h"
#include "esp_system.h"
#define I2C_PORT I2C_NUM_0
#define I2C_SCL_IO GPIO_NUM_18
#define I2C_SDA_IO GPIO_NUM_19
const char *TAG = "qemu-i2c";
uint16_t tmp105_temp_raw(i2c_master_dev_handle_t dev_handle)
{
uint8_t txbuf[1] = {0};
uint8_t rxbuf[2] = {0, 0};
i2c_master_transmit_receive(dev_handle, txbuf, sizeof(txbuf), rxbuf, sizeof(rxbuf), -1);
return (rxbuf[0] << 8) | rxbuf[1];
}
void app_main()
{
i2c_master_bus_config_t i2c_mst_config = {
.clk_source = I2C_CLK_SRC_DEFAULT,
.i2c_port = I2C_PORT,
.scl_io_num = I2C_SCL_IO,
.sda_io_num = I2C_SDA_IO,
.glitch_ignore_cnt = 7,
.flags.enable_internal_pullup = true,
};
}
`
Project release version
8.2.0-20240122
System architecture
Intel/AMD 64-bit (modern PC, older Mac)
Operating system
Linux
Operating system version
Ubuntu 20.04
Shell
Bash
Additional context
As can be seen from console logs i2c_master_probe() succeeds but reading from i2c device does not.
The text was updated successfully, but these errors were encountered: