Application Watchdog & Atomic Blocks

Troubleshooting
1

I’ve been having issues with a P1, I2C Port Expander (MCP23017), and I2C display, where communications are messed up (display misprints, and port expander randomly turns on the incorrect pins).

This issue pointed me towards task switching being at the heart of the problem. I added atomic blocks to limited I2C code, and it seems to have resolved the issues. However…

I’ve been running an application watchdog in my firmware, and it’s no longer working now that I’m using atomic blocks.

So, my question:

After Atomic Blocks have disabled interrupts and thread switching, how do they reenable them? And would an application watchdog be reenabled?

Thanks!

2

I’d rather try SINGLE_THREADED_BLOCK before opting for the nuclear option of ATOMIC_BLOCK.

ATOMIC_BLOCK just masks the interrupts it doesn’t detach them.

3

Interesting, I just moved on from the DS18B20 and have now added the MCP23017 to my project; I am also planning to use the WDT eventually. Scruff, you are aware of the issues we found with OneWire that seems to be blocked/solved using Atomic Blocks, but only for non-mesh enabled devices.

The OP’s question and your answer brings up these related questions:

  1. Homemalster, are you using a mesh device AND actually enabling mesh?

  2. I haven’t looked yet at WDT but i understand it is a system software type function and not a true hardware implementation. Is there a “critical window” for recognizing a WDT trigger action that is possibly missed entirely through the use of Atomic Blocks? I understand that Atomic Blocks are not ideal, but some users will find their use necessary in some applications. Could that make the WDT unusable for them?

  3. The OP points to a long dormant thread (regarding corruption/errors during critical I2C windows) that has been closed and seemingly solved for those chasing that issue back in 2015. Should we assume that that issue WAS solved?

4

@ScruffR Ok, thanks. I’ll try out SINGLE_THREADED_BLOCK and see if it changes anything.

So perhaps it’s not a block that is preventing my application watchdog from working? I’ll start eliminating other potential issues after trying out the SINGLE_THREADED_BLOCK to see what I can find - but are you aware of any common problems that allow an application watchdog to compile, but not function? Perhaps that’s too vague of a question…

5

@Jonpcar - I'm not using a mesh device with enabled mesh. I'm running on a P1.

I'll echo your 2 questions - I'm not sure of answers, and would love to help find them.

& could the corruption during critical I2C windows have returned, or be occurring in a new rendition? Or am I just seeing a similar issue caused by a different bug in my own code?

6

I have my reservations agains Application Watchdog as it usually also gets tickled by the system when you drop out of loop(), call Particle.process() or even delay().
Hence I haven’t found it too useful as a watchdog entirely (IMHO).

2 Likes