 |
 |
| View previous topic :: View next topic |
| Author |
Message |
allenhuffman
Joined: 17 Jun 2019
Posts: 552
Location: Des Moines, Iowa, USA
|
| 24FJ64GA002 I2C slave reporting stop bit too soon? |
 Posted: Wed Nov 25, 2020 1:58 pm |
 |
|
I've run into another issue on the 24FJ64GA002, I think. The last issue was in the errata and I found a work around.
When receiving data from the Master, I have code that blocks until the next character comes in or the Stop bit is seen:
| Code: |
// Wait for either a stop bit, or another incoming data byte.
while ((P == 0) && (I2C_SYSTEM_BUS_IRQ_PENDING_BIT == 0));
|
On this PIC, it seems that the P get set early. If I start to process the message, it is incomplete. Verifying with an I2C analyzer shows all the bytes are written with the Stop indicator after the final bytes. Very frustrating.
Is anyone aware of this issue on any other PIC24 variants?
The master writes something like:
0x01 0x02 0x03 0x04 0x05
...and in my loop I see the Stop bit after the 0x03 SOMETIMES. It maybe failes 2-5% of the time, and the rest it happens when I expect.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
 |
newguy
Joined: 24 Jun 2004
Posts: 1907
|
|
| Posted: Wed Nov 25, 2020 2:32 pm |
|
|
Do you have an oscilloscope handy? Confirm that there isn't any very short duration transient noise on the lines.
Suspect that there's a runt transient which the analyzer doesn't "see" (or filters out/discards), but the PIC happily interprets as a stop.
What are your pullups? Line length? Anything remotely noisy on the board or controlled by the board? |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 552
Location: Des Moines, Iowa, USA
|
|
| Posted: Wed Nov 25, 2020 2:41 pm |
|
|
| newguy wrote: | Do you have an oscilloscope handy? Confirm that there isn't any very short duration transient noise on the lines.
Suspect that there's a runt transient which the analyzer doesn't "see" (or filters out/discards), but the PIC happily interprets as a stop.
What are your pullups? Line length? Anything remotely noisy on the board or controlled by the board? |
A diagram of our full-blown system would send you screaming. 
I have four variants of the PIC24 boards on the same I2C loop. I am using a Salea logic analyzer hooked up one step down. It properly sees everything, but the PIC24 the signal runs through before going to that board (we use ethernet cables for our connection, and ribbon cable on earlier board revisions).
When I capture a failure, I see everything properly on the Salea analyzer. But the PIC24 does not. With this particular PIC24 having the issue and others not, and having known errata with I2C bits not being seen properly, I am considering it a hardware bug currently.
We recently designed and built a custom board for analyzing our system. It has analog and digital outputs so we can read the raw signal as well as one through a conversion chip we use on our boards. We have been suspecting signal problems for things we are seeing, but the scope looked pretty good. It appears many of the issues we've fought have been found to be issues inside the PIC24 chips. Such a fun project!
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19505
|
|
| Posted: Thu Nov 26, 2020 2:03 am |
|
|
The obvious thought would be that possibly the chip reporting too often
has a higher Vih than the other devices, and that possibly the bus levels
are not what they should be. It sounds to be a long bus. Lots of capacitance.
Depending on the pull-ups, and the speed being used, if the Vih of this chip
was a bit high, the SDA signal might not have correctly recovered to what
it sees as Vih, when the SCL goes high. It then recovers a moment later
and this is seen as a 'STOP'. (A stop is a rising edge on SDA while the
SCL is high).
If you are not already using it, set the #USE I2C, to use SMBUS levels.
This drops Vih to a logic high of 2.1v, as against the default of 0.8 or 0.9*
Vss.
Your logic analyser, unless it has a specific I2C input setting, may well be
using this lower Vih level.
There is the following comment in the I2C specification, on this:
| Quote: |
D (DATA) - a high or low bit of information on the
SDA data line is valid during the high level of the
SCL clock line. This level must be maintained
stable during the entire time that the clock remains
high to avoid misinterpretation as a Start or Stop
condition.
|
If you then realise that what is actually interpreted as 'high' or 'low' is
dependant on the Vih of the chip concerned, it is easy to see how if a
chip has a fractionally higher Vih than the other devices on the bus,
or is placed further from the pull-up resistors, a problem can be seen
by just one device..... 
Remember though it also probably implies the rising edge times of
the bus may well be out of spec. I2C has specified maximum times
at given data rates for the bus to rise from the low to high levels,
(300nSec for fast mode, and 1uSec for standard mode), and this
error almost certainly implies the pull up resistors are larger than is
properly required for the capacitance of the bus. |
|
|
|
|
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
