Does "Flash Download Tool" support firmware loading via half-duplex UART communication ?

[LuvKira]

I have a development project which uses ESP32-C3. Now, I want to flash firmware for it. I found Flash Download Tool loads firmware via a USB cable. It seems to use full-duplex UART communication. I want my project to load firmware via half-duplex UART communication without a USB cable. Does the tool support half-duplex firmware loading? On the other side, I saw Flash Download Tool compress data before flashing them to ESP32-C3. I want to know the detailed steps the tool does.

[ESP_Sprite]

Full-duplex is probably in use because it's the default that most people have. The protocol itself is request-response, so I don't think there's anything stopping it from working on a half-duplex connection. The serial protocol is defined here but be mindful that esptool.py uploads a custom stub to get some more functionality and the protocol between it and the stub isn't 100% the thing that's described here. Dependent on what you want to do, esp-serial-flasher might also be an useful resource.

[LuvKira]

Full-duplex is probably in use because it's the default that most people have. The protocol itself is request-response, so I don't think there's anything stopping it from working on a half-duplex connection. The serial protocol is defined here but be mindful that esptool.py uploads a custom stub to get some more functionality and the protocol between it and the stub isn't 100% the thing that's described here. Dependent on what you want to do, esp-serial-flasher might also be an useful resource.

Thanks for your feedback. I will try to find a solution according to your guide.

[g3gg0.de]

Hello,

I am currently evaluating, if it is possible to pass the UART stream through a CAN PHY.
There is no result yet, but some concerns and I need to dig deeper.

There are two main concerns i have:

1. the "TxD permanent dominant" protection of the CAN PHY, which will kick in after ~1ms tx-low, releases Tx.
this however might be fixable by inversing the rx/tx signals in hardware.

2. the bigger concern is that RxD will also "see" the data the ESP32 has sent in that half duplex setup.
according to the SLIP protocol definition (https://docs.espressif.com/projects/esp ... tocol.html),
this could be detected and ignored, but when i tried to manually send reponse packets (0x01) instead of request (0x00), the ESP32
also seems to answer them.
this would cause a permanent loop i guess, answering the answer it just sent.

in short: the ESP32 ROM seems to answer the packets it has sent when using half duplex links although it is not neccessary.

@espressif:
- is this intentional or might that be fixed in some later ROM revisions to allow programming-via-can-phy?
- are there other measurements you implemented to prevent this, like disabling the rx path while sending?

[LuvKira]

Hello,

I am currently evaluating, if it is possible to pass the UART stream through a CAN PHY.
There is no result yet, but some concerns and I need to dig deeper.

There are two main concerns i have:

1. the "TxD permanent dominant" protection of the CAN PHY, which will kick in after ~1ms tx-low, releases Tx.
this however might be fixable by inversing the rx/tx signals in hardware.

2. the bigger concern is that RxD will also "see" the data the ESP32 has sent in that half duplex setup.
according to the SLIP protocol definition (https://docs.espressif.com/projects/esp ... tocol.html),
this could be detected and ignored, but when i tried to manually send reponse packets (0x01) instead of request (0x00), the ESP32
also seems to answer them.
this would cause a permanent loop i guess, answering the answer it just sent.

in short: the ESP32 ROM seems to answer the packets it has sent when using half duplex links although it is not neccessary.

@espressif:
- is this intentional or might that be fixed in some later ROM revisions to allow programming-via-can-phy?
- are there other measurements you implemented to prevent this, like disabling the rx path while sending?

I'm so sorry for responding to you so late. I didn't use to try passing the UART stream through a CAN PHY, but i hope my solution can help you. In my case, i used an PC connected to an ESP32-C3 through an UART half-duplex wire to flash firmware for it. As you said, RxD can "see" what esp32 sent via TxD, so i built a "filter" to discard those echo signals. That filter will become active after one command was sent to esp32 complete. The filter will only agree to receive the valid responses and ignore others. A valid response will have 0x01 value in the "direction" field and its "cmd" field is corresponding to this same field of the previously sent command. I think sending 0x01 in the "direction" field will cause the device to reject the request and return an error code. To test, you can edit esptool.py to output exactly what ESP32 responds with.