How can I cause the VM to reset the (code running too long) Watchdog?

Hi,

I've updated my HRV Analysis app to allow much longer run times which in turn needs a larger buffer. I've managed to reorder some code and optimise it to avoid watchdog timeouts from the code executing too long except in one instance.

I am attempting to write out the interval data to the log file (has historically no issues when the buffer is shorter) but now have a watchdog timeout on the simulator. I've read somewhere that the VM is called when a function is accessed so I partition the writes into short "bursts" via a separate function called in a loop.

This doesn't work.

So my question is what system calls or operations will force the VM to reset the watchdog timer???

Thanks,

David  

  • The watchdog resets when you return from something like onUpdate(), onTimer(), compute(), etc, not when you call call a function in your code.

    It's to prevent your code from running too long without returning to the VM.  

    With large data sets you may need to rethink how you do things in a bigger way.  Let's say you have an array that's 5000 elements long.  If you want the average, you could figure it out each time, or you could keep a running average - when you add something new, you know the previous average and number of elements, so you just factor in the new one and not recalculate using all the elements.

    Or you do things based on a timer - when the timer ticks, do the first 100, next timer tick the second 100, and so on,

  • Hi Jim,

    Thanks for getting back. I was hoping the VM might get called when any system function is used eg Sys.println(). I appreciate why it's there but I'm pushing the limits of the device somewhat. My processing is done sample by sample to avoid the issue you gave as an example. I'm simply trying to get the data off app and into a TXT file in onStop().

    It looks like I'll have to try restructuring the code to write the data after every test rather than on exit and use a timer to push packets out. Then run into the issue of async events if teh user starts a test while the write is still in progress - though I could add more code to stop this. On smaller devices I'm already a few hundred bytes away from the app crashing due to lack of memory. I am also trying to avoid splitting the code base. 

    I use the jungle for picking up limited code/settings/parameters but want to avoid doing this for significant chuncks of code as this becomes unmaintainable.

    Question. I've not yet worked out how to have...

    1. Set of base excludes that apply to all devices (done)

    2. Have a set of device specific excludes (can do this)

    3. (the bit I haven't worked out) Have an exclude that applies to all the other devices that are not in (2) but are supported by the app WITHOUT having to add an entry for every supported device.

    Ideas welcome.

    Regards,

    David

  • 1. Set of base excludes that apply to all devices (done)

    2. Have a set of device specific excludes (can do this)

    3. (the bit I haven't worked out) Have an exclude that applies to all the other devices that are not in (2) but are supported by the app WITHOUT having to add an entry for every supported device.

    Assuming that you already have an "excludeAnnotations" entry for every single device in 2), here's an example.

    The idea is if you override excludeAnnotations for a given device, you don't have to include the content of base.excludeAnnotations.

    # all devices
    common_excludes = excludeA;excludeB;excludeC
    
    # all devices except those explicitly listed (e.g fenix6, vivoactive3)
    base.excludeAnnotations = $(common_excludes);excludeD
    
    fenix6.excludeAnnotations = $(common_excludes);excludeE
    vivoactive3.excludeAnnotations = $(common_excludes);excludeF
    

  • I'm not Jim lol but you're welcome anyway.