I2C SDA spikes?

So I am using an I2C IR temperature sensor with the BBB. The device data sheet recommends performing an EEPROM dump, to store data on the mater. When I tell it to dump the device responds, nornally, but then something pulls the SDA line up prematurely for about 5us and then and all the subsequent data retrievals are skewed, seen here by the skinny little pop in the upper left of the pic.

this happens every time. any ideas? I have tried 10k and 1k pull ups and it still happens. Also, the clock runs consistently betw 3-5 khz slower that 100khz. not sure what to make of that either.

I think I have seen those on my scope during I2C transactions as well. They look like little shark fins that sometimes get high enough to be seen as a logic 1. They have no impact on the device as it's just the transition time between when the master is done transmitting the device address and starting to send data. The data line is released by the device but the master has not started to place data on the wire yet so the line starts to float back up via the pull-up. In your photo, it happens on the falling edge of the 9th clock bit and it's gone before the rising edge of the 10th clock so it's not being read as data.

Stronger pull-ups will just assist the runt in rising faster since the lower resistance allows the data line capacitance to be charged faster. On the scope you'd see the shark-fin start getting taller as you reduce the resistance. Your logic analyzer is just showing the brief time that the runt was interpreted as a logic 1 by the logic analyzer. Data isn't clocked in until SCL goes from low to high.

I think what you are chasing there is a red herring. The Logic analyzer shows both data values being what they ought to be.

I think I have seen those on my scope during I2C transactions as well.
They look like little shark fins that sometimes get high enough to be
seen as a logic 1. They have no impact on the device as it's just the
transition time between when the master is done transmitting the device
address and starting to send data. The data line is released by the
device but the master has not started to place data on the wire yet so
the line starts to float back up via the pull-up. In your photo, it
happens on the falling edge of the 9th clock bit and it's gone before the
rising edge of the 10th clock so it's not being read as data.

Stronger pull-ups will just assist the runt in rising faster since the
lower resistance allows the data line capacitance to be charged faster.
On the scope you'd see the shark-fin start getting taller as you reduce
the resistance. Your logic analyzer is just showing the brief time that
the runt was interpreted as a logic 1 by the logic analyzer. Data isn't
clocked in until SCL goes from low to high.

I think what you are chasing there is a red herring. The Logic analyzer
shows both data values being what they ought to be.

Unless your lines are very long, there is probably nothing wrong with your
I2C signals. My guess is you have a long ground wire on your oscilloscope
probe and this is causing the ringing. Use a high speed probe (small
distance between measurement tip and ground pin) and I¹m sure the signals
will look a lot cleaner. The long ground wire is acting like an antenna.

Regards,
John

He's using a Saleae logic analyzer so no way to alter the ground lead. This isn't ringing, when you see it on a short time-base it's very clearly a period of time between bytes when the data line is released and begins to rise back up to the positive rail. It's often too short to trigger a logic high but sometimes with stiffer pull-ups it rises high enough to be viewed as a logic high before the data line is driven again.

As you say though, I really think it's not the issue involved here. It's not occurring while clock is high so it's not messing with start|stop and it's gone before the next clock edge so it's not getting read as data.