> Hmmm... the UART device will closed when the kernel thread is killed, right?
> When the device is closed, it is also flushed I believe. If those two
> things are true, then data loss would be expected, right?
Yes, the UART is closed just before we perform a thread_delete(0).
Data loss is accounted for in the protocol. We send a known packet to the ESP
and it then responds to the request. This happens several times (we try 40
times). The logic analyser is showing the traffic between the chips and I have
manually checked the packets and the data looks good.
> Note that for a UART console, stdin is inherited so that the UART is not
> closed when the kernel thread exits.
The UART is opened at the start of the thread not prior to the thread being
started.
We are doing the following:
int start_uart_thread()
{
// Configure the thread properties
handle = kthread_create(… monitor_thread …);
}
void monitor_thread(…)
{
int uart = open(….);
// Setup signalling.
while (!shutting_down) { read and process data }
close(uart);
kthread_delete(0);
}
In this case is does the inheritance go both ways? As in if I open the UART
in the kthread does the parent thread keep it open?
Regards,
Mark
—
Mark Stevens
mark.stev...@wildernesslabs.co
> On 10 May 2024, at 05:38, Gregory Nutt <spudan...@gmail.com> wrote:
>
>
> On 5/9/2024 10:23 PM, Mark Stevens wrote:
>> The issue arises if I try to kill the kernel thread reading from the UART
>> and then try to start a user thread reading from the same UART.
>
> Hmmm... the UART device will closed when the kernel thread is killed, right?
> When the device is closed, it is also flushed I believe. If those two
> things are true, then data loss would be expected, right?
>
> Note that for a UART console, stdin is inherited so that the UART is not
> closed when the kernel thread exits.
>
>> Also, the issue can be reproduced within the first 15 seconds after board
>> reset so I am confident that the issue will not be related to long term
>> drift.
>
> From what I have read, any kind of slow drift is not possible due to the
> start and stop bits. Those transitions are necessary to synchronize on each
> byte. I also read that in the event of bad start bit, several bytes could be
> lost while the UART recovers.
>
> But that does not seem to be these issue here.
