SparkFun Thing Plus NINA-B306, logging IMU data to the onboard microSD at around 140 Hz. The sketch stops dead after anywhere from 3 seconds to 7 minutes - the status LED stops blinking, serial output stops, and the log file ends. No error message. Sample timing in the file is completely normal right up to the moment it stops, with no slowdown beforehand.
It happens with a SparkFun SAM-M10Q GPS breakout attached over Qwiic, and also with a minimal sketch using only the onboard ISM330DHCX and the SD card, with the Qwiic cable unplugged. Runs tend to get shorter across a session and are longest after the board has been off overnight. Battery reads 4.1 V throughout and the board does not get noticeably warm. SD card is a SanDisk Extreme 32 GB, FAT32.
I don’t know anything about what you are doing here but this stands out.
That sounds like a temperature problem.
But you say
The word “noticeably” might be a bit of a clue. There still might be a component that is getting hot that you haven’t noticed. Although if one component is behaving like this it tends to be noticed when it burns a hole in your hand.
You could try one thing. Wrap the whole thing in a couple of bags of frozen peas or something and see if that extends the operating time.
It could be something like a bad solder joint that fails when it gets warm. Could fail with a moderate temperature rise that you might not think excessive.
You could also quickly run over the boards with a warm air jet. You would need to do this at first switch on to get max run time and carry out the experiment quickly.
Cheers Bob
As for the noticably warm part - with some re-tests recently, I really do not notice any difference in temperature.
Interestingly, I have found that if I power on the SparkFun Thing Plus NINA-B306 and disconnect the GPS device - the device will run with no issues indeffinitely - have tried swapping the Qwiic cables that connect the two parts with no change.
I have tried 3 tests with the GPS connected Test 1 ~363s, Test 2 ~ 137s, Test 3 ~28s, Test 4 (With Ice gel pack underneath) ~ 142s
So it does improve quite a bit when cooled. Interesting, could be a clue there.
One other thing. Like I said I don’t know anything about what you are doing but would you have something in your communications like a clock conflict. If you don’t have the same clock for timing would there be a possibility that one gets a bit out of sync with the other and this gets progressively worse until everything just stops. This could be somewhat heat sensitive if one oscillator is getting a bit warmer than the other thus changing the actual error.
Without having all this on a bench in front of me with some nice test instruments I am afraid i really don.t know what to do remotely. The fact that all works without the GPS connected suggests some sort of conflict but one would have to see it or be able to reproduce the problem to say what the problem is with any certainty.
Have you or can you try the hot air sleuthing method. A bit difficult if you have not got a fairly fine device, preferably with some temperature control so you don’t destroy anything.
Cheers Bob
Not sure on how this is coded, but I would check the fat file system settings and ensure files are closed off correctly.
On micro controllers often max fat files is 5 by default, meaning you can have 5 handles to open files and everything is working fine, but the 6th will have issues.
I run into this a while back (very different board/project) where If I refreshed my webpage too fast it would lock up, but slower refreshing was OK. this was mainly due to things timing out and handles getting released before I requested a new one on the next file open.
If the system simply uses 1 file hander for ALL writes, then this should not be the issue, but if it re-opens on every write, then the old handles need to be released prior to that.
edit:
Then there is the the SD card overhead as per this google ai response
