Serial interrupts not wo

[CodingGhost]

Description

I posted the crashing code here: https://os.mbed.com/forum/bugs-suggestions/topic/35736/
somehow I cannot get github to format it correctly.

will crash on any serial data sent and gives "Mutex lock failed" error.

target:NRF52840
using PlatformIO
latest release

Issue request type

[ ] Question
[ ] Enhancement
[ x] Bug

[0xc0170]

You are using Serial object in interrupt, it won't work. There are couple of issues related to this here.

Please read this #8518 (comment)

[CodingGhost]

Whow, lightning fast Response :D
I figured, i could use rawserial, but please update your examples, because there are official mbed examples written in that way..

[0xc0170]

I figured, i could use rawserial, but please update your examples, because there are official mbed examples written in that way..

If you can share them, we will review. They should be fixed.

[CodingGhost]

https://os.mbed.com/handbook/Serial

the last example "Attach to RX Interrupt"

[0xc0170]

There's note on the page: This is the handbook for Mbed OS 2.

You are using now Mbed OS 5 to my understanding. Thus it fails.

[CodingGhost]

Dangit.
Sorry for wasting your time!
But just to be sure, I can just replace Serial with Rawserial and everything should be ok?

[0xc0170]

Yes, or rather UARTSerial

[kjbracey]

If wanting to process directly from interrupt, like that example, you would need to use RawSerial - it's the drop-in replacement.

UARTSerial removes the need to have your own interrupt handler - it does the interrupt handling and buffering for you, but the code would look different.

Examples here: https://os.mbed.com/docs/mbed-os/v5.12/apis/filehandle.html

[CodingGhost]

so, maybe I still found a bug, maybe Im just very confused...
I have been struggeling to get rawSerial to work properly for the last 2 hours.
It works, if I dont send many characters in one burst, but If transmitting above about 60 chars in one burst at 57600 baud, It will just receive garbage. And my program is still the same super simple echo example.
Edit:
just tried this example with no modification:
https://os.mbed.com/teams/mbed_example/code/RawSerial_HelloWorld/file/112a40a5991a/main.cpp/
9600baud

same behaviour, and this time its definitly meant for OS5.

[ciarmcom]

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

[kjbracey]

If you're trying to application code to read and write like that, RawSerial will not work. RawSerial is only really suitable for reception from interrupt - you need to have an interrupt handler to get data out of the serial port fast enough, or else ensuring you devote 100% of CPU time to waiting for reception - not stopping to write to a different serial port.

Your example program should use UARTSerial (which is buffered, and has built-in interrupt handlers). Its buffers should permit a simple copy loop like that to work.

Or, even better, do not explictly use it at all - just use stdin and stdout, so normal C getchar and putchar. But you will need to turn on platform.stdio-buffered-serial in mbed_app.json to get this "new, improved" stdin/stdout serial handling. For backwards compatibility, default stdin/stdout is raw, and hence works as badly as RawSerial.

[CodingGhost]

Ok, thanks I will try that. But why is it like this in the official example then?

[kjbracey]

Good question. I think the problem is that some examples of too simplistic "how to use this class", that don't actually use them in the way they're intended/suitable for.

The class-focused nature of the documentation also doesn't help - they end up documenting Serial with examples of using it to access the console, when you should be more generically accessing the console with normal C stdin/stdout. But that's not an Mbed OS class... (You should normally only be using the serial classes explicitly for other devices like modems/GPS etc - your console may or may not be serial, and if it is, the board support will have set it up and routed it to stdio for you).

[CodingGhost]

well... Im starting to think that something else isnt right at all.. now I am using uartSerial and I still have exactly the same problem. also, the "garbage" that I get is the same everytime.. its "USBS" plus some unknown characters. I really dont know whats going on.

edit:sorry for the code formats, I dont get it the way I want.

`UARTSerial ser(P0_6, P0_8,57600);
EventQueue queue(16 * EVENTS_EVENT_SIZE);
string buffer;
void test()
{
char c = 0;
while(ser.read(&c,1) == 1)
{
buffer += c;
}
}

void sigio_callback() {
queue.call(test);
SEGGER_RTT_WriteString(0,"test");
}

void periodic()
{
wait(2);
SEGGER_RTT_WriteString(0,buffer.c_str());
SEGGER_RTT_WriteString(0,"\n");
}
int main() {
SEGGER_RTT_Init();
SEGGER_RTT_WriteString(0,"start!\n");
ser.sigio(sigio_callback);
ser.set_blocking(false);
ser.sync();
queue.call_every(5000,periodic);
queue.dispatch_forever();

while (1) {
    wait(1);
}

}`

[kjbracey]

If P0_6 and P0_8 are your main console pins, UARTSerial may not play well with being double initialised - make sure you haven't turned on platform.stdio-buffered-serial if you're going to use UARTSerial explicitly in your app - that would mean two UARTSerial drivers attempting to access one serial port.

In Mbed OS 5.12, you can get hold of the console's existing handle for sigio/set_blocking with mbed_file_handle(STDIN_FILENO), turning on platform.stdio-buffered-serial and using that would be neater than making your own UARTSerial.

Other than that, code seems like it should work. If P0_6 and P0_8 aren't the main console, maybe there's a pin conflict with something else on the board?

Or maybe the problem's at the sender end, or even a conflict with the Segger trace?

[CodingGhost]

DAMN! I got it sorted.
your last tip "conflict with segger trace" gave me the idea to try it with an external ftdi chip instead of the segger for serial. And BOOM all problems gone.
I hate that Segger chip now.
sorry for all the wasted time and thanks a lot.

[linlingao]

@CodingGhost Close since the requester has solved it.