Echelon Neuron C - Manual (Page 176)

164 Additional Features
Figure 15. Interrupt Latency
As the figure shows, the first (in source-code declaration order) interrupt task
always has the minimum latency and no jitter. If the application includes more
than one interrupt task, a subsequent interrupt task experiences a number of
clock cycles of latency, depending on the interrupt type and whether other
interrupt tasks must run before it can be dispatched.
For a typical application, no more than two interrupts are pending at any one
time, so that either no other interrupt task, or just one interrupt task, needs to
run before the current interrupt task is dispatched.
Debugging Interrupt Tasks
You cannot use the NodeBuilder debugger to debug an interrupt task or any code
called from an interrupt task. That is, you cannot set a breakpoint within an
interrupt task or in a function that is called from an interrupt task. If you
attempt to set such a breakpoint, the device logs a system error, resets, and
comes up in the soft-offline state. If the reset clause re-enables interrupts before
the device can go offline, the debugger might lose communications with the
device, and thus need to set the device applicationless.
You can debug your code using application-specific debugging tools, such as
dedicated global variables to track states or events, or application-specific output
through a suitable I/O model. You could also run the code-under-test from a
when task for testing and debugging purposes.
When sharing data between an interrupt task and the application, you cannot set
a breakpoint on the __lock statement itself, but you can set breakpoints within or
outside of the lock. However, if an interrupt trigger condition is met while the
application is halted at a breakpoint within a lock, and the interrupt task tries to
acquire a lock, the Neuron Chip or Smart Transceiver watchdog timer will time