I want to load program with system bootloader over TCP/UDP

[Ahmet Yasin CİVAN]

I ran system bootloader, I can perform the bootloader process using the STM32CubeProgrammer software via USART. But what I want is to run the bootloader software over TCP or UDP using the USART protocol. Because my UART2 line is connected to a TCP converter.

I wrote a piece of code using Python, but it's very slow and disconnects after a while. Is it possible to enable STM32CubeProgrammer to communicate with UART protocol over TCP?

Softwareally, I used TCP to Uart converters, but STM32CubeRogrammer is getting a time delay error.

My system is as follows;

[TDK]

The system bootloader doesn't support TCP/UDP, nor does STM32CubeProgrammer. You'll need to own the conversion side, or create your own bootloader.

In theory, with a converter, it should be working. I would invest in a logic analyzer to see what part of the system is misbehaving. The bootloader should be solid, probably the converter isn't quite doing what is advertised.

There are also possibilities with a remote debugger able to be connected to the chip (via SWD) and reprogram it that way.

[Ahmet Yasin CİVAN]

I know the system bootloader does not support TCP.

I wrote a socket program in python, commands such as Get ID, Extended Erase, Get are working with the commands I send from this software. There is no error on my system and my dialers as the commands work fine.

I connect the STM32CubeProgrammer software to a virtual port on the computer, this virtual port is connected to another virtual port which turns into TCP. I expect this to work. But I am getting errors on STM32CubeProgrammer.

[Tesla DeLorean]

The serial protocol is documented, you could dispense with STM32 Cube Programmer, and implement the UART protocol more directly with your own Berkeley Sockets, or equivalent, implementation to talk more directly with your TCP-to-UART device.

You could also use a more common or robust serial based protocol in a loader of your own construction.

ST has previously published Ethernet IAP implementations

[Ahmet Yasin CİVAN]

Yes, I wrote a socket program in python, commands such as Get ID, Extended Erase, Get are working with the commands I send from this software. When I send the Write Memory command, I have to send it byte by byte, which is very long. If I send the data I want to write as a data packet, the system bootloader cannot detect it.

My socket program sends the commands in AN3155 document over TCP. Coming with TCP, the STM32H7 is converting to UART. There is no error on my system and my dialers as the commands work fine.

[Tesla DeLorean]

The methods should permit blocks of bytes, although will have size and alignment expectations.

Cannot detect it, or rejects it?

It expects EVEN PARITY (8E1)

Should perhaps scope it, and understand the failure.

Theoretically you should be able to push code into RAM, allowing for a "staged loader" methodology, that way if the current protocol isn't ideal, you can upload something that does the task better.

[Ahmet Yasin CİVAN]

All I need is to use STM32CubeProgrammer software with UART interface over TCP for system bootloader. Would you help me with this topic?

[Pavel A.]

>  If I send the data I want to write as a data packet, the system bootloader cannot detect it.

What if you send by shorter packets?

[Ahmet Yasin CİVAN]

Thank you for response,

After the Write Memory (AN3155) command, I start to write the data to the memory address. If this data is 1 byte over TCP, it writes properly. If it is more than 2 bytes in 1 TCP frame, nothing happens. This way python script is running very slow. Because I can send byte by byte.

[Tesla DeLorean]

I've been able to walk devices in via realterm​, so it should be pretty tolerant of some latency.

[Ahmet Yasin CİVAN]

Yes, but STM32CubeProgrammer is not tolerant, how can I increase the tolerance?

[Houda GHABRI]

Hi Ahmet Yasin CİVAN,

I propose to test this, hope it resolves the issue :

• There is an option to increase the timeout using CLI :tm , we can set vlaue in ms .

STM32_Programmer_CLI.exe -c port=COM36 -tm 100000

   -------------------------------------------------------------------

            STM32CubeProgrammer v2.10.0-RC2

   -------------------------------------------------------------------

Warning: Timeout is forced to 100000 ms

STM32_Programmer_CLI.exe -c port=COM36 -tm 100000

Serial Port COM36 is successfully opened.

• Did you already try to decrease the Bauderate value?

Can you please test it and tell me if it is OK ?

Houda

[Ahmet Yasin CİVAN]

Hi @Houda GHABRI​ 

I'm sorry for the late reply,

Timeout error persistsi, this method is not ok

I'm working over TCP;

I do decrease the Bauderate value over, there is a timeout error (Over TCP) 

İf direct connect to system bootloader (STM32H7 UART-2)

[Houda GHABRI]

Hi Ahmet Yasin CİVAN,

STM32CubeProgrammer is designed to operate in an environment where the host and device are close and ideally directly connected. Clearly not expected to work with such latency.

So CubeProgrammer cannot help in this case, what I can suggest is to try to use STM32 Flash loader demonstrator tool available here ,may be it is more tolerant about latency.

Hope this can helps you,

Houda

[Ahmet Yasin CİVAN]

STM32 Flash loader is not good for my request, I need STM32CubeProgrammer.

[Ahmet Yasin CİVAN]

Hi @Houda GHABRI​ ,

Can't you fix this problem by releasing an update for STM32CubeProgrammer? This is a very basic request.There may be many people in need and we are a loyal ST user. Please fix the problem with an update, I will be very grateful. ST is a very crowded and successful company.

[Houda GHABRI]

Hi @Ahmet Yasin CİVAN​ ,

I don't think it can be considered a problem in CubeProgrammer side :smiling_face_with_smiling_eyes: .The standard use case (where latency is "normal" ) is working fine.

However I will raise your request internally to enhance the tool to support such use case with high data transfer latency between host and device.

CubeProgrammer team will debug further and   see how they can address this modification.

I will keep you posted for any updates.

Houda

[Ahmet Yasin CİVAN]

Hi @Houda GHABRI​ ​

Yes, you are right it works very well. It does all the work it's supposed to do. :smiling_face_with_smiling_eyes:

I knew you would help, I will wait to hear from you. Thank you so much.

[Pavel A.]

@Ahmet Yasin CİVAN​ While you're waiting for ST response, can you post a picture of the connection between your eth to serial box and the board?

Have you tried to monitor the serial traffic at the board serial pins (TTL or after TTL to RS232 converter) with a scope or logic?

It's a long shot but looks like floating control pins (DTR,RTS...)