Portenta H7 serial communication with .Net

Official Hardware Portenta Family Portenta H7
1

Has anyone been able to communicate with the Portenta via the .Net System.IO.Ports library?

I am able to communicate with my Portenta via PuTTY or the IDE serial monitor. In many projects I use .Net and I am able to communicate with Uno, Mega, etc with the System.IO.Ports. However. With the Portenta I am not able to communicate at all even with the same settings that work for e.g. an Uno. I have tried multiple handshakes etc...

Any thoughts? What would be the differences that would make it work with others but not the Portenta?

2

I am not using that lib just C but had the same problem that you describe: A serial client worked fine with an Arduino Uno but not with the Portenta H7. Eventually I found this page, and it was the tcgetattr(serial_port, &tty) != 0) on line 19 that did the trick. Maybe something like that will work for you.

3

Thanks henksb for your idea.

The issue turns out to be that with Porenta, you need to enable DTR. For anyone else who comes across this, working code looks like:

using System.IO.Ports;

namespace TestSerial
{
    internal class Program
    {
        static async Task Main(string[] _)
        {
            SerialPort p = new("COM6", 115200, Parity.None, 8, StopBits.One);
            p.Handshake = Handshake.XOnXOff;
            p.WriteTimeout = 1000;
            byte[] send = new byte[1] { 49 };
            // this line is critical for Portenta H7, but not needed with Uno, etc...
            p.DtrEnable = true;

            p.Open();
            try
            {
                //p.Write(send, 0, send.Length);
                p.BaseStream.WriteByte(send[0]);
                p.BaseStream.Flush();
                await Task.Delay(100);
            }
            finally
            {
                p.Close();
                p.Dispose();
                await Task.Delay(100);
            }
        }
    }
}
1 Like
4

To be honest: I am a bit lost:
a) UART via USB-C is a pure VCP device. There is not any UART involved, it is native USB connection. A DTR signal does not matter here (and should not have any effect).

b) if you connect another chip, as a real UART chip (with USB to host): sure, this might need DTR for flow control.

But it should be always possible to run an UART without DTR, w/o flow control (or with SW flow control).
You can still implement your own protocol, like: have a ping-ping for UART transmission so that you avoid an overflow on any side.

A DTR signal should be a HW signal. And USB-C UART as VCP does not have such one.

And strange is also:
you enable Handshake.XOnOff - the SW flow control. Why would you need now also DTR ? (for HW Flow Control). It sounds more like: your external UART-to-USB dongle is not properly setup (wired).

It sound to me more like:
You have connected an external UART adapter, e.g. using Tx, Rx from MCU board and providing the UART via USB.
This external adapter wants to see a DTR signal, just to release the external board UART chip.
But from MCU point of view - this DTR is not needed. It seems to be your external HW connected which wants to see it.

Actually, if it would be a "UART-USB" chip: you can "tell" (configure) this external "USB-dongle" not to use HW-handshake (no DTR) needed.
But still necessary to set DTR signal on this board to enable it. If DTR is floating or not connected properly - it might block the HW (of your external dongle).

I am sure, USB-C UART, actually any UART, can be used w/o HW-protocol, w/o DTR.|
But for very fast and huge data - you need a larger FIFO or your own flow control.

5

I believe I tested this with 2 normal windows 10 machines hooking the unit up via a USB port. Same outcome on both. The set speed or amount of data had no impact on the results.

Not sure what else to say. I agree other serial programs on the same machine (e.g. putty) do not require DTR to work. I'm not familiar enough with the chip or library internals to know whats going on here.

Its fairly easy to test this. If you do please let me know the outcome.

6

Do you use the UART provided on the USB-C connector?
Or have you connected another UART chip on MCU pins with a separate USB to host?

The USB-C UART is not really a UART: it is a VCP device. It does not have any DTR feature. And at the end: you can select any UART speed in terminal setting (just the USB matters but any baud rate is fine). And if I select hardware protocol (which would be DTR) - in TeraTerm via this USB-C VCP - it does not have any effect.

It sounds to me as: you have a separate UART breakout board connected.
What is this "COM6"?
Is it the "Virtual COM Port"? (or another second UART device)

7

BTW: when I use Python UART to talk via this USB-C UART - I have never enabled such DTR. When you try with Python - does it fail in the same way?

It looks like your code is C# on Windows host - so, potentially not a question about Portena H7 itself.
And Handshake.XOnXOff is not related to hardware protocol (it is software protocol), DTR is not used with this SW protocol.
So, I guess, your C# environment wants to see this XOn/XOff handshake to release the UART (On Windows C#, OS). I cannot imagine it is related to Portenta H7.

8

I'm using the H7 the same way I've used any other Arduino.

  • Connect Arduino into a USB port on the host PC.
  • It shows up as a virtual com device ("COM6" here) Windows Device Manager
  • Use that com port to communicate

This is the only device I have this issue. Uno, Mega, Due all work fine.

As stated in the original post: PuTTY, serial monitor, etc.. also work fine with the H7. It is only the .Net library, which works with other devices, but does not work with the H7. I will try Python if I have time tonight.

9

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.