6 years, 7 months ago.

Serial Attach issue with OS5xx

Using OS5 rev.5349

When I do this;

esp2.attach(&espReceive,Serial::RxIrq);

I get this on my terminal:

++ MbedOS Error Info ++ Error Status: 0x80020115 Code: 277 Module: 2 Error Message: Mutex lock failed Location: 0x885F Error Value: 0xFFFFFFFA Current Thread: main Id: 0x200035A8 Entry: 0x8C6B StackSize: 0x1000 StackMem: 0x200025A8 SP: 0x2007FF58 For more info, visit: https://armmbed.github.io/mbedos-error/?error=0x80020115 MbedOS Error Info

Why?

Works fine with OS2, but I'm struggling to get any of my work running on OS5

The Serial information here is not much help either, at least not for me.

https://os.mbed.com/docs/mbed-os/v5.11/apis/serial.html

I'm sure there's a simple answer, can anyone point me in the right direction.

Thank you

Paul.

1 Answer

6 years, 7 months ago.

Hello Paul,

In the current version of Mbed OS 5, if you attempt to use a mutex from within an ISR, it will treat that as a fatal system error. So the reported error most likely results from calling the lock function in the attached ISR rather than from attaching a function to the 'serial received' interrupt. Because Serial is derived from SerialBase, Stream and NonCopyable and functions like readable, getc, read etc. (inherited from those classes) usually call the lock as their first action, you are not allowed to use them within an ISR anymore.

  • One solution is to define a global volatile flag, let ISR to set that flag when handling the interrupt and take action in the main function by testing the flag.
  • Another solution is to defer execution of non-ISR safe functions, like readable, getc etc., by using EventQueue.

Accepted Answer

Hmmm, not the 'simple' answer I was hoping for.

I really don't want this thread system for my work atm, although it does look interesting and will play with it when I get time.

Is there any command I can use that will completely disable all of the OS5 features so that it runs like OS2? Something like "#define os2" at the top of 'main' would be good.

posted by Paul Staron 15 Feb 2019

As usual there are some pros and some cons as the OS grows. It's very difficult to meet all the requirements and support so many various targets. This is what I was able to find that could be of help: https://os.mbed.com/forum/blog-Reducing-memory-usage-by-tuning-RTOS-con-404-forum/topic/28622/

posted by Zoltan Hudak 15 Feb 2019

Thank you Zoltan, I think for the time being I will stick with Mbed 2, it does what I need and I certainly do not want RTOS with thread based code at this stage. HopefullyMbed 2 will be revisited sometime to update a few loose ends, although I'm finding very few problems now.

posted by Paul Staron 15 Feb 2019