We are posting a signal using isr_send_signal() from an isr at priority level 14. When the interrupt is being triggered repeatably an error condition eventually occurs in which the signal does not reach its destination task. Using hooks we have determined that the problem is an imbalance of the isr signal queue counters.
We are using the older RTX166 OS v4.00. If anyone could provide some insight it would be greatly appreciated.
I have no idea what you mean by signal queue counters. As far as I know, there is only the signal flag of the task. Anyway, I have also had problems with isr_send_signal. To me it looked like if you have more than one isr where you call this function, a signal may be lost. Apparently when a call is interrupted by a higher priority isr which also calls isr_send_signal.
I solved it by constructing my own event queue. Instead of calling isr_send_signal, I add an event to this queue. When the event is added, a low priority interrupt is also triggered. It is this low priority interrupt which calls isr_send_signal to wake up a task which reads the event queue. The task reads the event codes in the queue and sends corresponding messages to the tasks which are supposed to handle the events. The disadvantage is that an extra task is required to read the queue and also an extra task switch before the event is handled. The advantage is that it works and that the task handling the event can handle many different events in the same loop (a task can't wait for a signal and a message simultaneously in RTX166).
Since I had all my isr:s and the add of an event to the queue written in assembler, the isrs exequted quite fast. No need to save and restore all registers for the isr_send_signal call, and adding the event to the queue is also faster than the isr_send_signal function call.