Nextion Editor uses a hard coded timeouts

I use Nextion Intelligent Series NX8048P070 display with STM32 MCU and it work great. Uploading to display with Nextion Editor (V1.65.1) and USB-UART CH340G dongle also works great. The problem occur when I want to upload firmware with Nextion Editor with STM32 USB virtual COM (it is used in device I’m designing currently):
22

STM Serial COM13 works like usual Arduino (Serial.) COM port.

Nextion display is connected to STM32F401 USART1 pins PB9 PB10. It respond to the commands, so the wiring is OK and Baud is OK. The code for “transparent mode” of Arduino STM32 is:

HardwareSerial SerDisplay(USART1);

void setup() { 
  SerDisplay.begin(250000);
  SerDisplay.setTimeout(1);
  Serial.begin(250000);
  Serial.setTimeout(1);
}

void loop() {
   if(Serial.available()){
      SerDisplay.write(Serial.read());
      SerDisplay.flush();}

   if(SerDisplay.available()){
      Serial.write(SerDisplay.read());
      Serial.flush();}
}

When I use Nextion Editor to upload project I get no response at any Baud, no changes on display (I used COM port sniffer to investigate what data runs in COM13):

It seems like Nextion Editor closes connection on hard-coded timeout :exploding_head: so he cant see 0x05 if it comes with a bit delay.

BUT! When I use any terminal to connect COM13 and try to manual insert commands from NEXTION UPLOAD PROTOCOL (v1.1) to terminal - display is responding:

->FF FF FF connect FF FF FF
<-comok 3,1793-0,NX8048P070_011C,163,10501,B23A34012971E843,131072000-0 FF FF FF
->whmi-wri 4096,9600,res0 FF FF FF
<-05

26

I get 0x05 and display become filled with white color as it should when waiting for upload process start.
Tried to put same command as Nextion Editor (DRAKJHSUYDGBNCJHGJKSHBDN+connecnt) to terminal and display respond:
28

So the question is why there are no responses from display when Nextion Editor try to find it? But in same time when I copy same “searching” bytes to any terminal connected to same COM13 port display respond like expected?

My guess is that there is some bug in Nextion Editor SW like hard coded timeouts when parsing answers from COM port. Also sometimes Nextion Editor hangs deadly when searching baud and it could be closed only with task manager.
29

Of course I created a post in Forums Archive - Nextion to connect with Developers, but unfortunately the post is invisible (maybe it didn’t pass moderation or something) Anyway that Nextion Editor sucks in data transferring…

UPD.
Since I can’t be the only one with this kind of problem and the need to flash the firmware through the USB port of STM32 controller my searches led me to the current forum. Here I found a Python script for flashing *.tft files directly to the COM port without Nextion Editor and c# one.
However, Python script didn’t work in my case because it also uses a delay for 0x05 calculated based on the current port speed. I had to modify the script to somehow get it to flash the display correctly.
I’m not very familiar with python, but I guess I should write a console C++ program that works with a COM port using threads and mutexes, so receiving and transmitting data can be independent or / and with configurable conditions like awaiting for 0x05 response with parametrized timeout:

The Nextion device will send a 0x05 byte within 500ms after receiving the whmi-wri instruction notifying that it is ready to begin receiving the .tft file contents. Users must wait until this 0x05 byte is received before sending or risk that the data sent before Nextion was ready will be deemed lost (and therefore a corrupted and unusable upload). Users must split the .tft file contents into 4096 byte sized packets with the final partial packet size equal to the last remaining bytes (<4096 bytes).

Users then sends out each packet, and in turn wait for the Nextion to return its 0x05 byte confirming reception and readiness to receive the next pack. Once the final partial packet has been sent and the confirmation 0x05 has been received, the upload portion is complete.