So we have a two chip board:
* STM32 running NuttX (v7.5 I believe)
* ESP32 acting as a coprocessor running custom firmware
The STM32 runs the show and the ESP32 provides services to the STM32 code.
In normal run mode, NuttX has a kernel thread that reads data from the ESP32
over UART (/dev/tty
On Thu, May 9, 2024 at 3:31 AM Mark Stevens
wrote:
> So we have a two chip board:
>
> * STM32 running NuttX (v7.5 I believe)
> * ESP32 acting as a coprocessor running custom firmware
>
> The STM32 runs the show and the ESP32 provides services to the STM32 code.
>
> In normal run mode, NuttX has a
It is random. So in a 50-ish byte packet I will see sequences of missing bytes
which can be 1, 2 or event 3 bytes long missing.
For example, I am seeing on the logic analyser the ESP sending the following
hex bytes:
c0 01 08 04 00 07 12 20 55 00 00 00 00 c0
NuttX is seeing:
c0 01 04 20 55 0
On Thu, May 9, 2024 at 5:40 PM Mark Stevens
wrote:
> For example, I am seeing on the logic analyser the ESP sending the following
> hex bytes:
> c0 01 08 04 00 07 12 20 55 00 00 00 00 c0
> NuttX is seeing:
> c0 01 04 20 55 00 00 c0
Can you add small delay between each byte transmitted?
Can you
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 an
One extra piece of information that has occurred to me, I am using a `SIGINT`
kill signal to tell the kernel thread that it should close the connection.
Regards,
Mark
---
Mark Stevens
Blog: blog.mark-stevens.co.uk
> On 9 May 2024, at 17:11, Tomek CEDRO w
On Thu, May 9, 2024 at 6:15 PM Mark Stevens
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
>
I can’t use a different UART, this is a direct connection between the two chips
on the PCB.
Regards,
Mark
—
Mark Stevens
mark.stev...@wildernesslabs.co
> On 9 May 2024, at 17:24, Tomek CEDRO wrote:
>
> On Thu, May 9, 2024 at 6:15 PM Mark Stevens
> wrote:
>> Yes, I am sure both side are c
On Thu, May 9, 2024 at 6:26 PM Mark Stevens
wrote:
> I can’t use a different UART, this is a direct connection between the two
> chips on the PCB.
I mean different internal UARTn/USARTn peripheral, configured to use
the same physical connection, verify RX/TX BUFSIZE, and/or
verify/eliminate poss
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
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 wrote:
>
>
> I've seen this problem before which revolved around flow control; essentially
> soft versus hard flow control (xmit of
When writing to the port, write() should indicate number of bytes written.
Are you checking the return value and is it less than expected?
Note that write() enqueues the bytes but returns before write complete. If
port is closed before hardware finishes shifting all the bits out, message
will be t
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
> wrote:
>
> This is a direct connection between the two chips on a PCB.
>
> Regards,
> Mark
> —
> Mark Ste
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 l
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 with
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
> 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 a
17 matches
Mail list logo
