Serial ISR "Mutex lock failed"

[rmr1012]

Description

There seems to be an issue with the serial RX ISR handling portion of the mbed-os. Everytime the ISR for a serial RX is called, Mbed-os would panic and throw "Mutex get lock failed". This was not a problem with earlier versions of mbed, although I can't remember what that earlier version was. This bug was tested and replicated on two platforms, K66 and F303

- What target does this relate to?

K66F, NUCLEO_F303ZE
- What toolchain (name + version) are you using?
GCC_ARM
- What tools (name + version - is it mbed-cli, online compiler or IDE) are you using?
$ mbed --version
1.10.0

- What is the SHA of Mbed OS (git log -n1 --oneline)?

8a7f591 (HEAD, origin/master, origin/HEAD) Merge pull request #10826 from ABOSTM/IAR_EXPORT_STM32H743ZI
- Steps to reproduce. (Did you publish code or a test case that exhibits the problem?)
Minimum code to reproduce

Serial pc(USBTX, USBRX);

void callback() {
    pc.getc();
}

int main() {
    pc.attach(&callback);
    led1 = 1;
    while (1) {
        led1 = !led1;
        wait(0.25);
    }
}

when any serial bytes are sent, the below error occurs

++ MbedOS Error Info ++
Error Status: 0x80020115 Code: 277 Module: 2
Error Message: Mutex lock failed
Location: 0x37D3
File: Mutex.cpp+64
Error Value: 0xFFFFFFFA
Current Thread: rtx_idle  Id: 0x20000490 Entry: 0x39D9 StackSize: 0x200 StackMem: 0x200007D8 SP: 0x2002FF28
Next:
rtx_idle  State: 0x2 Entry: 0x000039D9 Stack Size: 0x00000200 Mem: 0x200007D8 SP: 0x20000980
Ready:
Wait:
rtx_timer  State: 0x83 Entry: 0x000050A5 Stack Size: 0x00000300 Mem: 0x200004D8 SP: 0x20000770
Delay:
main  State: 0x13 Entry: 0x00003927 Stack Size: 0x00001000 Mem: 0x20000B90 SP: 0x20001AA0
For more info, visit: https://mbed.com/s/error?error=0x80020115&tgt=K66F
-- MbedOS Error Info --

Attempted to use the event queue ISR implementation as well

Serial pc(USBTX, USBRX);

void callbackFunc() {
    pc.getc();
    led2 = !led2;
}
EventQueue queue;
int main() {
    Thread eventThread;
    eventThread.start(callback(&queue, &EventQueue::dispatch_forever));
    pc.attach(queue.event(&callbackFunc));
    led1 = 1;
    led2 = 1;
    while (1) {
        led1 = !led1;
        wait(0.25);
    }
}

A diffrent error is raised

++ MbedOS Error Info ++
Error Status: 0x80020126 Code: 294 Module: 2
Error Message: CMSIS-RTOS error: ISR Queue overflow
Location: 0x410D
File: mbed_rtx_handlers.c+64
Error Value: 0x2
Current Thread: rtx_idle  Id: 0x200004E8 Entry: 0x40E1 StackSize: 0x200 StackMem: 0x20000830 SP: 0x2002FF18
Next:
rtx_idle  State: 0x2 Entry: 0x000040E1 Stack Size: 0x00000200 Mem: 0x20000830 SP: 0x200009D8
Ready:
Wait:
rtx_timer  State: 0x83 Entry: 0x00005F09 Stack Size: 0x00000300 Mem: 0x20000530 SP: 0x200007C8
Delay:
main  State: 0x13 Entry: 0x0000402F Stack Size: 0x00001000 Mem: 0x20000BE8 SP: 0x20001A20
For more info, visit: https://mbed.com/s/error?error=0x80020126&tgt=K66F
-- MbedOS Error Info --

Issue request type

[ ] Question
[ ] Enhancement
[X] Bug

[0xc0170]

Hi @rmr1012 , you can find similar issues in issue tracker here on github if you search for "serial mutex". There were silent failures previously, we fixed that in previous minor release (I don't recall if it was 5.11 or 5.12).

See good response from @kjbracey-arm here #8518 (comment). That should answer your bug report.

Btw, thanks for detailed issue report!

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-1344

[rmr1012]

Hi 0xc0170,

Thanks, that's super helpful! I ended up using RawSerial for what I need. Hope you guys can help update the examples on the website to avoid confusing other folks.

Also, some extended examples for the FileHandle implementation of serial r/w would be helpful as well.
The examples in the doc only covered read cases, but the handling of writing wasn't immediately clear.

[0xc0170]

Thanks, that's super helpful! I ended up using RawSerial for what I need. Hope you guys can help update the examples on the website to avoid confusing other folks.

@AnotherButler Who could help with this one?

[AnotherButler]

@0xc0170 I believe @bulislaw and @evedon are looking into the state of our examples.