I'm getting the following dump on the serial port (USB) (sorry, copy/paste somehow doesn't work from the serial console, so please see the attached image). I'm going to try to avoid adding a lot of extra code - but here's a short version of the code segment(s) that fail:
int isTime(unsigned long *fromMillis, unsigned long maxMillis) {
unsigned long n=millis();
Serial.println("isTime called");
if ((n - (*fromMillis)) >= maxMillis) {
// Time expired - do action
*fromMillis = n; // Reset Count
return true;
}
return false;
}
void loop() {
static unsigned long sensorTime = 0;
static uint16_t dist=100, strength=5000;
if (isTime(&sensorTime, 100)) {
dist = tfmini.getDistance();
strength = tfmini.getRecentSignalStrength();
}
}
That's it - the code fails in "isTime" when called from the function above (the assignment of *fromMillis seems to be it). This function is called A LOT and I only see it called once using debug statements. running this code segment directly in gcc works just fine:
#include <stdio.h>
#include <stdbool.h>
#include <time.h>
#include <stdlib.h>
long long gettimeofday_ms() {
struct timespec ts;
clock_gettime(CLOCK_MONOTONIC, &ts);
long long ms = ts.tv_sec*1000LL + 1e-6*ts.tv_nsec;
return ms;
}
bool isTime(long long *fromMillis, long long maxMillis) {
long long now=gettimeofday_ms();
if ((now - *fromMillis) >= maxMillis) {
// Time expired - do action
*fromMillis = now; // Reset Count
return true;
}
return false;
}
long long waits[] = {200,600,1200,5000,2000};
void main() {
long long now = gettimeofday_ms();
for (int i=0;i<5;i++) {
while (!isTime(&now, waits[i])) { };
printf("Wait %d is complete - was %ld. ms=%lld\n", i, waits[i], now);
}
}
Outside of the call to millis() being replaced by standard C's time feature, this works. I know "millis()" returns unsigned long, so no "long long" is required.
Does anyone see what I fat-fingered wrong here?
Update - no go on the EspExceptionDecoder - it requires "rather old" python and ncurses libraries - Fedora 32 finally got rid of Python2, now 5 (I'm pretty sure) years after it was deprecated. So all I get is a prompt of an ELF binary which most likely is the python2.7 executable.
That said - I've noticed the stack trace comes before the setup() debug statement. But since I can add more statements before the one I pointed out and they are all output after the stack-dump it seems like a buffer issue to me. Clearly the unit is resetting due to a software error. I can run other code on the Wemo D1, from "blinky" to more complex code. So it's not a hardware issue.
