Forum Rule: Always post complete source code & details to reproduce any issue!
Page 3 of 3 FirstFirst 1 2 3
Results 51 to 72 of 72

Thread: Sparkfun BNO080 - Teensy 3.6 >> 4.0

  1. #51
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,994
    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...

  2. #52
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,524
    @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?

  3. #53
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,994
    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...

  4. #54
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,524
    @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.

  5. #55
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,421
    Quote Originally Posted by mjs513 View Post
    Code:
    boolean BNO080::waitForI2C()
    {
    	for (uint8_t counter = 0; counter < 225; counter++)
    Is that the kind of thing that will get optimized away as a NOP? Also vary wildly with F_CPU

  6. #56
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,524
    @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.

  7. #57
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,524
    Quote Originally Posted by defragster View Post
    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?

  8. #58
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,421
    Quote Originally Posted by mjs513 View Post
    @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.

  9. #59
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,994
    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...

  10. #60
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,524
    @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.

  11. #61
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,524
    @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.
    Attached Files Attached Files
    Last edited by mjs513; 12-30-2019 at 02:30 PM.

  12. #62
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,524
    @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.

  13. #63
    Junior Member
    Join Date
    Nov 2019
    Posts
    9
    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?

  14. #64
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,138
    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.

    Click image for larger version. 

Name:	DSC_0669_web.jpg 
Views:	12 
Size:	185.7 KB 
ID:	18617

    I'm digging into the low level details. Hope to have an answer soon.

  15. #65
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,524
    @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?

  16. #66
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,138
    Quote Originally Posted by mjs513 View Post
    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.

  17. #67
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,524
    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?

  18. #68
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,138
    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.

  19. #69
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,994
    @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.

  20. #70
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,138
    I've uploaded Teensyduino 1.49-beta5 with major improvements to how the Wire library manages the I2C FIFOs on Teensy 4.0.

    https://forum.pjrc.com/threads/59030...no-1-49-Beta-5

    Please give it a try and let me know how it works for you?

  21. #71
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,138
    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.

  22. #72
    Junior Member
    Join Date
    Nov 2019
    Posts
    9
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •