Tsa5511 & pic12f629 i2c_read returns 0

[Eve]

Hi,

I'm having difficulties reading a phillips pll chip ( tsa5511 ) with a 12f629.
Writing to the chip is no problem and i can easily lock the chip to a set frequency. Reading the chips lock flag however keeps returning zeroes.
The pullup resistors are 10kohm.

Here's the read routine:

#use i2c(Master,slow,sda=PIN_A1,scl=PIN_A2)
#use delay (clock=3200000)
#fuses XT,PUT,MCLR,NOWDT


byte tsa5511_status_read(char tsa_addrr)
{
byte data2;
i2c_start();
i2c_write(0xc1); //write addr=0xc0, read addr=0xc0+1
data2=i2c_read(1); // i2c_stop();
return data2;
}


The write routine is as follows:

byte set_tsa5511(char tsa_addrr,int16 freqmhz,int16 freqkhz,int16 outport)
{
byte bytes[5];
int i;

bytes[0]=tsa_addrr;
bytes[1]=((freqmhz*20)+(freqkhz/5))/256; //get MSB
bytes[2]=((freqmhz*20)+(freqkhz/5))-(bytes[1]*256); // LSB
bytes[3]=0b10001110; // 1-Cp(0)-T1-T0-1-1-1-0
bytes[4]=outport;
i2c_start();
for(i=0;i<5;i++) {
i2c_write(bytes[i]); }
i2c_stop();
if(tsa5511_lock(0xc0)!=0) return 1;
else return 0;
}

The fun part is that my routines worked perfectly with CodeVision AVR C compiler for atmel microcontrollers.
According to me, it seems to be a timing issue.

Any clue anyone?

grt.

xor101

[Kenny]

I haven't used that chip, but I did notice a couple of things you could try.
A NACK (high) needs to be output by the pic on the last byte received to reset the i2c logic of the chip.

byte tsa5511_status_read(char tsa_addrr)
{
byte data2;
i2c_start();
i2c_write(0xc1); //write addr=0xc0, read addr=0xc0+1
data2=i2c_read(0); // First byte is last byte so NACK
i2c_stop();
return data2;
}

Also, 10k is a bit high, usual range is 2k2 to 4k7.
HTH

[Guest]

Yep,

I tried the 4k7 pullups as wel, no change.
I tried the unack mode too, same results as ack mode.
The main prob is that i don't have an oscilloscope to check the wave patterns. I do have a spectrum analyzer...
normally it is the other way around.....

The code is supposed to be running as it is on the atmel cvavr compiler. I ported to code to CCS PICC. Not a big hassle though. The i2c routines appear similar, except this issue.
Writing to the device is no prob and is checked to be working. reading is a bit harder seems.

could it not be the case that the tsa5511 is not able to sink the pic12f629 ports to ground? if so, what to change to the code. With the atmel 2313 the ports where floating.


grt.

xor101

[languer]

To float I2C pins:

[PCM programmer]

I think you need to show us a full demo program.

1. Show all pre-processor statements. #fuses, #use delay(),
#use i2c(), etc.

2. Show a main() function, in which you call all of the functions
shown in your original post. Put in suitable parameters.

3. Show your initialization code in main(). ie., how you setup
the i/o ports as digital pins, etc. Don't leave out any of your
init code that pertains to i/o pin setup.

4. Show us the code for the tsa5511_lock() function.

5. What is your version of the compiler ?

6. I have a question about your "#use delay (clock=3200000)"
statement. If I go to http://www.digikey.com and look at both
crystals and oscillators, I don't see that offered as a standard
frequency. It may be that you had a custom crystal made,
but I want to confirm that the #use delay clock speed matches
your crystal frequency exactly.

7. What voltage are you running the PIC at ? What voltage are
you running the tsa5511 at ?

8. How do you know that writing to the tsa5511 works ?

[Guest]

Ok, in reply to PCM programmer.

1
#use i2c(Master,slow,sda=PIN_A1,scl=PIN_A2)
#use delay (clock=3200000)
#fuses XT,PUT,MCLR,NOWDT

2 // Soft voted pll loop lock detection.
main() {
while(lock_timout!=0) {
if(tsa5511_lock(0xc0)==1) {
if(lock_timout>0) lock_timout--;
}

if(tsa5511_lock(0xc0)==0) {
if(lock_timout<2048) lock_timout++;
}
}
}

3 These are the pin output settings.

output_float(pin_A2);
output_float(pin_A1);

4 The lock detect routines.

byte tsa5511_lock(char tsa_addrr)
{
if((tsa5511_status_read(tsa_addrr)&0b01000000)!=0) return 1;
else return 0;
}

byte tsa5511_status_read(char tsa_addrr)
{
byte data2;
i2c_start();
i2c_write(0xc1);
data2=i2c_read(1);
i2c_stop();
return data2;
}

5
IDE: 3.28
PCx 3.150

6
cristal frequency is indeed 3.2 mhz. This is because of the clock for the tsa5511. 3.2mhz / 64 = 50 khz reference step.
The pic clock is used to clock the tsa5511. Crystal is tapped with a 33pf capacitor.

7 The pic and the tsa511 are running on 5 volts.

8
When i write the settings to the tsa5511 the oscillator directly locks onto the desired frequency. The loop is in lock.

Hope this is enough info.

[eve]

Hi,

I found the problem and it's not related to my sourcecode i think.
After some debugging with an oscilloscope i found that the clock is out of sync with the data. The skew is exactly two bits.
see
http://62.216.16.167/clockskew.jpg
this realy seems like a library bug, since i can't understand why the clock should be skewed. The master ( pic 12f629 ) generates the clock, the tsa pulls the dataline low or not.

The clock seems to go out of sync after a ack.

who can help please?

[PCM programmer]

I was out of the office on Tuesday, and so I couldn't get back to you.

Before you go any farther, you need to make these changes:

I think you said before that you tried changing the i2c_read() parameter
to 0, and it didn't fix your problem. So apparently you changed it
back to a 1. But that's not correct. The last i2c read must do a NAK.
Regardless of whether or not the overall problem is fixed, the line
shown below in bold must be changed to use a 0 parameter.

byte tsa5511_status_read(char tsa_addrr)
{
byte data2;
i2c_start();
i2c_write(0xc1);
data2=i2c_read(0); // The parameter must be 0
i2c_stop();
return data2;
}

---------
The 12F629 has a comparator on pins GP0, GP1, and GP2.
The default power-up state is for it to be enabled. It should
be disabled by adding this line to the very beginning of main():

setup_comparator(NC_NC_NC_NC);

I tested this with PCM vs. 3.150 (your version), and it writes
to the correct register (CMCON at address 0x19).
---------
I don't like the order in which you have the compiler directives.
I would always put the #use delay() line above any #use statements
that invoke CCS library routines. The compiler needs to know
the "clock" speed in order to create the proper length delays.
I would do it in this order:

[eve]

Hey man,

The setup_comparator(NC_NC_NC_NC); did the job!!!!

About the messy code, well you're right. I'm cleaning it right now!

Guys (especially PCM programmer) THANKS for helping me out!!!


grt.

Eve