*edit: by repeated start, I mean a second start, as in a second SEN, *not* RSEN. Also, the post above uses an RSEN condition between writing the slave address + register, and then writing the slave address and the value of the data to read - your MPR121 uses a repeated start*, like the sensor I'm using.
#Point blank error 0x82 series#
May work with 24F series instead of 32MX, give it a go. <- that post helped me out a lot, as I could actually see the flags being set / monitored inside the I2C registers. I don't know for sure what any of those I2C functions are doing *inside* the called code. Some stuff "looks" commented but I assume wasn't. I have to manually interleave blank lines when I post mine, might help you there. (Noticed you were using 7bit address but I'll leave it in anyway)
IdleI2C1() //Wait to complete GETS STUCK AT THIS LINE MasterWriteI2C1((MPR121Address << 1) | 1) //transmit read command
MasterWriteI2C1( 0x00) // send out register address MasterWriteI2C1( dat) // send out the data for that register MasterWriteI2C1( reg) // send out the internal register number While ( I2C1CONbits.RSEN ) // wait until re-start condition is over RestartI2C1() //Send a Restart even though, at end, a stop will follow restart IdleI2C1() // Ensure I2C module is idle assumes that i2c module is already active with the MPR121 Void MPR121WriteRegister ( unsigned char reg, unsigned char dat)
_builtin_btg((unsigned int *)&LATA, 6) WHY IS THIS HERE? at this point, i2c system is still active but any device can be called MPR121WriteRegister( 0x7F, 0x9F) // was 8C Initialization follows = register, contents PORTE = 0x0200 // switches on RED LED - NOTE THIS NEVER HAPPENS EVEN WHEN I USE AN ADDR THAT DOES NOT EXIST!!! if 1 then slave has not acknowledge the data. MasterWriteI2C1((MPR121Address << 1) | 0) //transmit write command OpenI2C1( I2C_ON & I2C_IDLE_CON & I2C_IPMI_DIS & I2C_7BIT_ADD & I2C_SLW_EN, I2C_BRG ) GetKeyBytes() // call function that will read values into key1/2 #define addrLCD() readLCD( LCDCMD) & 0x7F #define busyLCD() readLCD( LCDCMD) & 0x80 // NOT USING BUSY SIGNAL FROM LCD - IT'S BROKEN Return( PMDATA) // read the status register PMADDR = addr // select the command addressĭummy = PMDATA // initiate a read cycle, dummy read While( PMMODEbits.BUSY) // wait for PMP to be available char MasterputsI2C1(unsigned char *) library function. The data to be written should be end with '\0' if using Void MPR121WriteRegister ( unsigned char, unsigned char ) Void GetKeyBytes() /* declare the function */ Unsigned char key2 // set space for variables #define MPR121AddressRd 0xB7 /* Slave address + Rd for MPR121 or 5B or 4D ? */ #define MPR121AddressWr 0xB6 /* Slave address + Wr for MPR121 or 5B or 4D ? */ #define Fcy (Fosc*4/2) // w.PLL (Instruction Per Second) #define USE_AND_OR // To enable AND_OR mask setting for I2C.
#Point blank error 0x82 code#
** Previous version (vn b) contained non-working i2c code and was abandoned ** include a delay for every write to LCD - this is also achieved by adding for loop ** Working version with LCDwait commented out and minimal delays, works fine as long as we Some posters here have commented that I should not rely on OpenI2C1 to set up i2c on a PIC24 but I'm dealing with several possibilities.Īny suggestion on what to use, not to use, code samples include, things to try will be much appreciated. This may be because the MPR121 isn't talking to the PIC but I'm not sure. When I try to read a byte from the MPR121, it seems to get stuck on IdleI2C1() There's a silicon error that suggests that this might be an issue but it's not supposed to apply to anything other than using 10 bit addresses.Ģ. It appears that the PIC thinks that i2c has been ACKed regardless of whether I use an address that does or does not exist - I've scoped the SDA1 line and I can see that when I send out the correct address, it does not get an ACK from my device which seems to point to a hardware error - I have other i2c devices on the same bus so I'll try those too. Using 'if( I2C1STATbits.ACKSTAT )' does not seem to work I read and used all I could find on i2c library stuff to come up with the code below which seems to have the following issues:ġ. I posted about this a while back but I'm still stuck with the same issue.
0 kommentar(er)
