Hello Toby, The example should be correct and has been tested to work. Setting up the USIPE settings in USICTL0 should set your pins up correctly for you. The USI modules will ignore the P1DIR setting when engaged. The 0xFF line is to set the other pins on Port 1 into an initialized low power state. You can check for this by looking in Register view in CCS while debugging and making sure the registers match up to Table 17 in the datasheet. The example should work as is, but for added piece of mind, you can add the correct P1SEL and P1SEL2 settings to ensure I2C pins are set correctly. Do you have a logic analyzer shot of the I2C lines so we can see what communication is on the lines? An O-scope with logic analyzer abilities would work as well. Have you also tried debugging the slave side by adding a breakpoint within the I2C ISR? Also, with the USI being very manual when it comes to communications protocols, there could be a mix-up on the perceived slave address here. Depending on how your master handles the input/output of the slave address. To break this down further, in I2C the slave address is shifted to the left by one bit in order to account for the Read/Write bit. Depending on how this last bit is handled on the master or slave side, your actual slave address could be shifted. For example, if looking at the I2C lines and you see the address packet show 0x48, on the slave side this would be a Read command of slave address 0x24. (0x49 would be write to 0x24). If your slave does have an address of 0x48, then the I2C lines would show 0x90 for a Read command. What makes this confusing is the variable SLV_Addr in the USI example has to take in account the R/W bit. So for an actual slave address of 0x48, SLV_Addr must equal 0x90 (0x48 << 1 ). In our newer modules that do I2C (USCI, eUSCI) you place in a register the actual Slave address (0x48 in this case) and the part takes care of the R/W bit.
↧