Weird Hardware Serial Problem on Teensy 3.0

Status
Not open for further replies.

baishi

Member
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\x2F\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
 
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.
 
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
 
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.
 
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.
 
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.
 
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 )
Capturers485.PNG



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:
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
 
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
 
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 )
View attachment 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
 
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
 

Attachments

  • pin0.jpg
    pin0.jpg
    48.3 KB · Views: 179
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.
 
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
 
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.
 
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
 
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
 

Attachments

  • pullup.jpg
    pullup.jpg
    62.2 KB · Views: 202
Being low for more than a character time or so generates a break condition which might be a factor.
 
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.
 
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
 
Status
Not open for further replies.
Back
Top