View previous topic :: View next topic |
Author |
Message |
davefromnj
Joined: 03 May 2007 Posts: 42
|
i2c_write() fails to give an ACK when it should |
Posted: Fri Jul 11, 2008 8:41 am |
|
|
hello all,
Quick question:
I have an I2c Master PIC18F65J10 and a slave PIC18F44J10.
The i2c communications works properly as long as delays are added such as:
Code: |
unsigned int address_ack = 0;
unsigned int command_ack = 0;
i2c_start();
delay_ms(5);
address_ack = i2c_write(0xA2);
delay_ms(5)
printf("address ack =%d \r\n", address_ack);
command_ack = i2c_write(0x22);
delay_ms(5);
printf("command ack =%d \r\n", command_ack);
i2c_stop();
delay_ms(5);
|
What happens is the master sends the proper sequence of commands and receives a "0" for address_ack and a "0" for command_ack as it should, on power up.
However, if I cause a MCLR reset to the PIC18F44J10, the master now ALWAYS shows a "0" for address_ack and a "1" for command_ack.
I have checked the slave 18F44J10 and IT DOES RECEIVE the 0x22 command, even though the master is not detecting the ACK.
Anyone know why this works properly on power up, but not after a reset occurs on the slave?
I need to make the i2c_comms a little more fault tolerant.
Thanks all, |
|
|
rnielsen
Joined: 23 Sep 2003 Posts: 852 Location: Utah
|
|
Posted: Fri Jul 11, 2008 11:06 am |
|
|
If the slave is responding to it's address and not any command, odds are your code, in the slave, is stuck somewhere. You might need to zero out a variable that tracks where your code is or something like that, after each command sequence, so the slave is ready for a new batch of commands.
Maybe try posting your slave code so we can see what's going on inside.
Ronald |
|
|
davefromnj
Joined: 03 May 2007 Posts: 42
|
Solved! |
Posted: Fri Jul 11, 2008 3:25 pm |
|
|
Hello All,
I was able to solve this problem I making a delay_ms(1000); before the first i2c_start() command gets executed. I still have to experiment to see what is the shortest delay to get consistent results. All the other delays were still fairly short, just a few msec.
Looks like the master unit was sending commands faster than the slave could ACK. |
|
|
|