Exact match. Not showing close matches.
'[PIC] I2C missing first character...sometimes. loc'
> If it failed every single time I could accept that and try a different
> method. What I'm finding is that even under identical conditions
> it's a coin toss whether the F88 will accept data properly. I spent
> a lot of the past few days trying to gather evidence, perhaps see
> some sort of pattern , but I still couldn't predict when an sspif test
> will fail
Could you clock the F88 from the same oscillator as the device sending
the data, just for testing?
This would fix the relationship between I2C clock edges and the
slave device internal clock, and remove some of the 'randomness' so
that you could confirm that SSPIF is not being set correctly.
Adding a variable phase shift (using something like a ring counter
clocked at 100Mhz to get fine steps, or a tapped delay line)
may allow you to find a oscillator timing phase where it misses EVERY time.
Creating test code that just bangs away with addresses (7, 8, 9, 7, 8, 9)
should increase the 'error' rate to make it easier to point a finger at
Borrow/rent a logic analyzer with a really deep capture buffer,
and look at the I2C edge timing wrt slave master clock.
It could well be that there is a silicon bug and that the issue is
setup time on the SSPIF flag.
The Agilent 6000 series of MSO scopes have up to 8 megasamples of buffering,
and can be setup to trigger on timing errors such as you are seeing
so that it should be easier to zero in on the 'bad' timing value.
That you couldn't get it working at 8 Mhz, but somewhat at 4, suggests
that if you dropped to 2 or 1, it would work every time, which would
pretty much eliminate your code as the problem.
And you might want to try cooling or heating the chip significantly
since temperature changes propagation times internally, and would change
the error rate if it were the cause.
More... (looser matching)
- Last day of these posts
- In 2006
, 2007 only
- New search...