X-Ryl669
commented
2 years ago Few progress here:
I have similar issue without using a static buffer (typically, by using i2c_cmd_link_create) so it's not related to the way the command link handle is created.
Also, by merging the first 2 writes in a single write, that is, by doing:
uint8 skipWrite[2] = {(uint8)((devAddr << 1) | I2C_MASTER_WRITE), 0xFA };
if (!FilterError(i2c_master_write(cmd, skipWrite, 2, true))) return false;Then no timeout error is reported, but the second read returns 0xFF (that's worse, IMHO, since it feels like it worked but returned garbish).
Also, by reading the I2C code, there's a race condition going on here in i2c_master_cmd_begin_static:
i2c_hal_write_txfifo(&(i2c_context[i2c_num].hal), write_pr, fifo_fill);
i2c_hal_write_cmd_reg(&(i2c_context[i2c_num].hal), hw_cmd, p_i2c->cmd_idx);
i2c_hal_write_cmd_reg(&(i2c_context[i2c_num].hal), hw_end_cmd, p_i2c->cmd_idx + 1);
i2c_hal_enable_master_tx_it(&(i2c_context[i2c_num].hal));
p_i2c->cmd_idx = 0;
if (i2c_cmd_is_single_byte(cmd) || cmd->total_bytes == cmd->bytes_used) {
p_i2c->cmd_link.head = p_i2c->cmd_link.head->next;
if(p_i2c->cmd_link.head) {
p_i2c->cmd_link.head->cmd.bytes_used = 0;
}
}
p_i2c->status = I2C_STATUS_WRITE;Here you enable the hardware interrupt (line 1421), but you later modify the p_i2c->cmd_link.head. So if the CPU reach line 1421 (enable_master_tx_it), and the interrupt fires, it'll call the interrupt handler, that'll, in turn, call i2c_master_cmd_begin_static (so you're re-entering this function before the effect on the linked list is applied and it's wrong).
Typical example, for this corruption:
- You have a sequence of "read / write / read" command and are actually processing the write command.
- The cpu process to line 1424 (
cmd_link.head = head->next) but notbytes_used = 0and also not thestatus = WRITEline - I2C interrupt triggers (cpu enters
i2c_isr_handler_default) - Write event is processed, it calls back
i2c_master_cmd_begin_static - Because the status wasn't updated yet, the line 1354 that read
if (p_i2c->cmd_link.head != NULL && p_i2c->status == I2C_STATUS_READ) {pass the test (the previous operation was a read, and the link head isn't NULL). It shouldn't pass this test, since we are executing a write not a read.
- Then, the code tries to copy the I2C's read buffer while it was executing a write command
I didn't follow what happens next, but it explains why I'm seeing garbage in the read buffer.
The same problem happens for the read operation but the race window is shorter, since the code is doing the status = READ part just after enabling the interrupt.
Here, there isn't any write of the register address, and no read whatsoever. In fact, it's even worse, since nothing's said it has failed. 
o-marshmallow
Answers checklist.
IDF version.
master
Operating System used.
macOS
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
No response
Development Kit.
ESP32 WROVER
Power Supply used.
USB
What is the expected behavior?
I'm creating a static i2c_cmd_buffer where I'm preparing a transaction with 2 successive reads, like this:
What is the actual behavior?
If there's only one read, the above code works. But if there are multiple read (like above) it fails with timeout, even with the stop part.
If I create 2 cmd link, it works. But I want to create a complete transaction with 2 read and (re)execute it whenever required. What's the purpose of
I2C_LINK_RECOMMENDED_SIZEif it only support one transaction only ?As a side note, the documentation state:
but the actual code does this in i2c_master_write_read_device does this:
(That's
I2C_LINK_RECOMMENDED_SIZE(1)and not 2)Steps to reproduce.
Please copy the above (simple) code and connect on any I2C device where you can read 2 register with a 8 bit address.
Debug Logs.
More Information.
No response