mbed-events breaks Timeout on STM32F4

[DavidPowell]

Description

• Type: Bug
• Related issue: equeue_mbed problem with sleep mbed-events#16
• Priority: Major

---

Bug

Target
STM32F4

Toolchain:
GCC_ARM

mbed version:
Revision 131 (bundled with platformio)

Expected behavior

Using Timeout to creating a callback to turn off a pin after 50us, I expect to see the pin turn off when looking with an oscilloscope. I am create an EventQueue from mbed-events, which is not expected to interact with the Timeout.

Actual behavior

On NUCLEO L053R8: The callback turns off the pin after 78us
On NUCLEO F401RE , the pin goes high, and stays high. Debugging with GDB indicates that the callback never gets called. (same behaviour on Discovery F4 after changing my_pin to a valid pin for this board)

Replacing the call to queue.dispatch() with while (1) {} means that the callback is now called properly on both targets. This suggests that some code called by the queue is blocking interrupts.

The issue has some similarities to ARMmbed/mbed-events#16, where the sleep() function in the HAL is a suspect. Since the behaviour depends on the target, I have raised the issue here, where all target dependent code lives

Steps to reproduce

The following example code illustrates the problem:

#include "mbed.h"
#include "mbed_events.h"

DigitalOut my_pin(D2);

void pin_off(void)
{
  my_pin = 0;
}

EventQueue queue;

int main(void)
{
  printf("starting\n");
  Timeout to;
  while (1)
  {
    my_pin = 1;
    to.attach_us(pin_off, 50);
    //while(1) {};
    queue.dispatch();
  }
}

[0xc0170]

cc @bcostm @adustm @LMESTM @jeromecoutant

[bridadan]

May also be of interest to @geky

[geky]

Hi @DavidPowell, thanks for raising the issue and example. Looks like this was a simple bug in the non-rtos port of mbed-events.

Interestingly, it wasn't an issue with critical sections, but actually an unchecked overflow when the event queue tries to create a timeout before going to sleep. This line didn't check for -1, which is used in mbed-events to represent an infinite wait/dispatch:
https://github.com/ARMmbed/mbed-os/blob/master/events/equeue/equeue_mbed.cpp#L127

The result was a timeout with some ridiculously large delay, which would mostly work on platforms (for ~50 days). Oddly enough it seemed to kill any other timeouts on the STM32F4 boards.

Raised a pr here #3550 and ARMmbed/mbed-events#27, let me know if that doesn't fix the problem.

[DavidPowell]

@geky Thanks for the fix. I applied it manually, and confirmed that it solves both the problem both in my example code above, and in my real code.