Hi, I did look at this code recently. The way it is designed, without changing a lot of things, one way to avoid calling console_out() in interrupt context is to do it after a line is taken off the lines_queue in console_read(). However, it might get a bit complicated as there are multiple cases, I am not sure if console_read() would be the only consumer of a complete line but it surely looks like it should be since it is the only one that pulls out the line from the lines_queue.
Regards, Vipul Rahane > 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 > > >
