Tool/software: TI C/C++ Compiler
Hello,
I have a problem with receiving only one byte after a repeated start sequence. The easiest way to explain this is by example:
Working case, with STOP/START sequence
- Send START / W - set UCTXSTT and UCTR in UCBxCTLW0
- Send byte no 1
- Send byte no 2
- Send stop UCBxCTLW0 |= UCTXSTP
- Change mode to reading - clear UCTR in UCBxCTLW0
- Send START / R - set UCTXSTT and UCTXSTP in UCBxCTLW0
- Receive only one byte, after which MCU send NACK and STOP.
Non working case with repeated start sequence:
- Send START / W - set UCTXSTT and UCTR in UCBxCTLW0
- Send byte no 1
- Send byte no 2
- Change mode to reading - clear UCTR in UCBxCTLW0
- Send START / R - UCTXSTT and UCTXSTP in UCBxCTLW0
- Receive two bytes: the first one is ACKed and the second one is waiting for my move
I found a workaround for this problem, I am using UCASTPx mode 10b, which allows for automatic STOP generation after sending/receivng n-bytes. It looks like this:
- UCBxTBCNT = 0 (set counter to zero, what blocks auto STOP generation)
- Send START / W - set UCTXSTT and UCTR in UCBxCTLW0
- Send byte no 1
- Send byte no 2
- Change mode to reading - clear UCTR in UCBxCTLW0
- UCBxTBCNT = 0x01 ( set counter to 1 byte)
- Send START / R - UCTXSTT in UCBxCTLW0
- Receive only one byte, after which MCU send NACK and STOP.
My problems:
1. Why I2C doesn't work properly if i set UCTXSTT and UCTXSTP in repeated start mode?
2. The documentation contains a stipulation that modification of UCTBCNTx is possible only if UCSWRST is equal 1. I can not meet this condition because it will disable I2C and release SCL line, and repeated start become impossible. Do I have to worry about this stipulation?
Best regards,
Mateusz