Serial communication stops without causing hardfault on certain use of getc()

Questions » Serial communication stops without causing hardfault on certain use of getc()

Anton Dalsmo

7 years, 2 months ago.

Hi all,

I am currently writing a program that has both read and write over serial communication to a pc vi usb. I need to both listen for input from the pc, while at the same time being able to send messages to the pc. I'm using a Nucleo F303K8 board, and the faulty code is attached below. The problem is that the attached code crashes after a while, which is why I am posting here.

include the mbed library with this snippet

#include "mbed.h"
DigitalOut led1(LED1);
Serial pc(USBTX, USBRX); // tx, rx
char buf[256], outbuf[256];
int buffer_pos = 0;
int buffer_readable = 0;

Ticker flipper;
void flip() { 
    led1 = !led1;

}
void pcCallback(){
    //version1 (crashes)
    buf[buffer_pos] = pc.getc();
    buffer_pos = ++buffer_pos%250;
    //version2  (works fine, but does not do what is desired)
    //pc.putc(pc.getc());
}

int main() {
    flipper.attach(&flip, 1);
    pc.attach(&pcCallback); 
    pc.printf("Hello World!\r\n");
    int i=0;
    while(1) {
        i++;
        pc.printf("Loop!%i\r\n",i);
        wait(0.1);
    }
 }

The problem seams to be located in pcCallback(). When running version1 the code should simply place the input in a buffer, but this version crashes after a while on input from the pc. However when commenting/uncommenting to version2 the program works fine.

Even tho the the program crashes the flipper callback still remains active and keeps blinking LED1. Which should mean that we have avoided a hard fault.

Last peace of useful info i can give is that crashes can usual look like the below attached serial prompt, and this only happens when sending characters from the computer. If i dont send anything over serial the program happily chugs away.

Quote:

Loop!61 Loop!62 Loop!63 Loo

This problem boggles my mind, and any help would be much appreciated. Regards Anton

1 Answer

Danel Kirch

7 years ago.

Can verify this issue. Experiencing this issue on: F303K8 and F411RE

After a couple of tests, i found that when transmitting larger amout data to the board, the hick-up appears. In other words, if buf[256] expects 256 characters and sending exactly 256 , freeze appears.

A example

If buffer has 8 bytes allocated

Expecting 8

char buf[8];

sending following string will work cafe, note the string will contain either or both \n\r at the end, that makes the data to be 6 bytes however if sending cafebabe, freezing will occur due data is 8bytes and ending will exceed by 1 or 2 bytes depending if \n and/or \r are appendend.

2 Possible workaround

Option 1

Increase buffer size which will hold incoming payload. Eg. char buf[512] However, if transmitting too fast multiple payloads, freezing will occur. Therefor wait a bit before transmitting next payload.

Option 2

Use a middleware (NodeJS, Python or other) that does the transmission to the board. If payload exceeds buffer size, middleware would split the payload and transmit each batch when previous one is complete.

Anton Dalsmo

Important changes to forums and questions

7 years, 2 months ago.