Skip to content

RuntimeError: bad chip id (1 != a0) on ESP8266 #9

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
caternuson opened this issue Apr 10, 2018 · 9 comments
Closed

RuntimeError: bad chip id (1 != a0) on ESP8266 #9

caternuson opened this issue Apr 10, 2018 · 9 comments
Labels

Comments

@caternuson
Copy link
Contributor

caternuson commented Apr 10, 2018

Not sure if this is related to #2 or not. The traces look different, so maybe bitbangio is playing into it? It's failing before it even gets to the reset part.

Adafruit CircuitPython 2.2.4 on 2018-03-07; ESP module with ESP8266
>>> import board
>>> import busio
>>> import adafruit_bno055
>>> i2c = busio.I2C(board.SCL, board.SDA)
>>> sensor = adafruit_bno055.BNO055(i2c)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "adafruit_bno055.py", line 125, in __init__
RuntimeError: bad chip id (1 != a0)
>>> 

esp8266_bno055

@tannewt
Copy link
Member

tannewt commented Apr 11, 2018

Could you zoom in on the trace so we can see what the response was? Thanks!

@caternuson
Copy link
Contributor Author

caternuson commented Apr 12, 2018

Here's a zoom on the response. SDA/SCL state remain unchanged for rest of trace. Attached the trace file also.

bno055_i2c_trace_zoom

esp8266_bno55.zip

@caternuson
Copy link
Contributor Author

I'm thinking this has something to do with bitbangio and clock stretching.

I didn't even need to use the drivers. I was able to see an issue with just this simple test:

>>> import board, busio
>>> from adafruit_bus_device.i2c_device import I2CDevice
>>> i2c = busio.I2C(board.SCL, board.SDA)
>>> device = I2CDevice(i2c, 0x28)

Tested with a Feather M0 Express and Feather ESP8266 using a TCS347245 and a BNO055. Here's what it looks like under the scope:

Feather M0 Express w/ TCS34725
No clock stretching, all good:
m0_tcs34725

Feather M0 Express w/ BNO055
Some clock stretching in the ACK, but it handles it, all good:
m0_bno055

Feather ESP8266 w/ TCS34725
No clock stretching, all good:
esp8266_tcs34725

Feather ESP8266 w/ BNO055
It doesn't like that clock stretch :(
esp8266_bno055

@deshipu
Copy link
Contributor

deshipu commented Apr 26, 2018

The code for clock stretching in bitbangio is here: https://github.com/adafruit/circuitpython/blob/master/extmod/machine_i2c.c#L56-L61

Personally I don't see anything wrong with it, but maybe I'm missing something...

@deshipu
Copy link
Contributor

deshipu commented Apr 26, 2018

Hmm, looking at the shared-module, it seems the code I linked above is not used. Instead, this is used: https://github.com/adafruit/circuitpython/blob/master/shared-module/bitbangio/I2C.c#L53-L55 which is the old version with the time stretch timeout hard-coded to 255µs — but that should still work, as on the trace the stretch is a bit over 100µs, so I still have no idea.

@deshipu
Copy link
Contributor

deshipu commented Apr 26, 2018

Could it be that there is enough delay between releasing the SCL pin and releasing SDA pin, that ACK is missed?

@caternuson
Copy link
Contributor Author

caternuson commented May 24, 2018

Blaming this on clock stretching may be a red herring.

It seems to be more related to specific timing issues with specific sensors. As an example, can get the same failure on the Feather M0 Express w/ BNO055 combo using bitbangio instead of busio, like this:

>>> import board, bitbangio
>>> from adafruit_bus_device.i2c_device import I2CDevice
>>> i2c = bitbangio.I2C(board.SCL, board.SDA)
>>> device = I2CDevice(i2c, 0x28)

and here's the trace:
m0_bno055_bitbangio
Note the difference in timing on SCL between bitbangio (~40kHz) and busio (~333kHz)

@kattni
Copy link
Contributor

kattni commented May 4, 2020

@caternuson Is this still an issue?

@caternuson
Copy link
Contributor Author

@kattni Unknown. The landscape has changed so much (ESP8266 is no longer supported and bitbangio isn't in M0 builds) that I'd say let's just close this and if there is still some issue, we can open a new one with updated info and testing when we hit it.

@ladyada ladyada closed this as completed May 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants