Thanks for the answer Jesus.
I've been looking into the code in I2C_MASTER_lStartTransmitPolling() and thought about a solution:
In the direct Mode you must poll on the TBIF flag, after that you can evaluate NACK and ACK (not while loop on ACK-Flag but on TBIF). If ACK=1 continue with the remaining Data. If NACK=1 you must return and not continue with the Data (possibly flush fifo?).
The enum I2C_MASTER_STATUS should have an I2C_MASTER_STATUS_ACK, I2C_MASTER_STATUS_NACK, instead of success and failure - the caller must be able to discern if transfer worked or not because of the device not answering OR if there was another error like a blocked bus, arbitration lost etc.
This bug occurs numerous times throughout i2c_master.c, basically at every comment /* wait for ACK */ (also in DMA mode! Only Interrupt Mode seems not to block).
Generally the usage of while in your drivers without a timeout is a problem throughout most of your DAVE APP drivers - you should definitly add those in the longterm.
I've been looking into the code in I2C_MASTER_lStartTransmitPolling() and thought about a solution:
In the direct Mode you must poll on the TBIF flag, after that you can evaluate NACK and ACK (not while loop on ACK-Flag but on TBIF). If ACK=1 continue with the remaining Data. If NACK=1 you must return and not continue with the Data (possibly flush fifo?).
The enum I2C_MASTER_STATUS should have an I2C_MASTER_STATUS_ACK, I2C_MASTER_STATUS_NACK, instead of success and failure - the caller must be able to discern if transfer worked or not because of the device not answering OR if there was another error like a blocked bus, arbitration lost etc.
This bug occurs numerous times throughout i2c_master.c, basically at every comment /* wait for ACK */ (also in DMA mode! Only Interrupt Mode seems not to block).
Generally the usage of while in your drivers without a timeout is a problem throughout most of your DAVE APP drivers - you should definitly add those in the longterm.