The device on the "COMx" Port Is not compatible

[rusudanion]

Hello to all ,i have a problem with connection between PC and any esp32 . I have this error any time i try to connect any esp32 device with ESP32-MPY Jama "The device on the "COM x" Port Is not compatible".
the esp device works with other tool for flashing.
Thankyou

[jczic]

Hi @rusudanion,
I have 2 questions first: what OS are you on and more importantly, what version of MicroPython are you using on your ESP32 device?
When you say "other tools for flashing", do you mean the esptool command line tool?
Please, give me as much information as possible.

[rusudanion]

Hi @rusudanion, I have 2 questions first: what OS are you on and more importantly, what version of MicroPython are you using on your ESP32 device? When you say "other tools for flashing", do you mean the esptool command line tool? Please, give me as much information as possible.

Hello i use Windows 10 , i use last version of micropython 1.20 . the tools used for flash was esp32flasher and Chrome extensions.

[jczic]

Ok, thank you for information.

The serial connection under Windows 10 has already been tested and works as well as the good compatibility with the version 1.20 of MicroPython.
So if you have this error, it is may be because ESP32 MPY-Jama cannot communicate with MicroPython's REPL through the serial.

You have been able to flash a firmware on the device but, can you connect correctly to the REPL with a standard serial terminal and get an access to the code prompt?

Also, I see that the ESP Flasher tool uses the basic Espressif esptool tool as well as ESP32 MPY-Jama.
Can you try to flash a firmware on one of your devices by accessing it via the Firmware Tools menu section, so that we can check together if this manipulation works.

The goal is to understand if this is due to a serial driver problem (with the different UART pins used) or if it is due to the exchanges with the REPL of MicroPython which could not be done normally.

Thank you for your feedback!

[rusudanion]

Ok, thank you for information.

The serial connection under Windows 10 has already been tested and works as well as the good compatibility with the version 1.20 of MicroPython. So if you have this error, it is may be because ESP32 MPY-Jama cannot communicate with MicroPython's REPL through the serial.

You have been able to flash a firmware on the device but, can you connect correctly to the REPL with a standard serial terminal and get an access to the code prompt?

Also, I see that the ESP Flasher tool uses the basic Espressif esptool tool as well as ESP32 MPY-Jama. Can you try to flash a firmware on one of your devices by accessing it via the Firmware Tools menu section, so that we can check together if this manipulation works.

The goal is to understand if this is due to a serial driver problem (with the different UART pins used) or if it is due to the exchanges with the REPL of MicroPython which could not be done normally.

Thank you for your feedback!

i have various esp32 device with serial chip CP2101 and CH340 . All this device works good with all flasher and home assistant,also the serial Is working.
I Test your program with other PC with windows11 x64 and give me same error. The device on te COM Is not compatible.

ALL ESP32 DEVICE WORKS NORMALY .
I also flash tasmota and no change to see the device.

Same error on ESP32 MPY-Jama TAB FIRMWARE TOOLS

[rusudanion]

if the esp32 Is connected to putty,and i try to connect also to esp32 mpy-jama,i have errore from espjama CANNOT OPEN SERIAL PORT COMx

[jczic]

Ok! If I understand correctly, knowing that normally, the connection works well with all boards and from Win/Mac/Linux, it would then come from a problem of TX/RX blocking on the serial port related to a problem that some people seem to have had by using the last version of the pySerial library (issue from level of other UART lines).
Precisely, with a user under Ubuntu, we just had this similar problem and he had a USB/TTL CH340.

Look at the recent discussion eventually:
#41

I haven't updated the Windows and MacOS binaries yet, but the fix for this problem has been committed to the repository sources.

Can you then try to clone the GitHub repository and run the program from the Python sources on your Windows?
I know it's not as user friendly as the binary setup but there's a good chance it will work.

Do you think you can try this method?
Thanks a lot, I'm waiting for your feedback :)

[jczic]

Just, for "CANNOT OPEN SERIAL PORT COMx" : if the esp32 is already connected to putty, it's normal, Jama requires exclusive access to the serial port.

[jczic]

Also, you have indicated "Same error on ESP32 MPY-Jama TAB FIRMWARE TOOLS", this is really strange because from this page, the software does not connect to the ESP32 but asks the official Espressif tool, esptool, to do it.
This would mean that you can't run esptool either :/

[rusudanion]

Also, you have indicated "Same error on ESP32 MPY-Jama TAB FIRMWARE TOOLS", this is really strange because from this page, the software does not connect to the ESP32 but asks the official Espressif tool, esptool, to do it. This would mean that you can't run esptool either :/

