NRF52 Queue timer issue when built with release profile

Description

• Type: Bug
• Related issue: Ticker issues with NRF52 platform, especially while using event queue call_every timer function. #4893, mbed-os-example-blinky breaks on NRF52_DK when NDEBUG set #4621
• Priority: ?

This might be duplicate, but it's hard to say.

---

Bug

Target
Nordic NRF52

Toolchain:
GCC_ARM

Toolchain version:
6.x
mbed-cli version:
1.2.0

mbed-os sha:
99a8467 (current master)
db4be94 (5.5.5 tag)

DAPLink version:
How do you find out? does it matter?
Expected behavior
I expect the llights to start on (on startup) then turn off for X milliseconds once the interrupt is fired and then turn back on again.
Actual behavior
When compiled via the debug profile all is well, but on the release profile it acts like so:

Lights start on, then the interrupt fires, lights go off, then on for a fraction of a second, and stay off and the logic becomes reversed as the interrupt now turns the lights on for a fraction of a second and then off.

here's the relevant code snipped.

void onAgain(void)
{
    toggleLights(true);   // is just two DigitalOut set to  true|false 
}

void onImpact(uint8_t zone)
{

    if (gameServicePtr->isGameActive() || !gameStartRequired) {
        gameServicePtr->updateAdvPayload();
        gameServicePtr->updateHitCounter(zone);
        toggleLights(false);

        eventQueue.call_in(MBED_CONF_APP_LIGHTS_BLINK_TIME, onAgain);
    }
}

void sensor1PressedCallback(void)
{
   eventQueue.call(Callback<void(uint8_t)>(onImpact), 1);
}

void sensor2PressedCallback(void)
{
    eventQueue.call(Callback<void(uint8_t)>(onImpact), 2);
}

int main() {
    initLights(!gameStartRequired);

    BLE &ble = BLE::Instance();
    ble.onEventsToProcess(scheduleBleEventsProcessing);
    ble_error_t error = ble.init(bleInitComplete);
    if (error != BLE_ERROR_NONE) {
        ble_print_error(error, "BLE initialisation failed");
        return 0;
    }


    sensor1.fall(eventQueue.event(sensor1PressedCallback));
    sensor2.fall(eventQueue.event(sensor2PressedCallback));

    eventQueue.dispatch_forever();

    return 0;
}

Excuse the poor code, I'm still learning C++.

There are a lot of nrf* timing related bugs; do they share a root cause?

[0xc0170]

cc @pan- @nvlsianpu @anangl

Is it possible that this is related to the SLEEP support? If so, will tickless help?

[pan-]

How do you find out? does it matter?

Use mbedls, it will return the version of the interface firmware running on your board. Indeed it matters.

When compiled via the debug profile all is well, but on the release profile it acts like so:

So if I understand correctly it works fine with the debug profile but not in release.

Could you try in release with the following code:

void dummy_idle() { } 

int main() {
    Thread::attach_idle_hook(dummy_idle);
    // rest of your code ...
}

The goal is to test if it is the use of sleep which disturb the event queue.

Last question, what is the value of MBED_CONF_APP_LIGHTS_BLINK_TIME ?

MBED_CONF_APP_LIGHTS_BLINK_TIME is either 500 or 1000 depending on what i'm doing. It's definitely always >= 500ms.

The daplink firmware is 0242.

adding the example code did indeed fix it, although the board can't seem to auto reset now. I see this occasionally, but never 3 times in a row like this.

[mbed] Detected "None" connected to "/run/media/johnny/DAPLINK" and using com port "/dev/ttyACM0"
[mbed] ERROR: Unable to reset the target board connected to your system.
[mbed] ERROR: This might be caused by an old interface firmware.
[mbed] ERROR: Please check the board page for new firmware.

I guess the problem is sleep.

[pan-]

@jrobeson Thanks for the feedback. From the sounds of it, sleep in the idle loop is the offender. Either it is a latent issue in the eventQueue or sleep on NRF52 is broken. You can get version 0243 here

@nvlsianpu Looking at the sleep code, the value of SCB_ICSR_RESERVED_BITS_MASK seems wrong according to the ICSR documentation. I might have done a poor job here. Could you confirm ?

The code is also full possible of race condition. In an RTOS world, the idle thread can be preempted at any time and re scheduled at a later point which. The sleep code exposed as it is now is supposed to be executed in one block. It might be hard to put a critical section there for the softdevice path but it should be OK for the non softdevice path.

Last point, do you know if sd_app_evt_wait interfere with the SysTick ?

[pan-]

@jrobeson After looking at that thread on Nordic forum it appears that going to sleep stop the SysTick therefore it screw all timing related operations of the event queue.

Tickless mode will help when it gets in (see #4956). If your not using directly the OS primitives in your application, could you try your code, in release mode, with the RTOS disabled via a .mbedignore file and give us the results ?

directly? the eventqueue itself seems to require the the rtos, so I guess I am?

I had to search on how to disable the rtos btw. The docs for .mbedignore don't really clarify which parts, so I had to go elsewhere.

[nvlsianpu]

Looking at the sleep code, the value of SCB_ICSR_RESERVED_BITS_MASK seems wrong according to the ICSR documentation. I might have done a poor job here. Could you confirm ?

This value should be set to 0x98403F03F
edit:
This value should be set to 0x94403F03F

pretty sure I can update the daplink firmware because it requires this: ARMmbed/DAPLink#178 so I'm using the latest from here: https://github.com/redbear/nRF5x/tree/master/nRF52832/daplink

I tried changing SCB_ICSR_RESERVED_BITS_MASK to 0x94403F03F , but it didn't change the behavior.

[pan-]

@jrobeson Can you try with the latest master (or at least include #4991 and #5063) ? I've read the thread again and realized you were using a red bear lab MCU.

Basically, the idle os hook is broken for all NRF52 targets on mbed OS 5.5.X. What this function tries to achieve is to go to sleep whenever then is no work left in the RTOS. It was expected that the MCU would wake up from either an external interrupt or the Systick timer. However, on NRF52 the SysTick timer stops working once sleep is entered. As a consequence timing primitives from the RTOS does not work as intended in develop/release mode.

That issue was not visible on Nordic development kits if the DK is usb powered but it is visible once it is powered by a coin cell battery.