#137 Ethernut 5.1 general USART driver bug w rx cooked mode

[PBX]

when mode USART_MF_COOKEDMODE, under some circumstances there is a possibility of an unwanted EOF, effectively shutting down the stream.
Given:
fgets (or fgetc) from a stream in cooked(text) mode until you reach a _first_ \n or \r character. Next call, when there is ONE single \r or \n character in the buffer, an EOF is produced instead.
File: nut/dev/usart.c
in UsartRead(NUTFILE * fp, void *buffer, int size):
[...]
/*
* Get cooked characters from receive buffer.
*/
if (dcb->dcb_modeflags & USART_MF_COOKEDMODE) {
for (rc = 0; rc < (size_t) size;) {
if (taken >= avail) {
break;
}
ch = *rbf->rbf_tail++;
if (rbf->rbf_tail == rbf->rbf_last) {
rbf->rbf_tail = rbf->rbf_start;
}
taken++;
if (ch == '\r' || ch == '\n') {
if (dcb->dcb_last_eol == 0 || dcb->dcb_last_eol == ch) {
dcb->dcb_last_eol = ch;
*cp++ = '\n';
rc++;
}
} else {
dcb->dcb_last_eol = 0;
*cp++ = ch;
rc++;
}
}
}
[...]
The routine fails to consume a \r\n sequence properly, especially when size makes it hit (and split) the eol sequence or single characters are read (size=1), encountering such a sequence.
When UsartRead is called and there is one single \r or \n character in the buffer (avail=1), but dcf->dcb_last_eo is not null or the same character (which is likely to occur on \r\n when consumed by a preceding call), taken will become >=avail and the routine exits via break - but rc was not increased and no character was effectively transferred. Hence, UsartRead returns 0, which represents an EOF. Stream gets unusable afterwards.

Note that the sequence might also arrive separately in the buffer. So I recommend to consider waitingfor for further characters to arrive when detecting this condition after leaving or before entering above loop (maybe by simply reiterating after consuming?)