-
Notifications
You must be signed in to change notification settings - Fork 7.2k
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 Master regression (IDFGH-12542) #13547
Comments
@mythbuster5 guess this would be for your attention |
@ammaree Sorry by this. We have a testing here tests this similar usage https://github.com/espressif/esp-idf/blob/master/examples/peripherals/i2c/i2c_tools/main/cmd_i2ctools.c#L118 but it doesn't report anything wrong
May I check your code and check in which case this regression will happen? |
Seeing from log, it might not be probe interface? Is it possible to be _transmit ? If so, what about change |
|
Only 2 I2C devices in this specific config, DS2482 and DS2482 at addresses 0x18 and 0x19 The errors occur before any _transmit function in my code.
|
Haven't reproduced currently🤨. Mine code is very simple. And quite as same as yours I think?
So...(1) Could you please use my code under esp-idf environment and check whether it works or not. Actually |
|
Checked one more time. Still doesn't reproduce the issue. Poke me if more clue has been found~~ |
Have tested using i2c_tools example, works. Will test further |
I have made some progress. The problem starts with
With this API call removed the error message The DS2484 device at address 0x18 is identified correctly but identifying the DS2482-800 at 0x19 causes the following 2 error messages: So, with the I2C_GENCALL_RESET_WRITE https://www.i2c-bus.org/addressing/general-call-address/ removed we are a step forward, but we need to fix this problem and try determine the cause of the other 2 error messages. Please note: In spite of the 2 error messages the DS2482-800 device seems to operate correctly. |
@mythbuster5 Can we please get 8f84ab3 and the other recent changes merged into EDIT: I see the changes just got pushed to |
I can confirm that: a) writing to I2C address 0x00 (General call) with data 0x06 (RESET) is definitely a problem, result in NACK error message as well as the device discovery failing. See https://www.nxp.com/docs/en/user-guide/UM10204.pdf section 3.1.14 for more info. b) the other 2 error messages only seem to occur when a DS2482-800 device is being used. The actual device address seems to be irrelevant, and the errors do not occur with the (very similar) DS2482-100/101 nor the DS2484 devices. |
Thanks for this message. I will do more testing~ |
I saw there is a sentence for 0x00+0x60 As for your issue title |
Have added the flag and it does take the error message away. Maybe the name But what I think should be looked at (and corrected) is the fact this this error Lastly, the new It might also be able to help once errors with specific devices are discovered after having been added to the bus, without having to remove and re-add the device from the I2C bus. |
Thanks for that much useful information. For As for |
Not sure I agree on the cause here. With the General Call Reset commented out these errors still occur 100% of the time on the DS2482-800 devices, not the -100/101 nor the DS2484 devices. These errors are as a result of normal read and/or write operations on the DS2482-800 device specifically. Have just done a test and changed the scp_wait_ms from 2000 to 10000 and the error messages disappeared. Maybe the default has to be increased, alternatively a get/set API to override selectively? |
Apologies, ignore last message. I will comment once the fix you are working on has been tested. |
This got closed based on commit above. Feel free to poke me if there is still something else. |
Thanks, will do |
OK, have tested the fix on devices with DS2482. I have reverted the After the process the DS2482 seem to be working so my thought is that the functionality has been restore similar to what was working on the old I2C driver, but with new error messages.
|
Well. Firstly, usually when a add a flag, i try to keep Secondly, I understand your concern。 LIke probe interface, it depends on nack but I didn't pring nack error log because it's expected. But for transmit, nack is unexpected for most of time. As a driver, pretty hard to know it is expected or not. Thirdly. yes I agree the log now it too much. But they are log errors indeed. I'm now considering to make them clearer Finally. I'm not very clear with this question. As I said before, we check Have a good day and thanks for your opinions~ |
Answers checklist.
IDF version.
v5.3-dev-3220-g9c99a385ad
Espressif SoC revision.
ESP32 rev 3
Operating System used.
macOS
How did you build your project?
VS Code IDE
If you are using Windows, please specify command line type.
None
Development Kit.
ESP32 WRover Kit
Power Supply used.
USB
What is the expected behavior?
I2C device discovery to work
What is the actual behavior?
I2C device discovery fail on ALL devices
Steps to reproduce.
Our code was working 100% on 6 different platforms configured with 2 ~ 6 different I2C devices per platform.
Using master up to 2024/03/18 all platforms all devices discovered and worked perfectly.
Having come back from leave, with NO changes to the code other than updating to latest master, all platforms fail trying to discover all devices. With the ESP-32 Rover devkit v4.1 test device only the first address (0x08) returns the correct status (ESP_ERR_NOT_FOUND) , no device found, all remaining addresses return ESP_OK
Debug Logs.
More Information.
No response
The text was updated successfully, but these errors were encountered: