Forum Rule: Always post complete source code & details to reproduce any issue!
Page 1 of 2 1 2 LastLast
Results 1 to 25 of 33

Thread: Weird Hardware Serial Problem on Teensy 3.0

  1. #1

    Weird Hardware Serial Problem on Teensy 3.0

    Hi Paul,

    I'm experiencing a very very strange problem on one of the Teensy 3.0. My project has progressed a bit but recently found strange behavior on received bytes from Serial1. We often receive partial data and couldn't identify the source. We initially thought i was cabling issue, but every time when we reboot Teensy we'd be able to read about 10-20 bytes before it hangs somewhere. We are using baudrate 4800, which should be considered very low. I tested on other Teensy and with exactly the same .hex file, the other board doesn't have this issue. What could be the reason?

    I have created a snippet which is able to demo the problem.
    [pre]
    void setup() {
    Serial.begin(115200);
    while (!Serial);
    Serial1.begin(4800);
    }

    void loop() {
    while (Serial1.available()) {
    Serial.print("A: ");
    Serial.println(Serial1.available());
    Serial1.read();
    }
    }
    [/pre]

    The result is something like
    A: 4
    A: 3
    A: 2
    A: 1
    A: 4
    A: 3
    A: 2
    A: 1
    A: 4
    A: 3
    A: 2
    A: 1
    A: 4
    A: 3
    A: 2
    A: 1
    A: 2
    A: 1
    And it hangs there despite I'm still feeding from serial controller.

    The feeder program is as follows:
    [pre]
    #!/usr/bin/python
    import serial
    with serial.Serial('/dev/ttyUSB0', 4800, timeout=None) as ser:
    while True:
    ser.write('\xBC\xE9\x04\x33\x34\x38\x30\x88')
    ser.write('\xBC\xEF\x08\xAC\x73\x14\x00\x40\x2D\x2 F\x06\x78')
    time.sleep(2)
    [/pre]

    My further investigation shows whenever Teensy meets time sleep, it will likely hangs there forever and every call to Serial1.available() would return 0 and any read from Serial1.read() will return -1.

    We are using this to convert from a RS485 wire to 3.3V
    https://www.sparkfun.com/products/10124

    RX to RX, TX to TX with nothing else connected.

    Teensy is powered by a ATX VSB which should be very stable at around 5.03V.

    Very much willing to know what went wrong.

    Regards,
    Bai Shi

  2. #2
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,412
    Quote Originally Posted by baishi View Post
    We are using this to convert from a RS485 wire to 3.3V
    https://www.sparkfun.com/products/10124

    RX to RX, TX to TX with nothing else connected.
    Did you connect the RTS pin to GND on that Sparkfun board?

  3. #3
    Hi Paul,

    I assume we have connected RTS pin to GND otherwise it shouldn't receive the initial few bytes, should it? Do you assume that if RTS is floating it may cause intermittent problem of receiving? But I don't think it should be the case as each time I re-upload Teensy program it will allow me to receive data until the first pause.

    The actual wiring is done by my colleague, I will check with him to confirm.

  4. #4
    Senior Member
    Join Date
    Nov 2012
    Posts
    1,526
    Code:
    ser.write('\xBC\xEF\x08\xAC\x73\x14\x00\x40\x2D\x2 F\x06\x78')
    It might be significant that it hangs at 'x2 F' which probably should not have a space.

    Pete

  5. #5
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,412
    Well, if the hardware were here on my desk, I would first connect RTS to GND. It should not be left floating. Floating digital control pins are notorious for strange problems, where things seem to work in some conditions but fail in others. I personally can not hear anyone saying "but it works when..." over the sound of "an important digital control pin is floating".

    I'm not a Python expert, but my understanding is that program keeps transmitting data forever in an infinite loop, right? If not, I'd make it do so.

    Then I'd run the test. I'd look at the signal on pin 0 with a scope, or even just a LED+resistor, so see if the RS485 chip is still sending data into pin 0 while Teensy appears to get stuck.

  6. #6
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,412
    Quote Originally Posted by baishi View Post
    The actual wiring is done by my colleague, I will check with him to confirm.
    You could also post a photo here.

  7. #7
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    RTS is an output, of course.
    RTS="request to send".
    Last edited by stevech; 01-27-2014 at 07:06 PM.

  8. #8
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,412
    RTS on Sparkfun's breakout board is an input (see Sparkfun's schematic and the chip datasheet). It's meant to be controlled by the RTS output from a serial port. If left floating, it could cause the chip to disable its receiver.

  9. #9
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    I'd call it RTS-IN.
    Always confusing, these DTE/DCE things. So too, SPI: I liked the use of MOSI and MISO rather than DIN, DOUT as the latter is ambiguous as to direction.

  10. #10
    Senior Member
    Join Date
    Nov 2012
    Posts
    275
    I'm using the same RS485 breakout from sparkfun with a Teensy 3.0 at 9600 baud. It runs for days without problems.

    Connected as the image below. (3-5V/VCC from the RS485 breakout is connected to Teensy's 3.3V )
    Click image for larger version. 

Name:	Capturers485.PNG 
Views:	546 
Size:	34.4 KB 
ID:	1339



    note: rx goes to tx and vice versa.

    RTS has to be high when the Teensy does write to the RS485 Bus (and low to receive).
    Last edited by HWGuy; 01-28-2014 at 12:10 AM.

  11. #11
    Quote Originally Posted by el_supremo View Post
    Code:
    ser.write('\xBC\xEF\x08\xAC\x73\x14\x00\x40\x2D\x2 F\x06\x78')
    It might be significant that it hangs at 'x2 F' which probably should not have a space.

    Pete
    Thanks Pete, but it is a layout problem of the forum post, maybe i shall use code block instead of pre block. Anyway if there is a space at that position, the program will fail with unexpected character before even able to run.
    Regards,
    Bai Shi

  12. #12
    Quote Originally Posted by PaulStoffregen View Post
    Well, if the hardware were here on my desk, I would first connect RTS to GND. It should not be left floating. Floating digital control pins are notorious for strange problems, where things seem to work in some conditions but fail in others. I personally can not hear anyone saying "but it works when..." over the sound of "an important digital control pin is floating".

    I'm not a Python expert, but my understanding is that program keeps transmitting data forever in an infinite loop, right? If not, I'd make it do so.

    Then I'd run the test. I'd look at the signal on pin 0 with a scope, or even just a LED+resistor, so see if the RS485 chip is still sending data into pin 0 while Teensy appears to get stuck.
    Hi Paul,

    I checked with my colleague the RTS pin is connected to Teensy and is pulled to Digital 0 by Teensy output. So this should not be the cause of missing data.

    Yes the program keeps transmitting chunks of data with a 2 sec interval. No matter what the data is, when the transceiver encountered the 2 second delay, any further data will not be visible from Teensy. I tried change chunk size to 10 bytes, 100 bytes, 1KiB, and it all stops at the 2 second delay and never come back.

    We connected with a scope and it looks fine on Pin 0. Actually such a semi passive device shouldn't stop responding after encounter empty transmission. Also our test on any other Teensy works without a single glitch. Just this one.

    Regards,
    Bai Shi

  13. #13
    Quote Originally Posted by HWGuy View Post
    I'm using the same RS485 breakout from sparkfun with a Teensy 3.0 at 9600 baud. It runs for days without problems.

    Connected as the image below. (3-5V/VCC from the RS485 breakout is connected to Teensy's 3.3V )
    Click image for larger version. 

Name:	Capturers485.PNG 
Views:	546 
Size:	34.4 KB 
ID:	1339



    note: rx goes to tx and vice versa.

    RTS has to be high when the Teensy does write to the RS485 Bus (and low to receive).
    Thanks HWGuy, we are using same wiring except that we use 3.3V instead of 5V. The breakout looks working fine.

    Best Regards,
    Bai Shi

  14. #14
    Attached waveform on Pin0. It looks working fine all the way.

    I tweaked the delay between chunks and found that 0.1 second will not cause problem of the serial, but 0.2 second sleep will make it sleep forever.

    Regards,
    Bai Shi
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	pin0.jpg 
Views:	130 
Size:	48.3 KB 
ID:	1346  

  15. #15
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,412
    Quote Originally Posted by baishi View Post
    Also our test on any other Teensy works without a single glitch. Just this one.
    How many different boards are you testing?

    Sounds like this is probably just a random (and strange) hardware problem. If it's just an isolate incident on only 1 board, let's just send you a replacement and not pour more time into this.

    But if it's a problem that reoccurs on multiple boards, of course I want to get to the bottom of it.

  16. #16
    Quote Originally Posted by PaulStoffregen View Post
    How many different boards are you testing?

    Sounds like this is probably just a random (and strange) hardware problem. If it's just an isolate incident on only 1 board, let's just send you a replacement and not pour more time into this.

    But if it's a problem that reoccurs on multiple boards, of course I want to get to the bottom of it.
    Hi Paul,

    Our further investigation shows that seems that Serial1 of Teensy hardware serial have some compatibility problem with this sparkfun transceiver. We tested on 3 Teensy 3.0 and 1 stopped half way, 2 continue to receive data from serial. We tested on 3 Teensy 3.1, all of them stopped since first pause of transmission. What's more interesting is that Serial2 and 3 is not affected.

    After we change to a brand new 485-232 transceiver, all hardware serial is happy with the data.

    I'll connect two Sparkfun modules together on Monday to see what in hell is different between a working one and non-working one.

    Will update in due course.

    Best Regards,
    Bai Shi

  17. #17
    Administrator Paul's Avatar
    Join Date
    Oct 2012
    Posts
    386
    I do have a pair of ST3485 chips here, which should be very similar to the ones on those Sparkfun boards. If necessary, I could get a couple of those boards from Sparkfun.

    Just say the word (with sample code) if you think I should wire up a test here.....

    It might indeed be a bug in my code? Very hard to say at this point.

  18. #18
    Quote Originally Posted by Paul View Post
    I do have a pair of ST3485 chips here, which should be very similar to the ones on those Sparkfun boards. If necessary, I could get a couple of those boards from Sparkfun.

    Just say the word (with sample code) if you think I should wire up a test here.....

    It might indeed be a bug in my code? Very hard to say at this point.
    Hi Paul,

    Just give me two days. It is local holiday here and there is 10+ hours time difference. There is some weirdness in one of the 485-232 converter, but I still don't know what indeed it is. Will update you once i get touch to it.

    Regards,
    Bai Shi

  19. #19
    Quote Originally Posted by baishi View Post
    Hi Paul,

    Just give me two days. It is local holiday here and there is 10+ hours time difference. There is some weirdness in one of the 485-232 converter, but I still don't know what indeed it is. Will update you once i get touch to it.

    Regards,
    Bai Shi
    Hi Paul,

    Here is the update. It seems the problematic rs485 breakout's power level for idling is 0v instead of 3.3v. Thus it confused Teensy hardware serial. Though I'm not sure why Serial2 and Serial3 seems pretty happy with this.

    I think it doesn't worth much effort to cater for the irregular voltage level.

    I have attached waveform on the pin0, if you'd like to refer to.

    Thank you very much for your attention.

    Best Regards,
    Bai Shi
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	pullup.jpg 
Views:	129 
Size:	62.2 KB 
ID:	1371  

  20. #20
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,412
    Oh, I see. Does adding a 10K pullup resistor on RX1 make it work on Serial1?

  21. #21
    Member dhylands's Avatar
    Join Date
    Nov 2013
    Location
    Shuswap, BC, Canada
    Posts
    45
    Being low for more than a character time or so generates a break condition which might be a factor.

  22. #22
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    is the 'scope displaying inverted data? The UART has an invert option config bit IIRC.

  23. #23
    Quote Originally Posted by PaulStoffregen View Post
    Oh, I see. Does adding a 10K pullup resistor on RX1 make it work on Serial1?
    No it didn't really work. The RS485 breakout pulls to ground when it is idle. Even if i put a 120Ohm pull up it barely manage to pull up to 1.x V on idle. I think the RS485 breakout is beyond repair if I'm not wrong.

  24. #24
    Quote Originally Posted by stevech View Post
    is the 'scope displaying inverted data? The UART has an invert option config bit IIRC.
    Hi Steve,

    Do you know how to invert the data? The UART you mentioned as in the UART in Teensy3 or the RS485 breakout? I couldn't dig it out though.

    Actually my finding seems that the space and mark are identical to a brand new RS485 breakout. Just that the idle is different. It might not be inverting, just being pulled down on idle. I might be wrong though.

    If you can advice how to set the inverting config, I can give it a try.

    Best Regards,
    Bai Shi

  25. #25
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,412
    Quote Originally Posted by baishi View Post
    The RS485 breakout pulls to ground when it is idle.
    Oh, that doesn't sound right...


    Quote Originally Posted by baishi View Post
    I think the RS485 breakout is beyond repair if I'm not wrong.
    Do you believe it's a fundamental design problem with this Sparkfun product (eg, all of them would do this), or just one product that's damaged or defective?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •