Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simple Loopback not working #10

Open
ipatix opened this issue Jul 9, 2019 · 2 comments
Open

Simple Loopback not working #10

ipatix opened this issue Jul 9, 2019 · 2 comments

Comments

@ipatix
Copy link

ipatix commented Jul 9, 2019

So I was having some issues with pill_serial where I wanted to connect the UART to some external device and it was loosing data for some reason.

This might possibly be related to #1

Basically, in my test I connect PA9 to PA10, PB10 to PB11, and PA2 to PA3.
I do the same thing with an off the shelve USB to UART converter.

Then I run this Python Program which tests if the data it sends comes back:

#!/usr/bin/env python3

import serial
import os

s = serial.Serial("/dev/ttyUSB0", 115200)

iteration = 0

while True:
    barr = bytearray(os.urandom(1))
    s.write(barr)
    aarr = s.read(len(barr))

    for i in range(0, len(barr)):
        if aarr[i] != barr[i]:
            raise Exception("Received data doesn't match: data=" + str(barr[i]) + " device=" + str(aarr[i]))
    print("iteration sucessfull: " + str(iteration))
    iteration += 1

On the off the shelve USB to UART converter it runs flawless. On the pill_serial none of the /dev/ttyACM[0-2] work with this.
It's not like the device doesn't work for me at all. It just seems to work very unreliably and in this test case I managed to make it always fail.

@ipatix
Copy link
Author

ipatix commented Jul 9, 2019

#1 (comment)

I actually just tried this solution with the define to 32. While it makes the Python script not freeze immediately, the test will hang up after somewhere in between 10000 and 100000 iterations.
The test doesn't fail with corrupted data but rather it just seems to drop a byte. Therefore it'll hang in the s.read(1). It could certainly also be an electrical issue with the UART, still, my wires are pretty short and it happens accross all 3 UART ports. No such issue with the off the shelve part (and pretty long wires on that one).

Without reading the firmware code I'd suspect a more serious bug than a simple buffer size being too small. I'm just sending one byte over the UART until a single byte comes back. So there shouldn't be any buffers building up and/or overflowing.

@stappersg
Copy link

Quoting the datasheet of the STM32F103RC

USART1, USART2 and USART3 also provide hardware management of the CTS and RTS signals,

My educated guess is that connecting Clear To Send and Request To Send will improve the situation. But please be aware that I'm saying this without reading the firmware source code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants