Skip to content
This repository was archived by the owner on Jan 28, 2021. It is now read-only.

127 bytes available bug #37

Closed
nseidle opened this issue Sep 3, 2019 · 4 comments
Closed

127 bytes available bug #37

nseidle opened this issue Sep 3, 2019 · 4 comments

Comments

@nseidle
Copy link
Member

nseidle commented Sep 3, 2019

Not sure if it's a bug, but wanted to document a weird ZED-F9P I2C comm issue:

Platform: Artemis

When requesting bytes available, we often see 0x007F or 127 bytes:

image

Unfortunately all these bytes are empty:

image

This happens multiple times per second (4 times in 1.15s):

image

@mazgch
Copy link

mazgch commented Sep 16, 2019

Could this issue be related to a mechanism of the u-blox GPS referred to as clock stretching. An I2C slave is allowed to hold down the clock if it needs to reduce the bus speed. The master on the other hand is required to read back the clock signal after releasing it to high state and wait until the line has actually gone high.
Does Artemis support slaves that make use of clock stretching?

@nseidle
Copy link
Member Author

nseidle commented Oct 7, 2019

Artemis does support clock stretching. I believe you can see the ublox module stretching the lock in the image in the OP:

image

I believe it's something else internal to the ZED but I can't pin it down.

Further thoughts:

  • I've seen similar behavior with the SAM-M8Q.
  • I see fewer issues like this on the ATmega328 based systems but not zero

@mazgch
Copy link

mazgch commented Oct 10, 2019

There was a similar issue in the nodeRED firmware, maybe this workaround can be applied.
nodemcu/nodemcu-firmware#1586

@nseidle
Copy link
Member Author

nseidle commented Jan 8, 2020

I haven't seen this bug in awhile. I think it's mostly been taken care of with the recent lib changes.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants