Re: rt_dev_send() stalls periodic task

[Steve Freyder <steve@freyder.net>]

On 4/22/2019 5:56 PM, C Smith wrote:
> Please don't think the cross-link.c app config has the magic answer. 
> Changing RX timeouts to prevent TX stalls would be an open loop hack 
> that might fail the serial traffic jitters differently.   The most 
> suspicious difference between the two apps is that : cross-link.c 
> behaves very regularly in terms of timing, because it receives its own 
> transmissions.   My app receives packets from another computer 
> asynchronously (full duplex). So there is likely a random timing 
> anomaly causing the problem.  Any properly working UART and driver 
> should be able to handle this, National Semiconductor would say. But I 
> have a strange serial port, and it is tricking the xeno_16550A driver.
>
> Jan alluded to a buffer-filling race condition in his comment.
> I also fear that Receive interrupt handlers are somehow clearing 
> Transmit interrupts?
>
> I didn't look at the stack trace when my app hung at startup due to 
> that infinite RX config. BTW there was no serial traffic whatsover 
> during this hang. I could try it again and look at the stack...
> Also, it would be too hard to rewrite my apps to send single bytes. 
> Its two computers, rigid packet protocols & CRCs etc. Lots and lots of 
> code. Thats why I did that test app.
>
> -C Smith
Anything that can prove that there's no hardware problem causing
lost TX interrupts is good.  I remember you said that you had three
serial ports, and one never failed like this, the other two *do*
fail like this.  Isn't that true?  That seems important.