tonight i want to try the pyton fixed version .i know the other thread with same problem ,but i can try Linux version

for connection problem i don't use pyton version of exprestools ,i use exe versions

[rusudanion]

maybe i can reset all and install from begin ,can you tell me what steps i must to do ? thankyou

[jczic]

You need to have python on your machine (recent though) and install the 2 required dependencies with pip.
Then you just have to execute app.py located in the src directory of the repository.
The instructions are here : https://github.com/jczic/ESP32-MPY-Jama#build-and-run
Under Linux you can follow the next paragraph, it is explained.
But I think there will be no problem to make it work under Windows and the last fix should force the disabling of the 2 useless pins on the cable. So basic serial communication should not block :)

[jczic]

Hello @rusudanion, have you been successful since?

[rusudanion]

Hello @rusudanion, have you been successful since?

hello ,i am occupied this week. please alove me few days.thankyou

[rusudanion]

Hello @rusudanion, have you been successful since?

hello tryed today, same problem same error.
the esp Is working with micropython 1.2

i open your tools with command with app.py and ./app.py. same error .

[jczic]

Hmm, then I confess I don't see what the problem is now.

I guess you have cloned the last repository sources with the fix that solved the particular problem of some UART converters and especially the CH340.
So if it still shows you the message that the port is incompatible, it means that the communication to the REPL can't be done normally...

You don't have any other existing connection in parallel, do you?

Can you connect to it with a simple serial terminal so as to arrive at the REPL prompt directly?

So you are under Linux, right?

(just, the error msg comes from an exception here :

ESP32-MPY-Jama/src/esp32Controller.py

Line 201 in d834cda

raise ESP32ControllerException('The device on the "%s" port is not compatible.' % devicePort)

)

[rusudanion]

hello i am with operating system W10 64 ,I have nothing in parallel. The TTL is dedicated to the esp also because it is soldered together. I have TTL CH304 and CP2101 and neither of them is recognized by your program (my devices have been flashed with browser extension or TOOL EXPRESSIF, SO THEY ARE WORKING AND UPDATED), which I just downloaded and started with the app.py command. The program recognizes the com port but when I try to connect it says that the device is incompatible. yes I message and that there.Do you have anything else I can test ?thanks

[jczic]

It's a very strange problem for me and it is not easy to found it.
Eventually, if you edit the source file esp32Controller.py by replacing the block that causes the error with this one in order to display simple step messages to be noticed in the terminal :

        try :
            print('1')
            self.InterruptProgram()
            print('2')
            self._repl.rts = 0
            self._repl.dtr = 0
            print('3')
            self._switchToRawMode(timeoutSec=connectTimeoutSec)
            print('4')
            machineNfo          = self._exeCodeREPL('import uos; [x.strip() for x in uos.uname().machine.split("with")]')
            print('5')
            self._machineModule = (machineNfo[0] if len(machineNfo) >= 1 else '')
            self._machineMCU    = (machineNfo[1] if len(machineNfo) >= 2 else '')
            print('6')
            self._ensureJamaObjExists()
        except ESP32ControllerSerialConnException :
            raise
        except Exception as ex :
            print(ex)
            raise ESP32ControllerException('The device on the "%s" port is not compatible.' % devicePort)

So, by running app.py with Python from your shell (not from the GUI of course), you can easily see what the last step is before the message and the exact error caused.

Is it possible for you to do this? Thank you very much!

[tocrar]

I have the same error and tried to debug a little.
The error always happened in:
self._switchToRawMode(timeoutSec=connectTimeoutSec)
The ESP32 just seamed to reset and start the code again.

Connecting in PUTTY and Ctrl+C to interrupt the program worked fine.
I tried to change the InterruptProgram method to the following (currently around line 385):

def InterruptProgram(self) :
        if not self._isConnected :
            self._raiseConnectionError()
        try :
            with self._lockWrite :
                # self._repl.write(b'\x03\x03')
                self._repl.write(b'\x04')
                self._repl.flush()
                sleep(1)
                self._repl.write(b'\x03')
                self._repl.flush()
        except :
            self._raiseConnectionError()
        maxTime = (time() + self.KILL_AFTER_INTERRUPT_SEC)
        while self._inProcess :
            sleep(0.030)
            if time() >= maxTime :
                return False
        return True

Instead of just sending the Ctrl+C (\x03) I first send a Ctrl+D (\x04) for soft reset followed by a delayed Ctrl+C.
With these changes, the connection works now without a problem.

My conclusion is that the InterruptProgram method doesn't work correctly in some cases and only resets the ESP32 instead of exiting the running code. This can be due to wrong error handling in the code or other reasons. With the soft reset, we can get a better defined state that exits cleaner (for me).

