Nucelo L432KC freeze

Hi Mark,

The compilation time takes so long because the source of the Mbed OS 5 (or 6) is very huge and all its files are precompiled even if you not use them. But that occurs only first time or when you make a bigger change like change to another version of the MbedOS and so on.
When you not need / not want to use the RTOS functionality, you can use the Mbed OS 5 (or 6) with bare metal profile. It is more economical (vs MbedOS 5-6) for board’s flash memory, It is similar like MbedOS2. Also the EvenQueue is possible to use under the bare metal profile, it can be enabled in mbed_app.json like the bare metal profile.

In the interrupt handler you want to do only really necessary steps, because during this time is the rest of program out, it can not operate until the interrupt handler not finish. That can cause losing a data or something similar.

BR, Jan

thank you for all your advice.
I will see to use Mbed OS with the bare metal profile. :slightly_smiling_face:

I tried your code using MBED-OS bare-metal but I get this compilation error message:
Error: Could not parse mbed app configuration from /tmp/chroots/ch-acd2575d-67f1-4804-aeac-19549d1d7a27/src/mbed_app.json
I have mi in mbed_app.json:
{ "requires": ["bare-metal"] }
Do you have an idea ?

Hi Mark,

If you copy my modification of your code with the eventqueue from above you need this, how i wrote.

“requires”: [“bare-metal”, “events” ,“rtos-api”]

BR, Jan

Thank you for your prompt response.
I then get this error message:
Error: Could not parse mbed app configuration from /tmp/chroots/ch-773c6ec2-bad7-42fb-b5f8-6237fc6557b3/src/mbed_app.json

that indicates that mbed_app.json is not a valid json file, so there must be some mistake like missing ‘,’ or bracket error.
In the documentation, you’ll find which API can be used in bare-metal, but its a teddious work to find all the requriments. I looked up in the source mbed_lib.json files, or is there a smarter way?

Yep, I reproduce that when this " was changed with which was caused during copy&paste.

The example does not process the EventQueue, isn’t there missing a queue->dispatch() or ->dispatch_forever() ?

I don’t know but it was working when I did test it. I took it from Mbed’s example what is in the documentation of the EventQeueue (second example).

BR, Jan

yes, its ok, because it uses the existing queue in bare-metal. For the rtos, there can be many queues and then you need to dispatch the events.

there was indeed a “copy and paste” which must have gone wrong, look at the difference between these two lines at the level of “”:
“ Requires ”: [“ bare-metal ”,“ events ”,“ rtos-api ”]
" requires ": [" bare-metal "," events "]
I just noticed it.
The compilation works.
However, the program does not work as if there were no requests on the serial port (it’s the same if I add “rtos-api”).

does the LabView program set the DTR signal on the serial line? The Mbed USBserial waits for an USB connect and then for a terminal_connect. That is detected by the DTR signal. Can you test with a terminal program where you can set this signal manually?

The LabView program does not use any flow control.
The program as it is written in my first post works … a few thousand iteration until the crash. And there is no DTR signal management.

The line queue-> call (processing, caractere_recu);
does not execute the processing () procedure.
I just tested with myled =! Myled;

this works with queue-> dispatch_forever (); in the main ()

on the other hand the instructions which follow queue-> dispatch_forever (); in the main () are not executed.
It is not essential, I just have to take it into account when writing the program.

I was confused by the USB, but you are using the Serial, so forget about the DTR.

Just looked up for this, with RTOS, a dedicated dispatch thread is created automatically. For bare-metal, the dispatch() is necessary.
But you can add a timeout in ms to the dispatch call, so you can use it instead of the wait(). But for a fast response, it should loop very fast.
You can put also other events into the queue. And also cyclic events with:

 queue.call_every(1000, printf, "called every 1 seconds\n");

Thank you for this advice.
On the other hand I have just noted that the program with the use of EventQueue has the same reaction, it crashes after a few thousand iteration.

when a char is received and is processed and you receive another chars now, then you may have more than one char in the internal buffer, but you’ll get only one interrupt.
So, in the ISR you should process chars as long as available:

1 Like

@JojoS thank you to point this you are right of course but the input was a single character commands like ‘M’ ‘R’ ‘?’ with a delay so for example that was enough, I hope.

@marcusbaslerus My bad, I apologize to you. I tested the code on the full version of MbedOS 5.15 and with the bare metal profile I probably tested only the compilation not with a board.

BR, Jan

1 Like

Thank you, it’s always better to handle the arrival of chars correctly, even if it should not happen as Br. Jan wrote.