You're likely correct about the FIFO being full or blocked. Does that cause a write to data_cmd to hang?
If so, is there a race condition like this:
1) Ensure that i2c->hw->raw_intr_stat & I2C_IC_RAW_INTR_STAT_TX_ABRT_BITS == 0
2) (a previous, now-in-flight transaction aborts, disabling the FIFO)
3) i2c->hw->data_cmd = my_command
4) eternal sadness because step 3 hangs forever
?
Once I put in better error-checking, I found that my first transaction is failing with abort reason 0x8 (target ACK'd address but not data).
Since I was failing to check and clear the abort, it locked the FIFO. The abort only happens on the first transaction, perhaps because the device is not ready yet.
I'm still trying to learn if I can safely stuff the FIFO with a few transactions to the same target (understanding that an abort will hork everything in the queue).
If so, is there a race condition like this:
1) Ensure that i2c->hw->raw_intr_stat & I2C_IC_RAW_INTR_STAT_TX_ABRT_BITS == 0
2) (a previous, now-in-flight transaction aborts, disabling the FIFO)
3) i2c->hw->data_cmd = my_command
4) eternal sadness because step 3 hangs forever
?
Once I put in better error-checking, I found that my first transaction is failing with abort reason 0x8 (target ACK'd address but not data).
Since I was failing to check and clear the abort, it locked the FIFO. The abort only happens on the first transaction, perhaps because the device is not ready yet.
I'm still trying to learn if I can safely stuff the FIFO with a few transactions to the same target (understanding that an abort will hork everything in the queue).
Statistics: Posted by Eric Buddington — Wed Apr 17, 2024 5:56 pm