@rusudanion maybe this works in your case as well.

[jczic]

Hello @tocrar, I would like to understand the problem because you say that a Ctrl+D before the Ctrl+C seems to work but you also say that the 2x Ctrl+C only do a soft reset while however, in the REPL, it is indeed the Ctrl+D that does a soft reset.
What happens if a program is running when you connect? The Ctrl+D normally has no effect to interrupt the program.

So, I have to admit that I have trouble understanding when Ctrl+D really works and why it solves the problem in your configuration.

Have you tried to produce the same combinations by connecting directly to the REPL via a terminal? What happens to you in this case?
Thank you for helping me to understand this phenomenon :)

[rusudanion]

It's a very strange problem for me and it is not easy to found it. Eventually, if you edit the source file esp32Controller.py by replacing the block that causes the error with this one in order to display simple step messages to be noticed in the terminal :

        try :
            print('1')
            self.InterruptProgram()
            print('2')
            self._repl.rts = 0
            self._repl.dtr = 0
            print('3')
            self._switchToRawMode(timeoutSec=connectTimeoutSec)
            print('4')
            machineNfo          = self._exeCodeREPL('import uos; [x.strip() for x in uos.uname().machine.split("with")]')
            print('5')
            self._machineModule = (machineNfo[0] if len(machineNfo) >= 1 else '')
            self._machineMCU    = (machineNfo[1] if len(machineNfo) >= 2 else '')
            print('6')
            self._ensureJamaObjExists()
        except ESP32ControllerSerialConnException :
            raise
        except Exception as ex :
            print(ex)
            raise ESP32ControllerException('The device on the "%s" port is not compatible.' % devicePort)

So, by running app.py with Python from your shell (not from the GUI of course), you can easily see what the last step is before the message and the exact error caused.

Is it possible for you to do this? Thank you very much!

I tried changing the code, and it prints every number from 1-3

[rusudanion]

closed by mistake

[jczic]

Ok @rusudanion and thank you for your feedback.
So in your case, it triggers an error inside the _switchToRawMode() function.

When you connect, do you select the automatic port search or do you select the right port directly (the timeout is not the same).
Presumably, the error would come from the timeout being exceeded because the exit\r\n> string return (see line 465) would not arrive...

The only way to see where it comes from is to display some messages from this function.
Eventually, you could try increasing the value of timeoutSec=0.250 a bit.
(There is a double timeout system to optimize the connection speed to the REPL while allowing for the problems of waiting for a reset etc.).

It would be difficult to tell you more at the moment without reproducing the problem exactly and without testing the whole process directly in a serial terminal.

[rusudanion]

Ok @rusudanion and thank you for your feedback. So in your case, it triggers an error inside the _switchToRawMode() function.

When you connect, do you select the automatic port search or do you select the right port directly (the timeout is not the same). Presumably, the error would come from the timeout being exceeded because the exit\r\n> string return (see line 465) would not arrive...

The only way to see where it comes from is to display some messages from this function. Eventually, you could try increasing the value of timeoutSec=0.250 a bit. (There is a double timeout system to optimize the connection speed to the REPL while allowing for the problems of waiting for a reset etc.).

It would be difficult to tell you more at the moment without reproducing the problem exactly and without testing the whole process directly in a serial terminal.

I was choosing the right port directly. I now changed the value you said with the same results (automatic does 123, times out and gets stuck on 1 while manual does just 123 and timeout).

[jczic]

Then the REPL should not send back the answer I am waiting for... Or simply, nothing is received at all (serial connection problem with the different UART IOs...).
It remains to be seen if it returns something else and why.
The only way in this case is to use a serial terminal to connect directly and try to do the same commands (CTRL+C to interrupt a program and CTRL+A to switch to REPL raw mode...).

[madepolli]

Hi, I think I am having the same problem with my ESP32-s2, so I might as well try to expand on this issue. For a background info, I can connect to the board using "thonny" and it works as expected there.

I can confirm the problem is in the _switchToRawMode, more specifically self._serialReadUntil(b'exit\r\n>', timeoutSec=1.50, lockRead=False) never reads what it expects (yes, I've increased the timeout there).

So I checked what is going on in miniterm:

❯ miniterm /dev/ttyACM0 115200
--- Miniterm on /dev/ttyACM0  115200,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---

So only miniterm output, nothing from the board, not even python prompt - and regular input is not accepted. Pressing ctrl+c does absolutely nothing. But pressing ctrl+a:

raw REPL; CTRL-B to exit
>

The return sees as expected, right? So, I'm lost after this point.