32u4 watchdog fails with BNO080 with no bootloader

Hi All,

I have a minimum circuit with a BNO080 imu connected to a Atmega 32u4, I have had to remove the bootloader due to memory constraints. Due to failsafes I want to enable the watchdog to reset the board if needed, However when I do this the watchdog disables the chip but it does not come back up.

If i re-enable the bootloader it works fine, I thought i must be an issue with the fuses but using the fuse calc it states they should be fine?
L: FF
H: DF
E: FB
I can reproduce this with the following code:

#include <Wire.h>
#include<avr/wdt.h> /* Header for watchdog timers in AVR */

#include "SparkFun_BNO080_Arduino_Library.h" // Click here to get the library: http://librarymanager/All#SparkFun_BNO080
BNO080 myIMU;

void setup()
{
  Serial.begin(115200);
  Serial.println();
  Serial.println("BNO080 Read Example");
 
  Wire.begin();

  myIMU.begin(0X4A); 
  Wire.setClock(400000); //Increase I2C data rate to 400kHz 
  myIMU.enableDebugging(Serial);  

  myIMU.enableMagnetometer(100);
  myIMU.enableAccelerometer(25);
 
  wdt_enable(WDTO_8S);  /* Enable the watchdog with a timeout of 2 seconds */ 
}

void loop()
{
  //Look for reports from the IMU
  if (myIMU.receivePacket() == true)
  {
    myIMU.printPacket();
  }
}

If I remove the IMU commands it runs as it should. could this be the IMU holding the I2C bus or something?

Thanks for any insight
Spriggsy

That is very, very strange. What is taking up all that memory?

I've used the BNO055 with memory left over, on a 16K ATmega168 board. The only library needed is Wire (and not even that, if you use simple calls to the I2C hardware).

If all you want is orientation sensor data, there are many other choices, most of which perform much better than the old Bosch products, and require very little Arduino memory.

This is a very large project, taking in IMU readings/NFC/bty management, gps, gpio plus a oled screen and handing the readings over usb hid to a android device. unfortunately we have had custom boards made so are stuck with what we have, but mission creep has expanded what we originally wanted from the board,( What the Boss wants compared to what the Boss needs!).

The code above is the minimum that will cause the issue, and unfortunately The BNO00 cant be removed from the project

Why not use a micro with more memory? In the AVR series the Mega2560 or ATmega4809 (Nano Every) are obvious possibilities.

an ideal way would be to poss use the RP2040 but we already have the boards made and in a product

As for the watchdog problem, just enabling it is not enough. You have to make sure that the reset vector points to your code, and not the bootloader section.

I don't recall the details, though. The ATmega32U4 datasheet has the information you need.

Thank you for the hint, I thought that was what the fuses where for?
Ill dig through it late

So after a day of testing various things I have concluded the following

Standard Catrina bootloader: watchdog works fine, it resets after the time out and the BNO080 continues to work

No boot loader: crashes when the watchdog times out, reset btn non functional

ubaboot bootloader (GitHub - rastersoft/ubaboot: USB bootloader for atmega32u4 in 512 bytes) crashes when the watchdog times out, reset btn non functional

kp_boot_32u4 (GitHub - ahtn/kp_boot_32u4: driverless, 1kb bootloader for atmega32u4, with support for writing flash and eeprom): crashes on watchdog time out and hangs, however reset btn does reset back to bootloader.

I guess that the original arduino bootloader is resetting the I2C bus somehow that the other methods arn't doing?

There is no reason that RESET can't start your program properly. You are probably running afoul of Arduino IDE expectations for a bootloader, or incorrect fuse settings.

My approach would be to examine flash memory to see where the reset location is pointing, and look for the loaded program start address. It is possible to get a complete memory map of the program load module.

This was never a problem when using Atmel Studio to develop code, and it has been a long time since I've had to do something like that with Arduino, so I can't provide the details off the top of my head.

I don't understand what you mean by this comment:

If I remove the IMU commands it runs as it should.

Do you mean that the RESET starts the program correctly in that case? If so, something else is very wrong. If not, please describe in detail what actually happens.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.