 |
 |
| View previous topic :: View next topic |
| Author |
Message |
mewanchyna
Joined: 21 Nov 2005
Posts: 15
Location: Montreal, Canada
|
| I2C not working on 16F690 |
 Posted: Mon Apr 17, 2006 12:03 am |
 |
|
After trying many experiments, I can't get the software I2C interface to work on the 16F690. I'm using ver. 3.249 of the compiler. I've looked at the dissasembly listing and the program seems to get stuck in a loop looking for a pin to go logic LO. My understanding is that even without an I2C device attached, the code shouldn't get stuck in a loop waiting for a response. I've also used two pullup resistors on the two I2C lines as well. I've included a parsed down version of the code. Any ideas?? | Code: |
#include <16F690.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES
#use delay(clock=8000000,RESTART_WDT)
#use i2c(Master,Slow,sda=PIN_C2,scl=PIN_C3,restart_wdt)
void main() {
setup_adc_ports(NO_ANALOGS|VSS_VDD);
setup_adc(ADC_OFF);
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED,0,1);
setup_comparator(NC_NC_NC_NC);
setup_oscillator(OSC_8MHZ);
while(1){
output_high(pin_c0); // using this pin to see
delay_ms(500); // if the micro
output_low(pin_c0); // is alive !!
delay_ms(500);
i2c_start(); //
i2c_write(0x90); // invoking this line causes micro to halt
}
}
|
|
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Apr 17, 2006 12:32 pm |
|
|
Try this program, exactly as shown:
| Code: | #include <16F690.h>
#fuses INTRC_IO, NOWDT, PUT
#use delay(clock=8000000)
#use i2c(Master, sda=PIN_C2, scl=PIN_C3)
void main()
{
setup_adc_ports(NO_ANALOGS | VSS_VDD);
setup_comparator(NC_NC_NC_NC);
setup_oscillator(OSC_8MHZ);
while(1)
{
output_high(PIN_C0);
delay_ms(500);
output_low(PIN_C0);
delay_ms(500);
i2c_start();
i2c_write(0x90);
}
} |
|
|
|
mewanchyna
Joined: 21 Nov 2005
Posts: 15
Location: Montreal, Canada
|
|
| Posted: Mon Apr 17, 2006 8:11 pm |
|
|
| Hi, I tried the code as shown. as expected, C0 flashed on then off and that's it. I orginally ported the whole routine from my working 16F877A pic routine. I didn't expect the results that I've had so far. I even tried to use the built in hardware I2C interface on the 16F690 and added the "force hardware" line with identical, non-functioning results. I've tried various combinations of most fuses as well. I've replaced the PIC with a known good device to eliminate a hardware problem. I've compiled the project under MPLAB ver 7.22. I noticed that the routine stays in a loop, waiting for C3 to go to logic HI. It stays in this loop unless I manually apply a stimulus to that pin. The strange thing is that, C3 is already being held HI by the pullup resistor. Any other ideas. I'm running out! Thanks. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Apr 17, 2006 9:09 pm |
|
|
| Quote: |
I even tried to use the built in hardware I2C interface on the 16F690 and
added the "force hardware" line with identical, non-functioning results. |
This PIC doesn't have an MSSP, so I think software i2c is used even on
the "hardware" pins for Master mode.
| Quote: |
I noticed that the routine stays in a loop, waiting for C3 to go to logic HI.
It stays in this loop unless I manually apply a stimulus to that pin. The
strange thing is that, C3 is already being held HI by the pullup resistor. |
So it's likely to be stuck in the "clock stretching" loop. This part of
the CCS library code checks the SCL pin to see if the Slave device is
holding it low, until the slave is ready.
So how could pin C3 be read as a continuous logic low level ?
Possible answers:
1. If the pin is configured as an analog input, it will read as a logic low.
However, the code appears to setup the ANSEL register = 0, which
should configure pins C2 and C3 as digital i/o.
2. If you don't really have a pull-up on pin C3, it could float low.
Pin C3 is pin 7 on the 16F690 (20-pin DIP, SOIC, or TSSOP package).
Other possibilities:
1. The PIC is not really a 16F690. It's some other PIC.
2. The pull-ups are not wired correctly. They're either on the wrong pins
or they are wired as pull-downs.
3. Pin C3 is blown and always reads as a logic zero.
4. Something else besides the pull-up resistor is connected to pin C3,
such as a large value capacitor, or some circuit that is loading down
the pin, such as a pull-down resistor.
5. Pin C3 could be shorted to another pin, due to a solder short, and
it's being held low because of that.
6. You could be using a ICD debugger or an ICE to test the code, and
the unit isn't working properly. |
|
|
mewanchyna
Joined: 21 Nov 2005
Posts: 15
Location: Montreal, Canada
|
|
| Posted: Wed Apr 19, 2006 4:18 pm |
|
|
Thanks for the checklist. This is a really strange problem. I have 17 students who also have the same problem. Some of these may be programming errors but all 17? Nevertheless, going through your list, I double checked the pullups on the two pins. Definitely pulled up to +5V. I'm definitely using a PIC16F690. I made a program to read the status of C3 and apply its value to an output pin. It is reading the proper logic level applied to C3. It's a protoboard, therefore nothing else is connected to these pins. Since I can control two LEDs attached to these two pins individually, it can't be a short. I'm not using an ICD or ICE. My next plan is to make a board with an ICD connector and step through the code using MPLAB and their ICD2. I'll also look through the asm list to try to see what's happening and make sure I didn't misinterpret something. If I find out more, I will reply back.
PS porting the complete code back to the 16F877A worked flawlessly! |
|
|
mewanchyna
Joined: 21 Nov 2005
Posts: 15
Location: Montreal, Canada
|
|
| Posted: Wed Apr 19, 2006 6:33 pm |
|
|
| Sometimes the obvious is not so obvious! Although the I2C lines had pullups on them, after all, the LEDs attached to the I2C outputs were on when the pullups were added, the output pins must be logic HI, right? Wrong. The pullup resistors combined with the LEDs and current limiting resistors formed a voltage divider that kept the output pins at about slightly more than half +Vcc. This doesn't constitute a logic Hi. After removing the LEDs and trying out the original program, I've got the I2C interface functioning. I shouldn't have missed this obvious problem to start with. Sometimes, we all have to go back to school! Thanks for the help. |
|
|
|
|
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
