Sparkfun BNO080 - Teensy 3.6 >> 4.0

Status
Not open for further replies.
First issue is bus getting totally hung out to dry.

Put in the wait_idle call like is in for T3.x, which after 15ms of it being busy it tries to reset, by changing IO pins...
Appears to unhung that part of the test. Now still not handling the NAK properly.

WIP up in my github branch: T4_timeout_errors

Congrats on the Logic 8...
 
@KurtE
Thanks on the LA - about time right :)

Anyway haven't downloaded your branch yet but with the hacked up version I have with the extra delayMicroseconds(100) after the requestFrom's all the sketches seem to work except for the rotationVector which is telling me no BNO080 not found. Don't know if this info is helpful or not :)

BTW: WIP -> wire or bno?
 
So far trying to fix with Wire...

That is if it is working on T3.x then should work here (hopefully)...

Although who knows there might always be a need for a delay...
 
@KurtE
Can you give something a try with your BNO080, change this in the waitfori2c function in the BNO080.cpp file:

Code:
boolean BNO080::waitForI2C()
{
	for (uint8_t counter = 0; counter < 225; counter++)
and see if it works any better.
 
@defragster
The whole function looks like this:
Code:
boolean BNO080::waitForI2C()
{
	for (uint8_t counter = 0; counter < 225; counter++) //Don't got more than 255
	{
		if (_i2cPort->available() > 0)
			return (true);
		delay(1);
	}

	if (_printDebug == true)
		_debugPort->println(F("I2C timeout"));
	return (false);
}
the delay(1) should prevent that as long as millis is accurate :) I haven't tried changing clock speed - should give it a try and see what happens.
 
Is that the kind of thing that will get optimized away as a NOP? Also vary wildly with F_CPU

@KurtE - @defragster

Ok. Using @KurtE's wire changes and my waitfori2c change I tested a bunch of sketches at 150, 396, 528 and 600Mhz. The only one that seemed to give the BNO080 a problem was at 600Mhz. Why not sure?
 
@defragster
The whole function looks like this:
... the delay(1) should prevent that as long as millis is accurate :) I haven't tried changing clock speed - should give it a try and see what happens.

That is a whole diff story :) … the millis()/micros() test across speeds I re-ran look good. Though alternate speed to shuffle the i2c clocks might tell something.
 
Note: I was still running into some of them having issues at startup...

And some of their (BNO080) does not make sense to me...

That is if I understand correctly, the code like: ::getData.

Does something like: _i2cPort->requestFrom(...)
It does not look at return value... Then it calls waitForI2C().
Code:
boolean BNO080::waitForI2C()
{
	for (uint8_t counter = 0; counter < 100; counter++) //Don't got more than 255
	{
		if (_i2cPort->available() > 0)
			return (true);
		delay(1);
	}

	if (_printDebug == true)
		_debugPort->println(F("I2C timeout"));
	return (false);
}
Now I may be completely out to lunch (or maybe dinner ;) ) but I don't get this function?

I believe that the requestFrom will wait for the conversation to be complete? And returns how many bytes were received over I2C.
And the read functions, indexes into this from 0 to the number o bytes received in requestFrom. And more specifically available() simply returns the count of how many bytes were transferred during the requestFrom minus the index used in the read function.

So more specifically if: if (_i2cPort->available() > 0)
fails once (i.e. available == 0), it will continue to fail every call through that counter... i.e. there is nothing still active receiving data from the device that increments some counter?

So in the case of the failure I was seing where the Start Read fails with NAK, I believe the count would be 0...

So again maybe missing something obvious...
 
@KurtE
I think its effectively acting like a delay. Just guessing.

I had used my delay version with their waitfori2c function still in but I removed all the delays I had put in I hope and changed the loop limit to 225 and it seemed to work. So I put their lib's version in and retested with 225 and it gave me problems so maybe I had something else it so.... I just repeated the test with the their delay (waitfori2c) changed to 125 and all the sketches I tested up through 528Mhz clock seemed work out of the box for the 7 sketches I tested.
 
@KurtE - @PaulStoffregen

Starting with a fresh copy of the sparkfun BNO080 library and just adjusting the count in the waitForI2C() function found a couple of things:
  1. 600Mhz seems to be problematic - seems this is where I keep getting hangs and the sketches hit or miss if they hang or have to reload the sketch.
  2. If I reduce the clock to 528Mhz and change the count from 100 to 130 it seems to get it working at least for me.
  3. Did the testing with 7 sketches from the examples folder: Example1, 2, 3, 4, 12, 13, and 15.
Going to go back and add in some delays and see if I can get it working somewhat reliably at 600Mhz. I will update this post in a little bit.

UPDATE: Further testing to get to work at 600Mhz.
  1. All changes were made to the receivePacket function in the .cpp file.
  2. Delays were added after the requestFrom requests
  3. getData function was merged with the receivePacket function - so getData function no longer needed.
  4. also deleted one call to waitfori2c and replaced it with delaymicoseconds(100);
  5. changed count in WaitForI2C from 100 to 240
  6. I am using KurtE's wire fork for testing
