Odd spike in I2C data pulse. Nofloat_high not doing its job?

[Jeff7]

Update: Problem solved, apparently. As per recommendations here, I dropped the value of the pullup resistors, and dropped the nofloat_high. Once that was done, the odd 0.48V bumps disappeared, as did the spikes, and all the data pulses were still reasonably squared-up.



Hello all,
I'm using a PIC18F4520 to serve as a sort of clock/calendar timeserver along with a DS3231 realtime-clock, which uses I²C for communication.

It does communicate normally with the PIC, except I do sometimes get odd lockups in the PIC, which even the watchdog timer is unable to handle. The LCD (the usual Hitachi-based 16x2 display I see used commonly) becomes corrupted when these lockups occur, and a hard-reset is required. (This may well be worthy of a thread by itself.)


Anyway, I don't know if this is the cause, but it's still something I'm investigating: I get an odd spike in voltage when I'm writing the DS3231's address to the chip, using the built-in i2cwrite() feature.
The oscilloscope I have to work with has no image export function that I know of, so you'll have to put up with sketches for now.

Here is a sketch of the entire pulse (SDA line). The black pulse shows what I get when I do not have nofloat_high within the #use i2c section.
The red pulse is what I get when I do use it. Note the sudden spike at the end there.



Here's a closeup of the spike itself. You can see that it is very short in duration, only 104nS, but it does manage to work itself all the way up to 2.480V.



Here's what I'm using for the #use section:

[PCM programmer]

Post a short test program that will allow us to try to duplicate the problem.
I mean a really, really short program. Something like this:

[FvM]

I think, you didn't tell at all, which signal is shown in your sketched waveform. Is it SDA? If so, what's the green trace?

[Ttelmah]

The 'no_float_high' spec, sets up the code to momentarily drive the sgnal 'high', when it transitions, to improve the rising edge. The key though is the word _momentarily_. You still should provide standard I2C pullups on the lines. For a 3.3v bus, at 100K, with no series resistors, the _maximum_ value of the pullup resistors specified, is just over 3KR. The minimum, is just on 1KR.
The lines do not look to be being driven high properly at all...
Remember the low level drive is only specified as 0.6v. Nothing lower is needed.

Best Wishes

[Jeff7]

It's SDA, and just one bit of the data that's being sent.
The SCL line looks about like you'd expect - just series of evenly-spaced pulses during the time between i2c_start and i2c_stop.

In this particular section, I'm performing this simplified code:

[PCM programmer]

[Jeff7]

I edited my post; the FUSES I posted apparently was from a slightly older version of this code.
LVP and DEBUG have in fact been disabled.

And I'm not sure how much I'm really permitted to post of the code. I figured posting a few innocuous things would be ok though. And really, that's all that was run in order to generate the odd waveform.

1) Why no watchdog timer though, even on a test program? I have been bitten before by disabling it while writing and testing code, and then enable it, only to find that it was causing odd resets. I can give it a go with it disabled though.

2) Done.
3) Done.

4) I2C Fast Mode - this unusual waveform happens just the same with slow or fast mode.

5) Pullups on the SCL and SDA lines are 10k now. I'll definitely try out something much lower when I'm back at the office.

[FvM]

Although 10k pullup is possibly a bit high, it should not cause the discussed behaviour. I asked for the pullup, because SDA seems to have a rather slow risetime, that can't be explained with e.g. 20 pF pin capacitances and a 10 pF oscilloscope probe. The said 400 pF is a maximum bus load for a large multi-drop bus and doen't apply for your design, of course. Or did you connect a 1:1 100 pF probe?

From a complete bus transaction, with SCL and SDA recorded, one can possibly see, which side is generating the spike. If I understand right, the nofloat_high option is only available with software I2C, because it's no hardware feature of the PIC I2C interface. I wonder, why you're using software I2C on the standard I2C pins, that would allow hardware I2C as well?

Apart from what causes the "spike", I don't see a sufficient explanation, why it should also involve the other reported problems, unless you have a defective chip or another serious hardware issue.

[Jeff7]

[Jeff7]

Some updates:
- The oscilloscope is a Tektronix TDS 210.
As for the probes, they're 1x/10x probes, without any markings on them as to capacitance.

- I swapped out the 10k pullups and used 1.2k instead, and got rid of nofloat_high. I've got much sharper rises now, and all signals are either 0V or 3.3V; that little 0.48V "bump" is gone now. Rise time is about 412ns to hit 3V from 0V. Fall time is less than 100ns. (This is in fast=400000 mode.)


Seems like that may take care of this problem, unless anyone has any followup questions or hanging issues that they want answered.
Now it's on to determine the cause of these mysterious lockups.

[FvM]

Unfortunately, I can't explain the mysterious lookups from a distance.

Regarding probe impedances, you can expect 10-15pF || 10 MOhm in 10x position and about 100 pF || 1 MOhm in 1x mode. So it's strongly recommended to set the probe to 10x for an (almost) undisturbed signal acquisition.

[rnielsen]

I've seen this 'spike' quite a bit. It's, usually, when one device releases the line. I see it just before the ACK, when one of the devices releases the bus and the other one takes over to send the ACK. Is this where the spike is happening?

One other thought might be that there could be some contention between devices where one is trying to pull high while another is trying to pull low. Shouldn't happen but I've seen it, especially when I was trying to bit-bang things and didn't have things timed quite right.

You might try a bus accelerator like the LTC1694-1. I always use this in my I2C designs to make sure the signals are squared up properly.

Ronald

[Jeff7]

The spike appeared to be happening at the end of what should have been a logic high (I think that's the proper terminology), being driven there by the DS3231, but as best as I can figure, the PIC tried driving it low, but then for whatever reason it stopped trying about 100ns before the DS3231 stopped what it was doing.

Once I dropped the values of those pullup resistors way the heck down, and got rid of nofloat_high, the signals squared up well enough, the spikes went away (since the signal was already at 3.3V, it had nowhere to spike to), and where those odd little 0.48V-pulse+spikes had been, there were only clean logic highs coming off of the DS3231.





On an unrelated matter, though not really worthy of its own thread, the lockups I mentioned have also gone away, apparently. I think it was a memory management issue of sorts.
The way the code was done up before, the menus were all in one BIG function, consisting of a switch statement with oodles of cases after it. And some of the menus needed to call functions within them. For example, when setting the time on this particular product, it would first run another function to perform time zone calculations, which would call another function to do Daylight Savings Time calculations, which would call another function.....I think it went somewhere around 6 deep at some point, complete with all kinds of local variables being passed around.

When the menu() function was originally made, it was quite small, with only 4 screens. Since then it's grown in complexity to include 19 screens, some of which call functions, as described above.

In my brief and unskilled time with an ICD-U40, I saw that this massive Menu function was of course being shoved onto the stack. Sometimes the function calls that would cause this would initialize local variables consisting of 1-dimensional arrays of up to 212 characters, and a 2-dimensional array 4x70 characters.
As best as I can figure to the best of my relatively unskilled abilities, something was shoving things into places in memory or in the stack where they weren't allowed, causing either resets or hard lockups.


Anyhow, I pushed the calls to those functions which required large data buffers outside of the menu function, and instead used flags to enable them to be run.

These large buffers are being used to accept long strings of GPS data in through a software UART. If I tried to do any sort of processing of the information while it was arriving, I almost always lost a lot of it, so I instead used a large buffer to collect it all en masse, and then process it afterward to pluck out what I needed.




(Also, forgive any misuse of terminology. Corrections are welcome. Just be gentle. )

[bkamen]