The attached test program and logic analyzer displays shows that the function twi_master_transfer() returns to the calling program before the transfer is complete, if TWI_hw_master.c is used. Specifically, it returns before the STOP code has been transmitted. If the calling program makes another call to this function, the STOP code is never sent. The problem does not occur with the software version of the TWI interface: TWI_sw_master.c
In the attached images, the green dots are START codes, and the red dots are STOP codes.
Reviewing TWI_SW_no_extra_delay.jpg , the pulse on Diag 4 shows that the return from twi_master_transfer() occurs after the STOP has been sent. This is line 40 of the test program.
Reviewing TWI_HW_no_extra_delay.jpg (the only change is replacing the TWI_sw_master.c with TWI_hw_master.c) the same pulse on Diag 4 shows that twi_master_transfer() has returned before the STOP has been sent. The following call to twi_master_transfer() on line 52 is reached before the STOP occurs, and its start then looks like a RepeatedStart , which is incorrect.
Adding an additional delay of 35 us (could be less, but I didn't try and figure out the minimum) after line 40 , is shown in TWI_HW_with_extra_delay.jpg . This shows a stretched pulse on Diag 4 , and the STOP now occurs correctly.
It looks like the code at line 158 in TWI_hw_master.c is where the problem is. (see below, it is at line 81 per Hung Bui's response)
Could someone please confirm this bug, or correct me if I have not understood something. Thanks.
