-
Notifications
You must be signed in to change notification settings - Fork 7.4k
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 slave version 2 - ISR not waking task on request, while stretch keeps SDA low (IDFGH-14490) #15259
Comments
Since the attached component above is dependent on other components, it probably is not straightforward to get it working. Here is an example to reproduce, modified from the hello world example, using all necessary code stripped down to the essentials of the component we're making, bundled into a single project. I could create an even more minimal example, but this was the quickest way to demonstrate for me, without writing new code. It uses I tried to strip everything unrelated to the issue, but kept most of my code structure. EDIT: Had to re-upload due to broken zip because I forgot the recursive flag when creating it. |
Thanks I will take an eye on it.. BTW, may you try my example called i2c_slave_network_sensor. I want to know if the example also fails |
Ok, I might know why you encounter this issue. becasue in one i2c write-read transaction, the request and receive event occur very fast. So I think you need to change your code. 1). please create queue at least two item |
I am wondering, if the i2c_slave version 2 writes all bytes into the FIFO when using In my i2c slave component, I implemented a 128-byte memory with varying register sizes. The code checks the size of a register according to a table and returns only bytes up to the maximum size of that register. However, when writing back, I always use the full register size to write, since requested byte-length is unknown in I²C. For a register of size 6, the master could only request 1 byte of the 6 put into FIFO, leaving 5 remaining bytes in the FIFO after the call to Should I clear the FIFO in this?
To clarify, the reason I have a switch-case to begin with, is the fact that I also want to use the queue to send events to the task from another task, not just the ISR. I just haven't gotten to that part yet. |
Ok, sorry, to root cause is queue size indeed, switch-case logic is not that matter, my bad.. As for I don't know whether this is valid for you. |
I mostly looked at this example already when implementing this. The main issue was the queue size, a minor detail easily overlooked. If the FIFO is cleared, than that's completely enough for me. Closing this, since solved. |
Answers checklist.
IDF version.
v5.4.0
Espressif SoC revision.
ESP32-S3 (ESP32-S3FN8) (revision 0.2)
Operating System used.
Linux
How did you build your project?
Command line with idf.py:
idf.py -p /dev/ttyACM0 build flash monitor
If you are using Windows, please specify command line type.
None
Development Kit.
Custom board
Power Supply used.
External 5V
What is the expected behavior?
Receive callback waking the task after sending the corresponding event to the event queue, and the requested data being written back to the master.
What is the actual behavior?
ESP32S3 Controller holds SDA low and causes I²C stretch behavior, since the underlying task dealing with responding is never woken as it waits for the event from the queue.
This means no data reaches the FIFO, causing the stretch behavior.
Steps to reproduce.
TA_lex_i2c_slave.zip
I have attached my full component above. Since it is a bit complicated and related to our proprietary goals, I do not want to go into detail.
But in essence, here are the relevant code parts which I expect to be working, but don't:
I am sending the data from a raspberry pi as master via the following commands:
Debug Logs.
More Information.
I am using I2C slave version 2, and I have a task handling both receive and request.
Receiving data works fine and can be stored. The handling task is woken with the event.
Requesting data always fails, with SDA held low by the controller (I²C stretch behavior I believe) after the first attempt.
I have recorded the interaction on a logic analyzer:
I am still unaware as to why
i2cset
gives me a write failed error, despite the acknowledgment by the controller.However, my monitor log shows a successful operation, until the moment of the request:
The text was updated successfully, but these errors were encountered: