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){
if(!Marche){
TickerLED.detach();
TickerLED.attach(blink,0.1);
}
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++;
break;
case 'M':
Marche = 1;
flipflop = !flipflop;
Temps = MyTimer.read();
port_USB.printf("%f ",Temps);
port_USB.printf("%i ",flipflop);
port_USB.printf("3 4 5 6 7 \n");
myled = !myled;
break;
case 'R':
port_USB.printf("%f ",Temps);
port_USB.printf("%i ",flipflop);
port_USB.printf("3 4 5 6 7 8 \n");
break;
case '?':
port_USB.printf("Mon_MBED\r\n");
MyTimer.reset();
break;
}
}
//_____________________________________________________________________________
void reception_USB(void){
static char caractere_recu;
while (port_USB.readable()) {
caractere_recu=port_USB.getc();
queue->call(processing, caractere_recu);
}
}
//_____________________________________________________________________________
void blink()
{
// myled = !myled;
}
//_____________________________________________________________________________
int main()
{
queue = mbed_event_queue();
port_USB.baud(115200);
port_USB.attach(&reception_USB);//we define the USB link as an interruption procedure
MyTimer.start();
TickerLED.attach(blink,1.0);
queue->dispatch_forever();
}//main()
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 
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.
Marc.
That “USB MSD” mean Mass Storage Device, I think.
BR, Jan
Hi,
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.
Marc.