MicroPython
Replies: 5 comments 7 replies
-
|
Most likely, thonny is not the right tool to test for "errors" like this, unless you know exactly what thonny does/tries to do with the serial connection. |
Beta Was this translation helpful? Give feedback.
-
|
I am not familiar with mpremote.
When I connect with mpremote I can see my print statements coming and hitting CTRL+C during this loop will end up having mpremote getting stuck, not reading from serial anymore. |
Beta Was this translation helpful? Give feedback.
-
|
With mpremote I can easily also enter the same state: |
Beta Was this translation helpful? Give feedback.
-
|
@TRadigk is this a new problem (i.e. was the board previously working), or is it the first time using the board? I ask because we used to have two different configurations for this board which we just merged into one at the end of last week. (See #12270). You're using the new merged configuration. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @jimmo The esptool encounters the same issue: (chip auto or esp32 doesn't make any difference, since the esp32 is detected correctly anyway) |
Beta Was this translation helpful? Give feedback.
-
|
Pymakr is an unsupported product of the company Pycom, which ceased operation about a year ago. Even before, Pymakr had the habit of failing with almost every new version of VS Code. So better change horses. |
Beta Was this translation helpful? Give feedback.
-
|
Hi robert, I liked the integration in vs code, which I use for my micropython projects. I didn't yet find any suitable replacement, but I admit I didn't look very far. But with this I found an opportunity for a new project. @ALL: |
Beta Was this translation helpful? Give feedback.
-
|
One thing still remains curious: why does this (USB-C based ESP32-C3) board remain special in this regard? I can't get past that 🤯 Edit: The issue is very deceiving. At some point one could think "now I got it", but this is only true because I have entered the state where the connection always works. It remains: when power was disconnected, getting a stable connection is very difficult. Edit2: The most reliable solution currently is to set RTS on, wait 300 ms and set RTS off before sending first bytes. I know that the 0x0D in front of 0x03 is redundant. Didn't change anything having it there or not. |
Beta Was this translation helpful? Give feedback.
-
|
I thank everyone for participating 🙏. I got it. Resolution (and how I got there)I finally started a series of tests varying many different serial port options (baudrate, stopbits, handshake, dtrenable, rtsenable) to find no combination that works with every MCU. But stubborn as I am, I took another look into pyboard transport, because it always showed to be working. portinfo = list(serial.tools.list_ports.grep(device)) # type: ignore
if portinfo and portinfo[0].manufacturer != "Microsoft":
# ESP8266/ESP32 boards use RTS/CTS for flashing and boot mode selection.
# DTR False: to avoid using the reset button will hang the MCU in bootloader mode
# RTS False: to prevent pulses on rts on serial.close() that would POWERON_RESET an ESPxx
self.serial.dtr = False # DTR False = gpio0 High = Normal boot
self.serial.rts = False # RTS False = EN High = MCU enabledAnd since my C# driver never differentiated between the driver manufacturers I decided to implement this feature anyway. As the pyboard transport does I now switch off Dtr and Rts when the driver has not manufacturer "Microsoft", which is true for the wch driver used for the ESP32 CH340 board. This is the C# code for everyone interested: Note: in .net (included in .net framework) the additional nuget package System.Management is required. private bool IsMicrosoftDriver(string comPort)
{
var objSearcher = new ManagementObjectSearcher("root\\CIMV2",
"SELECT * FROM Win32_PnPEntity WHERE ClassGuid=\"{4d36e978-e325-11ce-bfc1-08002be10318}\"");
var objCollection = objSearcher.Get();
var providedComPorts = new Dictionary<string, string>();
foreach (ManagementObject obj in objCollection)
{
string rawName = (string)obj["Name"];
int nameStart = rawName.IndexOf('(') + 1;
int nameStop = rawName.IndexOf(")", StringComparison.Ordinal);
string comName = rawName.Substring(nameStart, nameStop - nameStart);
providedComPorts.Add(comName, (string)obj["Manufacturer"]);
}
return providedComPorts[comPort] == "Microsoft";
} |
Beta Was this translation helpful? Give feedback.
-
|
Happy to read that those changes and comments are of use to you If you want I have some automated tests for reset and reconnect cases as well. Note that recently there are new serial chips being used. Thus far the "non Microsoft" seems to hold true as intended, but frankly there is a bit of luck involved as well. Lastly, I suggest to raise this with Thonny so they can implement similar logic. |
Beta Was this translation helpful? Give feedback.
-
|
Also, on the espxx series you can hook up a logic analiser to the rx/t pins to trace what is happening when the host is doing other things, and missing out on relevant output. |
Beta Was this translation helpful? Give feedback.
-
|
Actually I think there is no issue with Thonny (to raise). I think that my C# driver with the wrong connection properties (e.g. DtrEnable and / or DtsEnable with the MCU where it should be false) kind of blocked the serial port of windows. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi everyone,
I can't say for sure the title is correct, but my findings indicate a bug specific to the USB variant of the ESP32 port. When trying to connect to the board (in this instance a https://wiki.seeedstudio.com/XIAO_ESP32C3_Getting_Started/) it is important to reset the board via the onboard reset switch and very quickly connect, e.g. via Thonny.
Taking too much time in this process will always lead to WriteTimeout on serial connection, like so:
I also tried other programs like HTerm to discover that a connection with 115200 Baud is not supported (though I think this is irrelevant?!?):
And also the number of StopBits has to be configured to "1.5".
Even when the connection is possible, HTerm is not able to receive data while the board is sending data periodically. Only when performing hard reset and quickly disconnecting/connecting to the board again allows to send/receive data:
Why I think this an issue with the micropython port?
It "feels" like the device must see an open connection when the bootloader hands over control to micropython.
Is there anything else I should be able to provide when converting this discussion to an issue?
Beta Was this translation helpful? Give feedback.
All reactions