I2C / TWI Master Mode Receive and Nak / Acknowledge

Question

Hello, 
 I am having a problem with an I2C device and reading from it. I start a master mode receive conversation by sending the slave's address and the receive bit set high. The device should then respond by sending a stream of bytes back until I tell it to stop. I tell it to stop by using a high acknowledge. I can continuing reading by using a low acknowledge after each byte. 
 My problem is that I can only receive one byte at a time because I always acknowledge high. Looking at the 21369 hardware reference manual, the acknowledge does not look programmable. At least not in master mode. I see that it might be in Slave mode. 
 If my only solution was to operate in slave mode, how would that work? Could a send out the address byte in Master mode and quickly switch to slave receive before the device starts sending data back? I see this as the only solution and will probably start looking into it more after I finish this post. 
 I attached a picture from the scope to help clarify the problem. 
 Thanks in advance, 
 Glen

EZAutoReply · Accepted Answer

Hi Glen, 
 Apologies for getting back to you late regarding this. Unfortunately, I don't have the similar code for 21369 processor. As far as mapping the TWI interrupt to a programmable interrupt is concerned, the following lines should work for 21369 too: 
 #define TWI_INTERRUPT P0I0|P0I1|P0I2|P0I4 
 ustat1=TWI_INTERRUPT;//mapping TWI interrupt to P0I; 
 dm(PICR0)=ustat1; 
 Hope this helps. Please let me know if you still face any further issues. 
 Thanks, 
 Mitesh)

EZAutoReply · Answer

Hi Glen, 
 Please see my reply below: 
 1) I understand that it is necessary to set the bit set the P14I / DPII bit in the imask register. I can see that in VDSP when I bring up the "Interrupts Registers" window under the Register / Core menu item. This bit seems to be bit 17. Why can I not find this in the Hardware Reference Manual under the bit definitions of the IMASK register. It says bit 17 is reserved. I am using version 1.0 of the 21368 manual. Is there a more recent version? 
 >> Rev 1.0 is the latest version of the manual. It seems to be a mistake in the manual. Bit 17 and Bit 19 can be used to unmask the interrupts P14I and P16I respectively. Thanks for pointing it out. We shall take take the required actions to correct this in the next HRM revision. 
 2) I seem to have captured an impossible scenario. Or at least one that I do not understand. Please see the attached screen shot. When I enter the ISR I read the TWIIRPTL register. If it is zero I break and examine things. It looks like in between the time I read the register and the time I break ( 1 cycle??), the TWIIRPTL register gets a value. How is this happening? What can i do to more properly treat these instances or prevent them altogether? 
 >> I understand that even after placing the instruction to read the DPI_IRPTL register inside the ISR, you get an erroneous interrrupt with TWIIRPTL register's value as "0". I believe, before we can know why the TWIIRPTL register gets a value, we should first debug why the interrupt occured even when TWIIRPTL register was "zero". To know whether a DPI interrupt and a TWI interrupt actually occured, I would suggest you to capture the DPI_IRPTL value inside the ISR and check if bit 4 of this register was set. 
 Thanks, 
 Mitesh

EZAutoReply · Answer

Hi Glen, 
 Apologies for my late response on this. I think there is a little confusion. From the following statement: 
 "To know whether a DPI interrupt and a TWI interrupt actually occured, I would suggest you to capture the DPI_IRPTL value inside the ISR and check if bit 4 of this register was set..", 
 I actually meant to check whether a valid DPI interrupt was actually latched in the DPI_IRPTL register for the erroneous interrupt. From the contents of the r0 when the breakpoint was hit, it looks like there was no TWI interrupt. However, its not clear whether there was actually a DPI interrupt. If yes, its againj not clear whether that was a TWI interrupt. This can become more clear if the DPI_IRPTL register is read in to some other register than R0 e.g. R14. 
 I would also suggest you to map the TWI interrupt to any other programmable interrupt using PICRx register and check if the problem still occurs. 
 Please let us know your findings on these two points. 
 Thanks, 
 Mitesh

Partner Forums

Partner Libraries

I2C / TWI Master Mode Receive and Nak / Acknowledge