Nucelo L432KC freeze

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.

No worries, it doesn’t matter

I noticed in my tests of the last days that the reaction of the L432KC during the crash is that the program in LabView no longer receives information by the serial / USB port but that the LED continues to flash normally.
I repeated the test with my program of July 3 under MBED 2, I get the same reaction: no longer receives information through the port and LED flashes.
I do not understand anything. However, I did not dream of the crash with fixed LED!
The current reaction can obviously suggest a problem with the reception of the LabView program.

I did the test under MBED OS bare-metal by flashing the LED at the time of the command “M”:
When the LabView program does not receive any more information the LED continues to flash, So the “M” command is a priori processed.
Here is the MBED program:

 mbed test Program

#include "mbed.h"
//#include "platform/mbed_thread.h"

#define BMS 50 //buffer max size

EventQueue *queue;
RawSerial port_USB(USBTX,USBRX); // tx, rx
Timer MyTimer;
Ticker TickerLED;
DigitalOut myled(LED1);

volatile char tableau_de_reception[BMS+1];
volatile unsigned short indice_tableau_reception = 0;
volatile float Marche = 0;
volatile float Temps = 1;
volatile int flipflop = 1;

void blink();

void processing(char c){
    switch (c) {
        case '0':
        case '1':
        case '3':
        case '4':
        case '5':
        case '6':
        case '7':
        case '8':
        case '9':
        case '-':
        case '.'://if i get a number
            tableau_de_reception[indice_tableau_reception] = c;//I put the received character in an array
            port_USB.printf("count %d\n ",indice_tableau_reception);
            if (indice_tableau_reception >= BMS) indice_tableau_reception = 0; //overflow protection
            else indice_tableau_reception++;

        case 'M':
            Marche = 1;
            flipflop = !flipflop;
            Temps =;
            port_USB.printf("%f ",Temps);
            port_USB.printf("%i ",flipflop);
            port_USB.printf("3 4 5 6 7 \n");
            myled = !myled;    
        case 'R':
            port_USB.printf("%f ",Temps);
            port_USB.printf("%i ",flipflop);
            port_USB.printf("3 4 5 6 7 8 \n");
        case '?':
void reception_USB(void){
    static char caractere_recu;
    while (port_USB.readable()) {
        queue->call(processing, caractere_recu);
void blink()
//    myled = !myled;    

int main()
    queue = mbed_event_queue();
    port_USB.attach(&reception_USB);//we define the USB link as an interruption procedure

I don’t quite understand.

Another thing: is the printf("%f ", Temps) sending correct values? I’m not sure with which version it started, but the printf is now replaced by a minimal_printf where %f is disabled by default. Is LabView receiving the correct timestamps?
For testing you could also a printf to a terminal program via the virtual comport from the Nucleo:

case 'M':
    printf("M: %f %i\n", Temps, flipflop);

I tried: gathering the data in the same printf does not change the behavior.

After a search for an error code on the National Instrument forum (LabView) I found that several people have already had a problem of connection loss on a serial port (via USB port or not) depending on the hardware which was used. The only solution I find on this forum is to close and then reopen the port, it works for me but it takes between 0.3s and 2s. this time is long when we want to act on outputs of the L432KC every 0.1s (I even hoped 0.01s).
I will try again without intentionally creating a data format error.

Sorry to have solicited you so much for a crash that comes more from the computer than from the microcontroller.

no problem, you’re welcome. but you have to mention also when the problem is fixed :slight_smile:

about the printf: my intention was to use an additional printf to the console, so that you can see if some requests are ariving. Using one printf shouldn’t change anything, right.

Oh, and one more pitty pitfall when the host is running Windows 10:
Windows 10 is doing some mysterious on the USB MSD that the Nucleo provides. This leads to resets of the board, I had this problem many times with different boards.
A workaround is to disable the USB MSD in the device properties.
To verify, you can print a startup message to the terminal or blink a LED until a button is pressed to continue.

Hi Johannes,
What is USB MSD?
I can’t seem to find it on the web.

That “USB MSD” mean Mass Storage Device, I think.
BR, Jan

Actually deactivating the “Mass Storage Device” seems to solve the problem, I tried it for 40mn. I would still see with longer tests.
Thanks for your help, Jan and Johannes.