UART Communication Issue Between Two Devices (Teensy 4.0 and MSPM0)

P

procoderer

New member
Hi all,

I'm working on getting UART communication running between two devices:
  • Device1: MSPM0 microcontroller
  • Device2: Teensy 4.0
Both devices are configured for 115200 baud, 8 data bits, no parity, 1 stop bit (8N1).

However, I’m encountering some strange behavior:
  • If bytes from Device2 (Teensy 4.0) are sent rapidly (with no delay between them), they sometimes get merged or misinterpreted on Device1 (MSPM0). There's a mostly consistent but incorrect mapping of the received bytes — the same garbled byte(s) appear for the same tightly packed message.
  • If I add a 1 ms delay between each byte sent from Device2, the received data on Device1 becomes a 1:1 mapping (one byte received per one sent) — but the received values are always 0xFF or 0xFE, regardless of what was sent.
  • Sending from Device1 to Device2 results in each single byte being received as two bytes: 0x00 0x00 on Device2, even with a 1 ms delay between each byte.
Has anyone run into this kind of issue before?

Any suggestions on what might be causing this would be greatly appreciated.

Thanks!
 
Have you tried slower speeds? e.g. 9600?
Perhaps there's a mismatch of polarity or voltage between the two devices?
Do you have a link to a reference manual for the MSPM0?

Pete
 
el_supremo said:
Have you tried slower speeds? e.g. 9600?
Perhaps there's a mismatch of polarity or voltage between the two devices?
Do you have a link to a reference manual for the MSPM0?

Pete
Click to expand...
I have tried slower speeds, and it doesn't seem to change the behavior.
Here is a link to the reference manual for the MSPM0.

Thanks!
 
Are the UARTS hard wired pin-to-pin (TX->RX) or are UART pins going thru RS-232 line transceivers?
What's the distance between Device1 and Device2?

You could try a simple UART loopback at each Device (connect its TX to its own RX pin) to see if it can receive it's own transmission properly.
 
BillFM said:
Are the UARTS hard wired pin-to-pin (TX->RX) or are UART pins going thru RS-232 line transceivers?
What's the distance between Device1 and Device2?

You could try a simple UART loopback at each Device (connect its TX to its own RX pin) to see if it can receive it's own transmission properly.
Click to expand...
They're going thru a transceiver on the Device1 side: the TI ISO7721-F.

On the Device2 side, it's just level shifters and I'm 100% confident that the Device2 hardware is correct since it's been used for a while with comms with a different device.

Device1 and Device2 are less than a meter apart.

Thanks!
 
Okay. Thanks for the details.

So Device1 is the new kid in town. I think the loopback test is where you need to focus.
It would also help if you have access to an oscilloscope to monitor the TX signal from Device1.

I assume ISO7721 is being used because you require isolation (since both Teensy and MSPM0 operate at 3.3V at their I/O pins)? Is this the case in your setup?
I'm hoping you don't have any 5V signals touching any Teensy I/O pins.

Which MSPM0 GPIO pins are used for TX/RX? You may have accidently configured an open-drain pin for TX (requiring a pull-up resistor).
 
Adding some color here as I'm the hardware engineer on this (procoderer is firmware):

ISO7721 is being used as Device1 can have a substantially different ground reference voltage.

No 5V on Teensy I/O - everything is level-shifted to 3.3V for the UART.

Here's a screenshot of the relevant portion of the schematic for Device1:
1747611957794.png


Let me know if you guys have any ideas!
 
BillFM said:
It would also help if you have access to an oscilloscope to monitor the TX signal from Device1.
Click to expand...

Agreed, this is really a job for an oscilloscope.

Ideally for the sake of testing you would short the 2 grounds together and connect to the scope's ground. Then you could watch the signal Teensy sends and the copy of it the other chip receives.

I don't have your non-Teensy hardware, but if you show the program that's transmitting bytes, I can copy it into Arduino IDE here and run on a Teensy 4.0 and connect my scope to see the waveform it's actually transmitting. If you search this forum, you'll find many other hardware serial questions where I captured the waveforms with my scope. But if you think something might be amiss with the Teensy side, maybe some unusual effect due to the way your program does things, maybe capturing Teensy's transmit waveform could help show whether the signal coming from Teensy's transmit pin is correct. I can't help much with the other hardware, but I can at least do that.


To specifically answer this:

procoderer said:
Has anyone run into this kind of issue before?
Click to expand...

I can't recall anyone describing precisely the conditions you've said so far.

Regarding general kinds of problems, many times we've heard the unable to sync starting in the middle of 100% bandwidth usage. But that doesn't match your description where most data arrives correctly but some bytes are corrupted. That problem is also known to be solved by having a gap of 9 or more bit times, so the description of adding 1ms delay causing bytes to be received at 0xFF or 0xFE also doesn't match up.

Generally speaking, with hardware serial the unexpected reception of 0xFF or 0xFE bytes usually means the receiving UART heard a pulse or noise which is believed was the start bit. Data is LSB first, so 0xFF usually means a short pulse followed by line idle for the 8 data bits, and 0xFE usually means whatever noise/pulse was seen lasted into the first data bit, then the rest of the time was line idle.

At this point it's pretty much all blind guesswork. A oscilloscope would really let you see the waveforms.
 
PaulStoffregen said:
that doesn't match your description where most data arrives correctly but some bytes are corrupted
Click to expand...

To explain just a bit further, the unable to sync on 100% bandwidth problem has every byte corrupted at the receiver, but they all do arrive at the correct pace. It only happens if the transmitter is already in the middle sending when the receiver begins to listen (eg, due to new code uploaded while the transmitter was still sending). Without any gaps, it can mistake any of the low data bits as the start bit, repeating forever if the data pattern continues having low data bits. Here's a prior conversation where it was explained with a good oscilloscope capture of the waveform.


