Serial interrupt not cleared after the interrupt?

I have problem with serial interrupt. After getting the interrupt activated the program keeps getting interrupt again and again and doesn’t go out from the loop.
I have only a simple instruction inside the function . I used both Serial and RawSerial without difference.
It seems that there is a bug in the new MBED-OS … I use the latest version and my board is NUCLEO-L476RG.
Any help ?
Thanks.

void ChangeInterActiveModeStatus(){
StopExecution=1;
}

Ahoj,
that implementation is not correct, I think. Please try to check this.

BR, Jan

Hi,
Thanks for the reply …
No even with RawSerial it doesn’t work. RawSerial is also using lock() unlcock() mechanism. It just continues as before and suddenly I get :

++ MbedOS Error Info ++
Error Status: 0x80010133 Code: 307 Module: 1
Error Message: Mutex: 0x20004944, Not allowed in ISR context
Location: 0x80085CF
Error Value: 0x20004944
Current Thread: main Id: 0x200015EC Entry: 0x80084FF StackSize: 0x1000 StackMem: 0x20003910 SP: 0x100004E0
For more info, visit: mbedos-error
– MbedOS Error Info –

= System will be rebooted due to a fatal error =
= Reboot count(=1) reached maximum, system will halt after rebooting Script program is running

It is a serious bug. :frowning:

Ahoj,

the crash only inform you about you call a method in a ISR context where is a mutex and that is not allowed.
The lock() and unlock()methods are empty in the RawSerial, see here.
Can you share your code or its a simplest version where this is occured?.
Or you can try this RawSerial_ex_2 example from RawSerial’s page.

BR, Jan

The error code is misleading.
Your code is working but mine is still not… I found that if you have an object like a pointer to an object (for ex. a serial object that is not initialized (i.e. =NULL)) and you try to use it …

the error will be as follow :
Error Message: Mutex: 0x20004944, Not allowed in ISR context

Which is not what you have … So mbed is failing to tell you that the object you used had a segmentation fault …i.e it is pointing to no where.

My problem is deeper… Unfortunately I cannot share the project and it is huge … I have to figure out why this happen.

BTW what you said is correct. I even added a thread to just simulate if that could cause the problem. But it is not RawSerial should work.
I even checked my code using CPPCheck but I cannot find any errors :frowning:

There must be something with the UARTSerial class.
The default console which uses the UARTSerial class acquire mutex … which could be the reason … But why your example doesn’t crashes and mine does?
My code works fine if I don’t fire up the interrupt… so It is very difficult to debug.

Ok,
This code will fail now … Having a printf inside the interrupt will cause a problem.
Please look at this code:

#include “mbed.h”

DigitalOut led1(LED1);
DigitalOut led2(LED2);

RawSerial pc(USBTX, USBRX);
Thread debugThread(osPriorityNormal7, 8 * 1024 /32K stack size/);

void debug(){
while(1){
ThisThread::sleep_for(1000);

    led1 = !led1;
    pc.putc('1');
}

}
void callback_ex() {
// Note: you need to actually read from the serial to clear the RX interrupt
int c;
c=pc.getc();

/* Remove this line and it works just fine. But putting a pc.putc doesn’t cause any trouble.
BUT if you use
pc.printf(“why”)
It works just fine.
So As I said … it must be the default console that causes the problem.

*/
printf(“why”);

led2 = !led2;

}

int main() {
pc.attach(&callback_ex,Serial::RxIrq);
debugThread.start(debug);

while (1) {

    ThisThread::sleep_for(500);
}

}

You don’t want to printf in ISR context. What I usually do is defer the call to another context using EventQueue.

EventQueue *queue = mbed_event_queue();

void why();

void callback_ex() {
	pc.attach(NULL, Serial::RxIrq);
	queue->call(why);
}

void why() {
	int c;
	c = pc.getc();
	pc.printf("why");
	led2 = !led2;
	pc.attach(&callback_ex, Serial::RxIrq);
}

I think you also need to detach the callback when interrupted as printf triggers Serial events. You can reattach after the call.

You can learn more about EventQueue here.
https://os.mbed.com/blog/entry/Simplify-your-code-with-mbed-events/

Please don’t understand me wrong. I show you what I have in my code. There is nothing than the change of the variable to 1.
I just wanted to tell you that mbed-os is using printf …which is go back to another calss that uses mutex. That causes the problem…
I debugged and after that I ended with seen the caller of the mutex which wase the default console.
Thanks anyway.
The mechanism is wrong. I shouldn’t be calling getc while it push me to use it … what? isn’t that a bug?

@mjm2016 yes, you have already answered by yourself. The alone printf(***); form the default console is probably Serial based so there are Mutexes up and it is not possible to use it in interrupt context, but RawSerial have have no Mutexes. That is why pc.printf(); works.

That issue you can also found on Githhub

Also how Kentaro wrote, " You don’t want to have any printf in ISR context.", because the printf is slow and that will block the MCU for another operations. For example you will lose some data from serial when will be too fast and so on.

BR, Jan

Hi,
I don’t use it and I don’t need it. But mbed itself uses printf. The above code explained that MBED uses the printf and it causes the ISR mutex problem.

The bigger issue is you need to cal getc while it is not allowed in interrupt. That is a bug

BTW: As I said, even when you have a segmentation fault… mbed’s fault message is referring to the ISR mutex problem… This (I think) due to the fact that mbed uses the printf to tell you the crash … and that will cause the ISR mutex problem… But the real reason is not that …
I hope you understand what I am saying.

As a conclusion:
The error :
Error Message: Mutex: 0x20004944, Not allowed in ISR context
was not a real error. I had no mutex or printf …or any other thing inside the interrupt routine.
What caused mbed to generate that error was a deletion of an object twice. But Mbed is not so cleaver to tell you the problem … It tries to printf and that will cause other problem which cover the real cause of the crash.

So, Don’t listen to this error. Mbed is not telling you the truth.