custom mbed build following the instructions crashes when mbed is reporting errors on anything other than a release build.

[schnoberts1]

Here's what I think is happening. mbed error handling string printers look like this:

void mbed_error_puts(const char *str)
{
    // blah blah
    write(STDERR_FILENO, str, 0);

    core_util_critical_section_enter();
#if MBED_CONF_PLATFORM_STDIO_CONVERT_NEWLINES || MBED_CONF_PLATFORM_STDIO_CONVERT_TTY_NEWLINES
    char stdio_out_prev = '\0';
    for (; *str != '\0'; str++) {
        if (*str == '\n' && stdio_out_prev != '\r') {
            const char cr = '\r';
            write(STDERR_FILENO, &cr, 1);
        }
        write(STDERR_FILENO, str, 1);
        stdio_out_prev = *str;
    }
#else
    write(STDERR_FILENO, str, strlen(str));
#endif
    core_util_critical_section_exit();
}

this means the writes are in a critical section. As I understand it that means IRQs are masked via __disable_irq. When the write happens it ends up in usb/serial code which requires a Semaphore (see AsyncOp::wait as an example). Semaphore asserts when it's constructed in a context with IRQs are masked. That assert then calls up and back through the same mbed_error coding and the cycle repeats, resulting in the device 'locking up'

In Release mode MBED_ASSERTs are compiled out.

[schnoberts1]

See #958 for the context

[facchinm]

@schnoberts1 that's expected, the crash dump is supposed to be a very low lover (register level) write to some UART, since you can't know in which amazing way the system might have exploded.
The USB stack requires a non corrupted stack, interrupts and other logic that might be broken, hence why we can't use it for this use case.

[schnoberts1]

I do not see how an infinite loop in mbed_error_puts in non-release mbed code is reasonable expected behaviour if the system is in a good state. Either MBED_ASSERT should work or it should not exist or the arduino build should always set NDEBUG.

It's also undocumented.

hence why we can't use it for this use case.

but it is used in all flavours of the Arduino build I could produce using the mbed arduino build script and libs. Is there supposed to be a way of turning that off (other than assuming mbed non-release builds are useless)? Hopefully the migration to Zephyr isn't plagued with these sorts of undocumented edge cases and interactions between mbed and ArduinoCore-mbed. The STM32/mbed/Arduino stack has been quite a journey.

[schnoberts1]

Here's a concrete example of the problem. Build mbed in the default profile (which is not Release). Write some threaded code which results in an MBED_ASSERT. Result: the developer spends their time debugging the assert rather than their issue.