This problem is a general issue with all hardware serial communication, but it's seen more often with Teensy because the CPU is so fast. With many other microcontrollers the slow CPU speed results in small pauses in transmission. If the transmit code doesn't implement a buffer or only a very small buffer (common on many lower end chips), transmit gaps are also pretty likely while code works on other tasks. But with a very fast CPU and good interrupt-based buffer transmit and a small FIFO in the UART transmitter, achieving 100% serial bandwidth transmit with Teensy 4.0 is pretty easy, even at high baud rates, even if your program does quite a lot of other work. Normally faster is better, but with hardware serial when you have 100% sustained bandwidth usage, the receiving UART needs to be listening before the first start bit or else it may receive out of sync and never manage to sync to the intended start bits.
 
PaulStoffregen said:
Agreed, this is really a job for an oscilloscope.

Ideally for the sake of testing you would short the 2 grounds together and connect to the scope's ground. Then you could watch the signal Teensy sends and the copy of it the other chip receives.

I don't have your non-Teensy hardware, but if you show the program that's transmitting bytes, I can copy it into Arduino IDE here and run on a Teensy 4.0 and connect my scope to see the waveform it's actually transmitting. If you search this forum, you'll find many other hardware serial questions where I captured the waveforms with my scope. But if you think something might be amiss with the Teensy side, maybe some unusual effect due to the way your program does things, maybe capturing Teensy's transmit waveform could help show whether the signal coming from Teensy's transmit pin is correct. I can't help much with the other hardware, but I can at least do that.


To specifically answer this:



I can't recall anyone describing precisely the conditions you've said so far.

Regarding general kinds of problems, many times we've heard the unable to sync starting in the middle of 100% bandwidth usage. But that doesn't match your description where most data arrives correctly but some bytes are corrupted. That problem is also known to be solved by having a gap of 9 or more bit times, so the description of adding 1ms delay causing bytes to be received at 0xFF or 0xFE also doesn't match up.

Generally speaking, with hardware serial the unexpected reception of 0xFF or 0xFE bytes usually means the receiving UART heard a pulse or noise which is believed was the start bit. Data is LSB first, so 0xFF usually means a short pulse followed by line idle for the 8 data bits, and 0xFE usually means whatever noise/pulse was seen lasted into the first data bit, then the rest of the time was line idle.

At this point it's pretty much all blind guesswork. A oscilloscope would really let you see the waveforms.
Click to expand...
To clarify, most data doesn't arrive correctly. None of the data arrives correctly (unless by coincidence).
 
Please understand we're blind guessing here. We can only see what you've shown us, which so far is almost nothing.

I tried to answer your question whether we've seen this before. But keep in mind I really can't see almost anything right now.

Best way to see would be with an oscilloscope. But maybe if you show us the code running on both sides and the actual data (ideally a screenshot) so we can see what you're actually seeing, perhaps better guessing may be possible. Right now, we're blind guessing based only on your words that imprecisely describe what you're seeing. So far noboby but you has seen the actual bytes received or the code running on both sides doing this work.
 
Based on schematic above, it appears the 5V side of ISO7721 is connected to Teensy (EXT_RX, EXT_TX) and the 3.3V side is connected to MSPM0 U1 (EXT_RX_3V3, EXT_TX_3V3). This configuration will damage Teensy. Or, have you added additional level shifting (not shown on schematic above) between Teensy and ISO7721. Please confirm or explain.
 
Last edited:
On the 3V3 side of the ISO7721, the signal EXT_RX_3V3 is connected to INA. It seems it is the UART TX signal. Correct ???

It could make confusion for other persons than the schematics creator. TX pin should be named ".....TX....", on both sides
 
They're going thru a transceiver on the Device1 side: the TI ISO7721-F.

On the Device2 side, it's just level shifters and I'm 100% confident that the Device2 hardware is correct since it's been used for a while with comms with a different device.
Click to expand...

RS232 transceivers invert the signal, level shifters don't. Are you sure things aren't getting inverted?

Check on the uart logic level pins, things should be idling high, if the idle voltage is low then you have an inversion going on. Or check on the connection between the two, both pins should have the same idle voltage ( around -5V for RS232 ). If they are at different levels then that is another sign of a polarity mismatch.
 
BillFM said:
Based on schematic above, it appears the 5V side of ISO7721 is connected to Teensy (EXT_RX, EXT_TX) and the 3.3V side is connected to MSPM0 U1 (EXT_RX_3V3, EXT_TX_3V3). This configuration will damage Teensy. Or, have you added additional level shifting (not shown on schematic above) between Teensy and ISO7721. Please confirm or explain.
Click to expand...

Yes, there is level-shifting on the Teensy side so everything is at 3.3V when it hits Teensy I/O.

This schematic is just for Device1
 
AndyA said:
RS232 transceivers invert the signal, level shifters don't. Are you sure things aren't getting inverted?

Check on the uart logic level pins, things should be idling high, if the idle voltage is low then you have an inversion going on. Or check on the connection between the two, both pins should have the same idle voltage ( around -5V for RS232 ). If they are at different levels then that is another sign of a polarity mismatch.
Click to expand...
This is one thing I've considered, I'm out of office until Friday but will be scoping things then.

Will update once I've done some work with the scope! Thanks all
 
Angelo said:
On the 3V3 side of the ISO7721, the signal EXT_RX_3V3 is connected to INA. It seems it is the UART TX signal. Correct ???

It could make confusion for other persons than the schematics creator. TX pin should be named ".....TX....", on both sides
Click to expand...

Yes, EXT_RX_3V3 is just the 3.3V level of Device2's Rx (so it's Device1's Tx from the M0L MCU)
 
You must log in or register to reply here.
Back
Top