 |
 |
| View previous topic :: View next topic |
| Author |
Message |
russk2txb
Joined: 30 Mar 2008
Posts: 109
Location: New Jersey
|
| Having trouble implementing I2C Slave |
 Posted: Fri Jan 29, 2016 2:41 pm |
 |
|
Hi all. For the first time I am trying to implement an I2C slave on a PIC18F6723, using the V 5.035 compiler. I cannot find out why, but the slave address is not recognized - there is no ACK generated when the address is sent. I have tried several addresses, even sending address zero (all call?) but the slave never responds. I am using I2C2, pins D6 and D5 or 50 and 51, with SCL on pin D6. I have the ssp2 interrupt enabled but it never interrupts (which I understand if it does not recognize the address).
| Code: | | #use i2c (slave, I2C2, slow, address=8, stream=CUST_IC) |
I am using an IC Tools USB-to-IC2 Pro device to try to send test data to the PIC, and I can see the address going out ok, but no ACK.
see: http://www.w2drz.ramcoinc.com/temp/i2c2.jpg
I am concerned about the above scope trace though, because all of the rising edges are rounded. I don't think this should happen. The pullups are 3.3k, and the cable length is only a few inches. If I disconnect the processor but leave the pulllups on, then the signals are nice and square. Is it reasonable to expect the processor to be hard to pull up? I expect it should be in input float. I am wondering if that is a sign that the processor is not set up correctly.
I have tried using input_float () on the two pins with no change.
Any help?
Thanks, Russ |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Jan 29, 2016 3:02 pm |
|
|
| russk2txb wrote: |
I cannot find out why, but the slave address is not recognized - there is
no ACK generated when the address is sent.
#use i2c (slave, I2C2, slow, address=8, stream=CUST_IC)
|
Look at this section on page 17 of the NXP i2c specification:
| Quote: |
3.1.12 Reserved addresses |
http://www.nxp.com/documents/user_manual/UM10204.pdf
It shows that slave addresses 0x00 to 0x0F, and 0xF0 to 0xFF are reserved.
To fix your problem, chose another slave address such as 0x10
to put in the #use i2c() statement.
| russk2txb wrote: |
I have tried using input_float () on the two pins with no change.
|
So you tried it without the #use i2c() statement and only this code,
and it still produced slow rise times ?
| Code: | void main()
{
output_float(PIN_D5);
output_float(PIN_D6);
while(TRUE);
} |
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19516
|
|
| Posted: Sat Jan 30, 2016 2:26 am |
|
|
A couple of extra comments to this:
1) Make sure you have the PSP port turned off. Generally it's always worth checking that every peripheral on pins that you are using is explicitly 'off', except for the ones you are actually using. So:
setup_psp(PSP_DISABLED);
Just a 'belt and braces', to make sure this is off.
2) Generally a slave does not have a 'speed'. A speed is normally for a master device. However there is an exception to this, and your chip is one where this applies. Your chip has programmable 'slew rate control'. This enables circuitry that deliberately slows the edges of the I2C signals to help reduce problems with overshoot. I'd suspect this is being enabled, and is what is slowing the clock edges. If you want to turn this off, use:
| Code: |
#bit SMP2=getenv("BIT:SMP2")
SMP2=1; //disable slew rate control
|
This is shown in the data sheet as defaulting to 'on'.
The most likely main problem is the address. |
|
|
russk2txb
Joined: 30 Mar 2008
Posts: 109
Location: New Jersey
|
|
| Posted: Sat Jan 30, 2016 8:11 am |
|
|
Thanks Ttelmah for your suggestions. I did not know about the slew rate thing and that is probably why I see the slow rise times. However the main problem was that the I2C WAS connected to the wrong pins! For some reason Microchip puts the 'dot' on the chip exactly in the middle between pin 1 and pin 64, and I guess that the board layout person and I both counted the wrong direction when identifying the I2C2 pins. I was actually on pins used for A/D input. Now everything works as expected, but the rise times are still slow.
Sorry for the bother but I did learn about that slew rate feature. It is funny but I did not see that in the datasheet at all. I will have to go back and find it.
Regards, Russ |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
