On Wed, Jul 19, 2017 at 09:00:16AM -0700, will sanfilippo wrote:
> I dont know enough about the console code to make an intelligent suggestion.
> There is no task associated with the console, right? If not, and the purpose
> of this is to wait some time maybe the only thing to do is set a timer to
> wake up and deal with this? Not sure that this would work though… And I dont
> think I have any other ideas :-)
I think this is caused by a recent change. It appears the console code
writes back to the uart in the middle of a read. Specifically:
int
console_handle_char(uint8_t byte)
{
/* ... */
/* Handle special control characters */
if (!isprint(byte)) {
handle_ansi(byte, input->line);
switch (byte) {
/* ... */
default:
insert_char(&input->line[cur], byte, end);
/* Falls through. */
case '\r':
/* Falls through. */
case '\n':
if (byte == '\n' && prev_endl == '\r') {
/* handle double end line chars */
prev_endl = byte;
break;
}
prev_endl = byte;
input->line[cur + end] = '\0';
console_out('\r'); // <--- ***
console_out('\n'); // <--- ***
cur = 0;
end = 0;
os_eventq_put(lines_queue, ev);
It seems the console is normalizing line endings. Regardless of what
type of newline is read, it always outputs "\r\n".
I don't know what the solution is, but Sterling is correct that the ISR
shouldn't be performing a UART write.
Chris
>
>
> > On Jul 18, 2017, at 10:34 PM, Sterling Hughes
> > <[email protected]> wrote:
> >
> > Hi,
> >
> > As I was supporting the Ambiq series of processor, I ran into what I think
> > is a bug in console_queue_char().
> >
> > Specifically,
> >
> > - console_rx_char() is registered as a uart device callback, which operates
> > in interrupt context
> >
> > - console_handle_char() is called by console_rx_char() in uart_console.c.
> >
> > - console_handle_char() calls console_out()
> >
> > - console_out() calls write_char_cb() which is console_queue_char()
> >
> > - console_queue_char() calls os_time_delay()
> >
> > So, in the cases where console_queue_char() is called in interrupt context,
> > and os_time_delay() is hit, the operating system crashes. os_time_delay()
> > is not meant to be called from interrupt context.
> >
> > I ran into this due to some errors managing the RX interrupt (more than (n)
> > bytes in a single RX interrupt), but I’m pretty sure the behavior should
> > not be this way/it will happen rarely. What do folks think in terms of
> > potential options for changing it?
> >
> > Sterling
> >
> >
> >
>
