Greg, Both pieces of code work fine if they are executed on their own so I am confident that UART connection is good.
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. 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. Regards, Mark — Mark Stevens mark.stev...@wildernesslabs.co > On 9 May 2024, at 22:51, Gregory Nutt <spudan...@gmail.com> wrote: > > This problem is reported for a lot a platforms and seems to be a hardware > issue, usually associated with FIFOs and buffers. > > If you rule everything else out, then you can also consider some of the more > unusual causes. On some hardware, small differences in BAUD can result in > the kind of data loss you describe. Other hardware is more resilient. > > Since you are using two different MCUs, there is a high probability that the > BAUD rates are not exactly identical and you may be relying on marginally > sized start and stop bits to keep in synchronization. The half bit times > typically used in the start and stop bits normally account for this. > > Here is a long discussion of some hardware behaviors: > https://www.eevblog.com/forum/beginners/uart-question/ Searching for "uart > data loss due to small baud differences" finds several others. > > On 5/9/2024 3:20 PM, Mark Stevens wrote: >> I’m not writing to the UART - I am reading. >> >> Regards, >> Mark >> ------------------------------------------- >> Mark Stevens >> Blog: blog.mark-stevens.co.uk >> >> >>> On 9 May 2024, at 17:40, Mark Stevens >>> <mark.stev...@wildernesslabs.co.INVALID> wrote: >>> >>> This is a direct connection between the two chips on a PCB. >>> >>> Regards, >>> Mark >>> — >>> Mark Stevens >>> mark.stev...@wildernesslabs.co >>> >>> >>> >>> >>> >>> >>>> On 9 May 2024, at 17:38, Bill Rees <redskyo...@icloud.com.INVALID> wrote: >>>> >>>> >>>> I've seen this problem before which revolved around flow control; >>>> essentially soft versus hard flow control (xmit off/ xmit on) >>>> >>>> Are you using a null modem cable? If not that may give you the accuracy >>>> you're looking for, else hardware flow control is the only other >>>> possibility if it is flow control. >>>> >>>> Bill >>>> >>>> On 5/9/2024 9:24 AM, Tomek CEDRO wrote: >>>>> On Thu, May 9, 2024 at 6:15 PM Mark Stevens >>>>> <mark.stev...@wildernesslabs.co.invalid> wrote: >>>>>> Yes, I am sure both side are configured correctly. >>>>>> If I run the kernel code only then all works as expected. >>>>>> If I run user space code alone all works as expected. >>>>>> The problems happen when I transition from kernel use of the UART to >>>>>> user space use of the UART. >>>>>> I have also connected a logic analyser to the system and all looks good. >>>>>> Also, my current problem is NuttX reading data not sending it. Sending >>>>>> may also be a problem but I have not got that far at the moment. >>>>> Which UART do you use? What happens when you use different UART? Are >>>>> you sure it does not interfere with console? >>>>> >>>>> -- >>>>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >>
