This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

RTX, MessageQueue, Realtime desaster

We have four identical µC systems based on STM32G081, running same, identical firmware.
They receive commands via one, single RS-485 bus.
One job is switching a GPIO pin from on to off.
UART interrupt has highest prio (0), consuming task has highest prio (realtime).
Occasionally one or more system (see LA pictures) are delayed.
Delay is always the same (@24 MHz 3.7 ms, @ 64 MHz 1.8 ms).

May someone help in what is blocking the consuming task ?

Best regards, Juergen

Parents
  • It turned out that it is/was a synchronizing problem between the four units.
    We thought having this eliminated by inserting a 'osDelay(1) before switching the outputs off.
    But osDelay seems not to work if the task calling osDelay is the only task currently running:
    The scheduler will not switch to idle task for 1 ms, but instead will run the calling task without delay.
    We now use __NOP() and that works.
    So the case can be closed.

Reply
  • It turned out that it is/was a synchronizing problem between the four units.
    We thought having this eliminated by inserting a 'osDelay(1) before switching the outputs off.
    But osDelay seems not to work if the task calling osDelay is the only task currently running:
    The scheduler will not switch to idle task for 1 ms, but instead will run the calling task without delay.
    We now use __NOP() and that works.
    So the case can be closed.

Children