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 > > <sterling.hughes.pub...@gmail.com> 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 > > > > > > >