The firmware breaks after the line "Erasing flash (this may take a while)..." esp8266

[kalabaha2022]

Hello everyone. I have a problem with lolin nodemcu v3 board. When you try to erase the flash or write the firmware, the process ends after the line "Erasing flash (this may take a while) ...". I figured there might be a problem with a defective flush. I soldered it and tried to read it, the flash turned out to be working. I tried to remove the dump from the working board and sew it into a flash through the programmer. Nothing helped

esptool.py v4.3
Found 1 serial ports
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: d8:bf:c0:cd:89:bc
Uploading stub...
Running stub...
Stub running...
Erasing flash (this may take a while)...
Traceback (most recent call last):
File "/home/user/.local/bin/esptool.py", line 34, in
esptool._main()
File "/home/user/.local/lib/python3.9/site-packages/esptool/init.py", line 1022, in _main
main()
File "/home/user/.local/lib/python3.9/site-packages/esptool/init.py", line 824, in main
operation_func(esp, args)
File "/home/user/.local/lib/python3.9/site-packages/esptool/cmds.py", line 984, in erase_flash
esp.erase_flash()
File "/home/user/.local/lib/python3.9/site-packages/esptool/loader.py", line 109, in inner
return func(*args, **kwargs)
File "/home/user/.local/lib/python3.9/site-packages/esptool/loader.py", line 1049, in erase_flash
self.check_command(
File "/home/user/.local/lib/python3.9/site-packages/esptool/loader.py", line 407, in check_command
val, data = self.command(op, data, chk, timeout=timeout)
File "/home/user/.local/lib/python3.9/site-packages/esptool/loader.py", line 376, in command
p = self.read()
File "/home/user/.local/lib/python3.9/site-packages/esptool/loader.py", line 308, in read
return next(self._slip_reader)
StopIteration

Also, when the board is connected in the terminal on baud 74600, the line "ets Jan 8 2013,rst cause:2, boot mode:(3,6) appears
"
I tried to flash this board on different devices, the same problems. I also successfully flashed other esp and arduino on my device
I would like to understand the reason, since this is not the first board with such symptoms for me.
P.S.
Sorry for bad English

P.S.
I also connected pin reset and gng to prevent esp from starting. I connected RX->TX, then sent a message through the serial port to check the operation of Ch340. It works well

[robert-hh]

Are you sure that the board is i bootloader mode when you try to load the firmware. The boot message does not show that. For bootloader mode, GPIO0 must be connected to GND and then Reset must be pushed, or power must by cycled.
At reset, you should at 74800 see a message like ets Jan 8 2013,rst cause:2, boot mode:(1,6)

[robert-hh]

The board looks OK. The mdoe switch transistors are populated. Next step for me would be logging, what actually happens on the wire. I do not know if you can do that. At least you can make a loopback test by:

• Connecting RST to GND, and
• Connecting RX with TX at the board.

Then all characters should be echoed. Then you know, that at least the USB/UART bridge works.

[kalabaha2022]

Already did today and supplemented my post at the top. Characters are returned without problems and at any speed

[robert-hh]

ok. did you check if there is a connection between rx, tx and the esp8266 chip pins are good?

[kalabaha2022]

And from here strangeness. There is no direct contact between rx, tx between board and chip. I found a diagram of my board and checked the contacts on it. there is more than 10kOm on the tx contact between the board and the chip, there is no contact on the rx

[kalabaha2022]

After researching, I found the right pins. Between the chip and the esp at rx, tx 200 ohm resistor. And pinout does not comply with ch340G. TX - 10, RX - 14, GNG - 7, 3V - 11

[robert-hh]

I did a capture of RX TX of the chip-id command. The data itself does not tell me a lot, but at least one can see the timing. The first pic shows the full transaction, starting with the reset-response. The second & third pic show a zooms starting with the chip-id command communication. You see a clear alternating communication, which is always in time.

[kalabaha2022]

Alas, I do not have the equipment to check the signals. I'll try to remove the chip or remove the esp12 from the board, and flash it through another usb-uart converter. If this does not help, then the problem is exactly inside the esp8266 microcontroller.

[robert-hh]

I agree that the problem is most likely in the ESP12 module. The ESP8266 starts. Otherwise it would not send that boot message. It still puzzles me, that you do not get the boot mode:(1,6) line, when GPIO0 is at GND and reset is pushed. Because that is the boot loader state. boot mode:(3,6) is the normal boot state.

It may be easier to just get another ESP8266 board. I usually recommend to get a simple logic analyzer tool. There are devices are available at about 10€ with a sample rate of 24MHz, which work with the Saleae logic software or the PulseView software. For serial communication analysis they a worth every cent. Available e.g. at aliexpress or Amazon or others. Like: https://www.aliexpress.com/item/1005003812410259.html?spm=a2g0o.productlist.0.0.20ee7ba1RG5MCU&algo_pvid=f3a6dcf9-88be-4e5e-b6f5-37437a90ab0d&algo_exp_id=f3a6dcf9-88be-4e5e-b6f5-37437a90ab0d-0&pdp_ext_f=%7B%22sku_id%22%3A%2212000027249902447%22%7D&pdp_npi=2%40dis%21EUR%217.26%216.25%21%21%21%21%21%402100bddb16671143546966380e61f6%2112000027249902447%21sea&curPageLogUid=IjO3DzklpdfV

[kalabaha2022]

Thank you for the recommendation for the recommendation, I will take into account this device and purchase it if possible. Also, thank you very much for your attention to my question, and the help you rendered to me.