Doing to much?

I am fairly certain the answer is no but perhaps someone can tell me what I am doing wrong…

I have a arduino(Adafruit Feather 32u4 to be specific) collecting weather and power data(wind speed,temp,humidity,volts2,amps2) which then talks to a remote Feather 32u4 over a rf69 radio at 900mhz which it then asks it for its battery info(volts,amps)

The power info is handled by 3 adafruit ina219 breakout which communicates by i2c.

All of my data is sent to a Raspberrypi every 5min by i2c which is initiated by the pi I also have an RTC that communicates over i2c to the pi.

Problem is randomly between 10min-3days the MAIN arduino stops responding to everything

So as far as the Arduino is concerned the Pi could ask for data at any point in the code execution the arduino cannot stop monitoring the Annemometer(wind speed) rotations as this would make for false wind speed data which is the main point.

so the arduino has an interrupt pin, and an interrupt timer as well as a watchdog timer… in addition to i2c calls… so is that to many interrupts? I am fairly certain that the issue resides with the way I am handling i2c by the pI

I am open to ideas about more reliable communication this thing needs to work for 6months on a remote site.

Basically I have a camera on a remote site that needs to record every time its windy and I also need to monitor the current weather. the Pi exists as a database server and as a VPN client to access the cameras over the LTE network

getData.c is the i2c request script from the pi that chron runs every 5min
Weather_i2c_Radio is the Main arduino unit
Remote_Cam_RX is the remote arduino unit

getData.c (5.78 KB)

Remote_Cam_RX.ino (5.52 KB)

Weather_i2c_Radio.ino (17.9 KB)

Problem is randomly between 10min-3days the MAIN arduino stops responding to everything

I looked over only the code for MAIN, and it does not look too complicated -- certainly it is unlikely that there are "too many interrupts".

On the other hand, you have a lot of libraries of unknown reliability contributing (with radio libraries being in general problematic), and just about anything could be hanging.

Why doesn't the watchdog timer reboot it when it hangs? Do you have the fuse set properly?

There is a known problem that, if the I2C does not respond properly, or a byte is not received properly, the I2C code will hang, waiting for the byte that never comes. I have often wondered why the I2C library was not modeled after the Stream class...

Fortunately, there is a fairly stable replacement here. That's the first thing I'd try.

jremington: I looked over only the code for MAIN, and it does not look too complicated -- certainly it is unlikely that there are "too many interrupts".

On the other hand, you have a lot of libraries of unknown reliability contributing (with radio libraries being in general problematic), and just about anything could be hanging.

Why doesn't the watchdog timer reboot it when it hangs? Do you have the fuse set properly?

I am currently right now trying to figure out why the watchdog doesn't reset it... I also thought I might just get the pi to reset the whole thing every 5min when I do the i2c dataread... I reset a lot of it to zero at that time anyhow lol.

Also if I put a delay in the code for 10seconds the thing does reset so the watchdog works, no idea why it doesnt reset when whatever happens, happens.

as it turns out if USB is plugged in the watchdog timer does not reset... it will also not reset if USB was ever plugged in prior to a power loss... so when I tested it I had disconnected USB and re-powered board but during normal testing on bench I was leaving USB plugged in

Guess the 32u4 relies on disabling the watchdog for usb functions?

I will now see how reliable it is with the watchdog reset working... cause honestly if it works 99x out of 100 and requires a reset every so often thats fine by me... would be better if it didnt but i2c is annoying me enough id be fine with that :p