Only sketch that gave a bit a problem was Example 1- RotationVector, had to change
Code:
  if (myIMU.begin() == false)
  {
    Serial.println("BNO080 not detected at default I2C address. Check your jumpers and the hookup guide. Freezing...");
    while (1);
  }
to just
Code:
myIMU.begin() ;
which actually matches all the other sketches.

Attaching modified file.
 

Attachments

  • SparkFun_BNO080_Arduino_Library.zip
    9.7 KB · Views: 126
Last edited:
@KurtE - @PaulStoffregen

Evening all. Eh - just retested with the BNO055 and it stalled after a few seconds running the sensorapi.ino sketch and had to use the 15sec restore to get it working again. The restore_offsets.ino sketch got to the point where I got to:
Code:
Fully calibrated!

--------------------------------

Calibration Results:
then it stalled but this time was able to load other sketches.
 
Many thanks to KurtE and mjs for continued work on this. I hope it has helped clear other i2c related issues. I timed out for a while, and continued my application with MPU9250. However, due to matching pinouts, I now have a hard PCB which allows for configuration with either MPU9250 or BNO080. I've also connected the 080 interrupt pin to the Teensy. I hope I can return and contribute.

I'd like to try the improvements you guys have produced. The improvements to the 080 driver is straightforward, but I'm not as clear on the Teensy i2c improvements. Do you recommend modifying the named Teensy i2c .cpp/.h files, or have the changes been pushed upward to the full Teensy stream?
 
Sorry for showing up so late to this party. Just wanted to let you know I purchased a BNO080 from Sparkfun. It's on my desk now.

DSC_0669_web.jpg

I'm digging into the low level details. Hope to have an answer soon.
 
@PaulStoffregen
If I am looking at the circuit right you have a resistor going from gnd to 3.3v on one side and a diode from the gnd to gnd. Why - power filter vs using a CAP? I can read the resistor but not what diode you are using. Learning exercise for me on that one?
 
a resistor going from gnd to 3.3v on one side and a diode from the gnd to gnd. Why

This raises the BNO080's GND voltage by about 0.4V about Teensy's GND. So when viewing the waveforms on my oscilloscope, I can see which chip is pulling the signal low.

At least some of the problems involve multi-master arbitration being mistakenly triggered, so which chip is doing what matters.
 
Thanks Paul. Good to know if I ever have to do some trouble shooting. If I remember right you taught me some about using a scope on i2c during some debugging on an Arduino issue years ago :) Guess you never stop learning.

Just out of curiosity do you see the problems at lower clock speeds as well? Are you using the Teensyduino version of the Wire library?
 
I'm seeing the BNO080 do all sorts of very wrong things after that first sendPacket to reset it, including driving the SDA pin low right in the middle of a bit time where Teensy is transmitting. Some of those cases put Teensy 4.0's I2C hardware into states that aren't currently handled by the Wire library code. The Wire lib on Teensy 4.0 isn't yet robust enough to handle and recover from all those things. I'm working on it now. Will probably take me a couple days.
 
@Paul - Sounds good. As we mentioned we were seeing lots of strange results like you mentioned. So will be looking forward to see what all you fix on it.
 
Ok, one final followup, now that Teensyduino 1.49 has been released.

As far as I know, 1.49 solves all the known problems we were seeing with BNO080. Unless I hear more reports of trouble, I'm considering this problem solved and no longer following this thread.
 
I downloaded 1.49 beta #5 yesterday. I had no problem running all of the example Sparkfun BNO080 programs. Thanks very much to all who have contributed to the resolution. I hope the work has helped to clear up other I2C concerns.
 
Hi guys, is there anyone that have used the bno080 on the teensy 4.0 and the bno080 is not even detected by the i2c scanner ?

I have two bno080 and feels like they are both frozen in some sort of undetected status.

Thanks
 
Hi guys, is there anyone that have used the bno080 on the teensy 4.0 and the bno080 is not even detected by the i2c scanner ?

I have two bno080 and feels like they are both frozen in some sort of undetected status.

Thanks
Short answer is yes. Several of us have tested the BNO080 in I2C mode. There was an issue but as Paul mentioned in post #71 that has been fixed since Teensyduino 1.49. We are up to 1.53 (latest). With out further information its hard to speculate, like whats your hook-up, what breakout board are you you using, etc. First I would check the wiring and run the scanner that is under examples in Wire.
 
on the teensy 4.0 and the bno080 is not even detected by the i2c scanner ?

I have a BNO080 sitting right here. I ran File > Examples > Wire > Scanner on a Teensy 4.0 just now. Here's the result.

bno080.png

The Scanner example definitely does find it. BNO080 definitely does work with Teensy 4.0.


If you're getting nothing detected by the scanner, something is probably wrong with your hardware. We can help you try to find & fix the problem, but if unless you show us photos that help is only going to be blind guessing.
 
Status
Not open for further replies.
Back
Top