New I2C Master driver i2c_master_probe() returning ESP_OK for all addresses (IDFGH-10967) #12159
Comments
github-actions
bot
changed the title
|
I noticed this issue already, will find time to fix it. |
|
BTW, you can use i2c_tool in example for probe an I2C device |
|
Probably not in our case, the probe functionality is used in our firmware to dynamically discover the devices present, and we are trying to migrate to the new master driver.
Unless I can use the older I2C APIs with the new driver, which I doubt…
If you can please fix the issue ASAP, much appreciated
On 23/08/30, 10:59, "Simon_Cao" ***@***.******@***.***>> wrote:
BTW, you can use i2c_tool in example for probe an I2C device
—
Reply to this email directly, view it on GitHub<#12159 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAYT7GET5A2PIDCFHNDCKYLXX36GNANCNFSM6AAAAAA4EC47ZU>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
@mythbuster5 Any chance we can get some focus on this bug, sounds like it is known and simple. We would really like to try the new I2C Master driver but due to our I2C device auto discovery process using the probe functionality, our testing has been very restricted. Even if you can send me a patch to get it going, we will be able to stress test it on a wide range of platform and sensors. Thanks André |
|
@ammaree I have already merged changes in internal repo (it needs time to update on github). Let's see if it doesnt sync on github monday. I will append a patch here. |
|
@ammaree In case you are really in a hurry, apply the patch that @mythbuster5 merged on master: |
|
I have tried with the patches but now it hangs up earlier, around lines 882 or 883 of i2c_new_master_bus() Previously my call to i2c_new_master_bus() passed perfectly and it only crashed later at the calls to i2c_master_probe() I am happy to test more patches since I am under pressure to get the I2C fixed. Thanks |
|
Can I see how did you call the functions? I want to see the function calling order. Line 882 and 883 is easy inline functions, code shouldn't fail there. BTW, I want to see your log error as well. |
|
this is closed by commit command directly, feel free to reopen if you still have any problems |
|
I am not currently next to the device to enable a higher level of logging (currently INFO) but when tested last night no error messages were shown, device just hung as the lines indicated, never returned in spite of waiting ~15minutes Entry point for the I2C device discovery is at halI2C_DevicesDiscover (). |
|
@o-marshmallow @mythbuster5 ` 1.291: #0 wifi wifi clear blacklist 1.383: #0 wifi wifi connect status 0 -> 0 1.395: #0 wifi wifi inter_channel_timeout: arg=0x00000000, ss_state=0x1 2.761: #0 wifi wifi updated connection retries to 3 2.787: #0 wifi wifi updated connection retries to 3 3.599: #0 wifi wifi updated connection retries to 3 3.702: #0 wifi wifi set max rate: from <rate=130, phy=3, sig=0> to <rate=144, phy=3 sig=0> 3.804: #0 wifi wifi profile match: ss_state=0x7 3.907: #0 wifi wifi profile match: ss_state=0x7 5.776: #0 wifi wifi Send sta connected event |
|
Oh, I reproduce the issue, the root cause is that one interrupt is lacked. The fix is on the way |
|
I am very glad you found it. I have spent 4 days trying to make this work, gave up around 01h00 this morning. |
|
Feel very sorry and apologize for this.Try with this please~ @ammaree |
|
I have up to now applied the patch manually, editing line by line.
What would be the correct git command to apply the patch automatically?
On 23/09/05, 11:23, "Simon_Cao" ***@***.******@***.***>> wrote:
Feel very sorry and apologize for this.Try with this please~
i2c_master.txt<https://github.com/espressif/esp-idf/files/12521375/i2c_master.txt>
—
Reply to this email directly, view it on GitHub<#12159 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAYT7GBDUJOMKKEQAYJVFK3XY3VQDANCNFSM6AAAAAA4EC47ZU>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Don't worry, very small, applied.. |
|
i2c_master.txt |
|
It now runs through, does not hang anymore, but ... |
|
let me check |
|
Then it's very weird. It works well on my board. I can show you the very simple testing code and result. (I connect two devices on one bus)
|
|
What you can do maybe check on a logic analyzer and see if the sending address is exist, there should be an |
|
Don't have logic analyser or scope on hand but...
Old driver output: New driver output: And this situation is 100% consistent |
|
Which esp chip are you using. I tried esp32c3 and esp32 on my side. Both of them work pretty well.. |
|
ESP32 Rev 3
On 23/09/06, 04:33, "Simon_Cao" ***@***.******@***.***>> wrote:
Which esp chip are you using. I tried esp32c3 and esp32 on my side. Both of them work pretty well..
—
Reply to this email directly, view it on GitHub<#12159 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAYT7GDI7UQO6P7TKXGUYA3XY7OHHANCNFSM6AAAAAA4EC47ZU>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
yeah, |
gpio_set_pull_mode(GPIO_NUM_4,GPIO_PULLUP_ONLY);
gpio_set_pull_mode(GPIO_NUM_5,GPIO_PULLUP_ONLY);I also have these codes above . |
|
@R0nyx Actually, I can run the "i2c tools" in the examples normally . I have checked my codes and it ,cannot find where the problem is. |
|
@puppy112358 i've attached how my current i2c_master.c |
|
@R0nyx No, it did not change anything. |
|
@puppy112358 are you sure that your hardware setup is connected correctly? |
|
@R0nyx Other part of my project can run normally. I think my hardware setup is connected correctly maybe. |
|
@puppy112358 I'm new to development myself so i cannot provide you with a good answer |
Actually , if the connection is wrong, it should return NOT FOUND instead every address is ESP_OK. @R0nyx |
|
@puppy112358 I know, but if you are using the same library as i do and follow espressif implementation guide, then you shouldn't be having any issues. |
I have add these codes , while it did not change anything ... |
|
@puppy112358 then code wise it seems like you are doing everything correctly. I would make sure your lines are pulled high with multi meter or logic analyzer. Also check if Esp32 SDA pin is connected to your slave SDA pin and the same for SCL. Oh and try this before setting pin configurations: |
Oh ,the pins are not pulled high as I use the multi meter! but I have config the pin as it should be . |
|
@puppy112358 Try using the gpio_reset_pin() command before setting pins to high: |
Should I add other codes to pull up the pins? |
|
|
|
|
@puppy112358 does it work then? |
|
No ,,,,how wired!!! |
|
But are the SDA and SCL pins High when you meassure them now? |
no, they are not high . |
|
it might be a dumb idea but try and see if the pin is still not high: |
|
I am not an I2C expert but have the new I2C master working on at least 7 different hardware platforms and with a total of 18 different I2C devices attached to the various platforms. In all our configurations the initialisation is as follows: We are not doing any other GPIO pin initialisation related to the I2C SD/SCL pins, everything is done within the i2c_new_master_bus() API. To add a specific device, the following is all that is required. |
|
Hi there, I'm also running in the same issue as previously described here. I'm running on ESP-ADF 5.2.1, a devkit-C V4 with a ESP32-WROVER-E, and compiling my code in cpp. i2c_master_bus_config_t i2c_bus_config;
i2c_bus_config.clk_source = I2C_CLK_SRC_DEFAULT;
i2c_bus_config.i2c_port = I2C_NUM_0;
i2c_bus_config.scl_io_num = gpio_num_t::GPIO_NUM_23;
i2c_bus_config.sda_io_num = gpio_num_t::GPIO_NUM_18;
i2c_bus_config.intr_priority = 0;
i2c_bus_config.trans_queue_depth = 10;
i2c_bus_config.glitch_ignore_cnt = 7;
i2c_bus_config.flags.enable_internal_pullup = 1;
i2c_master_bus_handle_t bus_handle;
ESP_ERROR_CHECK(i2c_new_master_bus(&i2c_bus_config, &bus_handle));
esp_err_t ret;
uint8_t i;
for (i = 0x01; i < 0x90; i++)
{
ret = i2c_master_probe(bus_handle, i, 100);
if (ret == ESP_OK)
{
printf("bingo! addr: %x\n", i);
}
}In the logs I have the following, so I would suppose that the GPIO pins are set up properly. I also verified with a voltmeter on pin 18 and 23 that they were at 3.3V. Theoretically I should only find a device on addresses 0x28 and 0x50, but all address return an ESP_OK (0). The devices on are both detected and interfaced using external tools, so we know that it is active. Does anybody have an idea why a pin at 3.3V would return an ESP_OK on a probe on all addresses? EDIT : To double check if Cpp compiling was the issue, I modified my code compile using C and I get the same result. Here is the code used and the log outputCode : // SPDX-FileCopyrightText: 2023 Carter Nelson for Adafruit Industries
//
// SPDX-License-Identifier: MIT
// --------------------------------------
// i2c_scanner
//
// Modified from https://playground.arduino.cc/Main/I2cScanner/
// --------------------------------------
#include <Arduino.h>
#include <Wire.h>
#define I2C_SDA 18
#define I2C_SCL 23
void setup()
{
Wire.begin(I2C_SDA, I2C_SCL);
Serial.begin(115200);
while (!Serial)
delay(10);
Serial.println("\nI2C Scanner");
}
void loop()
{
byte error, address;
int nDevices;
Serial.println("Scanning...");
nDevices = 0;
for (address = 1; address < 127; address++)
{
// The i2c_scanner uses the return value of
// the Write.endTransmisstion to see if
// a device did acknowledge to the address.
Wire.beginTransmission(address);
error = Wire.endTransmission();
if (error == 0)
{
Serial.print("I2C device found at address 0x");
if (address < 16)
Serial.print("0");
Serial.print(address, HEX);
Serial.println(" !");
nDevices++;
}
else if (error == 4)
{
Serial.print("Unknown error at address 0x");
if (address < 16)
Serial.print("0");
Serial.println(address, HEX);
}
}
if (nDevices == 0)
Serial.println("No I2C devices found\n");
else
Serial.println("done\n");
delay(5000); // wait 5 seconds for next scan
}Log : EDIT 4 : As a workaround I have switched to the older i2c.h drivers and the devices are detected. |
Exactly same to me! on ESP32 Wroom |
|
Is this fixed or not? |
|
Considering there has been no activity since we both reported the issue perhaps not. @mythbuster5, would it be possible to reopen this issue? |
|
I think if there still problem, you need to update the idf version. Because we already have automatically test toward this in internal CI https://github.com/espressif/esp-idf/blob/master/components/esp_driver_i2c/test_apps/i2c_test_apps/main/test_i2c_common.c#L150 |
|
Thanks for the clarification, I'll update to 5.2.2. |
Answers checklist.
IDF version.
v5.2-dev-2383-g82cceabc6e
Operating System used.
macOS
How did you build your project?
Eclipse IDE
If you are using Windows, please specify command line type.
None
Development Kit.
Custom hardware
Power Supply used.
External 5V
What is the expected behavior?
API to return ESP_OK only when a device is found on a bus.
What is the actual behavior?
Returns ESP_OK for all addresses between 0x08 and 0x77
Steps to reproduce.
static int halI2C_CheckAddress(u8_t eCh, u16_t Addr) {
#if (buildI2C_MASTER_DRIVER == 0)
u8_t i2cBuf[I2C_LINK_RECOMMENDED_SIZE(1)];
i2c_cmd_handle_t i2cCmd = i2c_cmd_link_create_static(i2cBuf, sizeof(i2cBuf));
i2c_master_start(i2cCmd);
i2c_master_write_byte(i2cCmd, (Addr << 1) | I2C_MASTER_WRITE, ACK_CHECK_EN);
i2c_master_stop(i2cCmd);
int iRV = i2c_master_cmd_begin(eCh, i2cCmd, 10);
i2c_cmd_link_delete_static(i2cCmd);
return iRV;
}
int halI2C_CountDevices(u8_t eCh) {
u8_t DevCount = 0;
for (u16_t Addr = I2C_LOWEST_ADDR; Addr < I2C_TENBIT_ADDRESS; ++Addr) {
if (halI2C_CheckAddress(eCh, Addr) == ESP_OK) ++DevCount;
}
return DevCount;
}
Debug Logs.
No response
More Information.
No response
The text was updated successfully, but these errors were encountered: