| View previous topic :: View next topic |
| Author |
Message |
Jim Hearne
Joined: 22 Dec 2003
Posts: 109
Location: West Sussex, UK
|
|
 Posted: Thu Feb 28, 2013 9:07 am |
 |
|
As i mentioned above, i've found that at 64mhz PIC clock the I2C data output is idleling low.
I thought some pictures of this might be of interest.
No changes at all to the code between the 2 clock speeds except changing the speed and recompiling.
Top trace is Data, bottom is Clock, scope is triggering off falling edge of clock.
32 Mhz clock 50us
64 mhz clock 50us
32 Mhz clock 200us
64 mhz clock 200us
Any thoughts ?, i have told CCS but no answers as yet.
Many thanks,
Jim Hearne
[/b] |
|
 |
bkamen
Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA
|
|
| Posted: Thu Feb 28, 2013 9:17 am |
|
|
The 64MHz picture shows illegal start/stop conditions.
I2C should always start and end with SCL and SDA high.
I'd have to go look at the I2C spec again to be sure.. but I also provided a link if you wanted to check too..
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
Jim Hearne
Joined: 22 Dec 2003
Posts: 109
Location: West Sussex, UK
|
|
| Posted: Thu Feb 28, 2013 9:21 am |
|
|
| bkamen wrote: | The 64MHz picture shows illegal start/stop conditions.
I2C should always start and end with SCL and SDA high.
I'd have to go look at the I2C spec again to be sure.. but I also provided a link if you wanted to check too..
-Ben |
Yes, i know, but this is what the CCS compiler is generating for the software I2C at 64mhz clock, i can't see why the change in clock speed should break it.
It's the same code as at the start of the thread except for #define I2C_DELAY 10 is changed to 0 and the #use delay(clock=64000000,RESTART_WDT) is set to 32mhz or 64 mhz.
Thanks,
Jim
Last edited by Jim Hearne on Thu Feb 28, 2013 9:24 am; edited 1 time in total |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19608
|
|
| Posted: Thu Feb 28, 2013 9:22 am |
|
|
Does it do this with a different I2C slave device?.
Key thing is that the slave device, can also hold the line low. This is 'clock stretching', and the master is then meant to stop till the line is released. This is how transactions are synchronised, with the slave holding the line low, till it has completed processing the data.
So it could be either the master or the slave holding the line 'low'. It might be the slave signalling a problem, not the PIC. This is what is returned as ack/nack from I2C write operations.
Best Wishes |
|
|
Jim Hearne
Joined: 22 Dec 2003
Posts: 109
Location: West Sussex, UK
|
|
| Posted: Thu Feb 28, 2013 9:30 am |
|
|
| Ttelmah wrote: | Does it do this with a different I2C slave device?.
Key thing is that the slave device, can also hold the line low. This is 'clock stretching', and the master is then meant to stop till the line is released. This is how transactions are synchronised, with the slave holding the line low, till it has completed processing the data.
So it could be either the master or the slave holding the line 'low'. It might be the slave signalling a problem, not the PIC. This is what is returned as ack/nack from I2C write operations.
Best Wishes |
Ah, good thinking.
I changed the slave address to 0x72 (from 0x70) so it doesn't access SAA1064 chip and then the waveform stays correct.
So the SAA1064 must be thinking it's getting a read command (i never read from it as it only has a power on status bit) and then just hanging onto the bus.
I will have to look into it further, maybe time to get the logic analyser out.
Many thanks,
Jim |
|
|
Jim Hearne
Joined: 22 Dec 2003
Posts: 109
Location: West Sussex, UK
|
|
| Posted: Thu Feb 28, 2013 10:12 am |
|
|
It's actually exactly the same problem as i had when i was trying to use the hardward I2C.
I put that down to that fact that the minimum I2C clock i could get with the hardward I2C is about 122khz.
Well above what is recommended for the SAA1064.
I've now found mentions of not using it at more that 50khz clock.
I guess the CCS software I2C doesn't support clock stretching so just carries on whereas the hardware I2C just hangs waiting for the stretching to end.
I think we might look for an alternative chip for production units.
Many thanks,
Jim |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19608
|
|
| Posted: Thu Feb 28, 2013 10:30 am |
|
|
I'd suggest using a DIY mod to the I2C write command. Something like:
| Code: |
void my_i2c_write(int8 val) {
i2c_write(val);
do {
delay_us(3);
} while (input(SCL_PIN)==0);
}
|
My suspicion is that the slave device takes possibly one internal clock to assert the clock line low. At lower CPU clock speeds this is OK, but at 64MHz, the CPU tests the line before it drops. Hence it doesn't see the line as low, and immediately returns. Then starts sending the next value before the chip is ready.... This is why your delays solve things, but they are probably significantly longer than is actually needed for some of the commands.
So instead, I'm using the standard I2C write function, pausing a moment, then testing if the line is low. If it is, wait a bit longer.
The line looks to assert low about 3uSec after the line is released, so with the extra delay in getting out of the write function, ought to be low when tested the first time.
Best Wishes |
|
|
oxo
Joined: 13 Nov 2012
Posts: 219
Location: France
|
|
| Posted: Fri Jun 21, 2013 6:42 am |
|
|
| Ttelmah wrote: | What have you got as Cext?.
If you are running multiplexed, this determines all the update timings on the chip. There is a (hidden) minimum time between being able to do things, based upon this.
Best Wishes |
Can you expand on this? What is the minimum time?
I have a pair of these running, but I get occasional flickers, maybe once every 5 seconds. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
