Hello Ryan, Thank you very much for your response and feedback. You suggestions provides a very good starting point to help debug my code. Just to dive deeper into what you have mentioned, I do have a couple follow up questions that I hope can help clear up my understanding. 1) When setting the UCASTP_2 for automatic stop conditions, I specify the UCBOTBCNT to be 6 bytes for that's the number of bytes I would be receiving from the Wii nunchuck. However, I only transmit 4 bytes to initialize the device. Therefore, should I not set UCASTP_2 bit altogether and manually send a stop condition every time? 2) For the other things you mentioned, such as register number to read from after initialization, and while loops to make sure the buffer is clear, I might just be ignorant but I don't see it in the example codes msp430fr413x_euscib0_i2c_10.c and msp430fr413x_euscib0_i2c_15.c from MSPWare . Are there other MSPFR4133 examples that can help illustrate these points? Having examples is quite reassuring but if there are none I can attempt to implement them. The actual slave device is the black Wii nunchuck and I have SDA and SCL connected to P5.2/UCB0SDA and P5.3/UCB0SCL respectively with 10k pull up resistors. I am also using the 3.3V and gnd from the launchpad to power and ground the nunchuck. As for where the code hangs I now believe it is as you described: "You also never write the register number that you want to read from after initialization, on some slave devices it will continue to increment the register address until an overflow or invalid address occurs." Since it seems that when I first try to run the code after reset it enters the nunchuck_read() function but fails to trigger the USCI_I2C_UCRXIFG0 interrupt flag. (Currently it actually enters the USCI_I2C_UCTXIFG0 subroutine before it eventually hangs) I will attempt to correct my code with the changes you described but if you have some insights to the couple questions above it will be a tremendous help. Thanks and best regards, Jerry Leung
↧