i2c to BNO055 fails

[skandragon]

I've been trying to connect a BNO055 (from Adafruit) to the Adafruit Huzzah board, but it fails to work. I have tested the BNO055 against an actual Arduino, and it works.

I've tried using pull-up resistors of various values, but without success.

I've tried setting the Wire.setClock() to 100000, 200000, 300000, and 400000 as well as leaving it unset. I've tried different pins for SCA/SCL without success.

I don't have access to a logic analyzer or oscilloscope at the moment to dig into this at the protocol level, but I'm hoping someone here has advice to try.

I did see #254, which seems related.

[igrr]

#254 is actually fixed, not sure why it's still open.

A logic analyzer or a scope would really be essential to diagnose this issue... Is there any chance that you borrow one to do a test?

[skandragon]

I'm currently traveling (who doesn't work on electronics on a plane?) but I'll poke around and see if anyone has one handy. I'm in the SF Bay area; surely someone has one here!

[lrmoreno007]

You don't have a oscilloscope but you have an Arduino... Then you have a Oscilloscope.

[skandragon]

I've got little 8 Mhz devices, and so far everyone recommends 16 Mhz to get good results. The 16 Mhz devices I know of are all 5.0 v, and I'm using 3.3v, but technically that should work well enough, but it might extend high and low times. I think then 'scope would be better, and I might have access to one tonight.

[me-no-dev]

16MHz AVRs run just fine on 3.3V :) even though it's not recommended

[skandragon]

I grabbed a 16 Mhz Arduino last night, and tried using it. I did get some captures, but nothing of note. Part of the problem is the WDT triggers, and the ESP8266 is basically in a reset - probe loop, so capturing the actual data is harder than it should be. I'll modify the code to do less in setup(), and put a delay in for the i2c part as well. I may even teach it to cause a particular pin to rise or fall just before the i2c part starts, so I can get a sane trigger point for the scope.

[skandragon]

I have my device plugged into a National Instruments VirtualBench device, and am seeing some very strange things. For one, I see basically no activity on GPIO 4 or 5, although I expected to. I do see a lot of very, very short spikes across the board, from nearly all input pins. It doesn't even look like this is trying to speak i2c. I'm going to write a very very simple app just to see if I can get a basic i2c waveform out of pins 4/5.

[skandragon]

I now have this working with the latest code in master. Here's the trick: TWI_CLOCK_STRETCH is too small. I had to increase it to 800 (!) to make this work. Sometimes I see basically no delay between the address and data for write, or address and data for read. Sometimes I see 150uS or so between the end of the address and the data byte, or the end of the address and the reply. I have screen captures of each.

[skandragon]

I do occasionally get totally bogus values from the device still. These bogus values do not appear in the true Arduino board, so I suspect they are still related to the odd glitches I'm seeing occasionally on the logic analyzer. I am sure the power is clean from the supply.

[skandragon]

I'm not sure what explains this. Sometimes I get very odd spacing between i2c transactions:

[skandragon]

[yoonghm]

If you could disable WiFi from ESP8266 (do not know if it is possible), does the problem disappear? If so, the MCU does not have enough spare time to handle WiFi and I2C. Can you lower the speed of I2C?

[skandragon]

I am not using WiFi at this time. Is there something more than just not configuring it I have to do to completely disable it?

[skandragon]

The glitch problem is insufficient power from the FTDI. Even without WiFi, this device draws more than it can supply. However, this does not quite explain the very oddly stretched i2c issue unless I'm losing the CPU during that time, as referenced on another issue I had open.