Closed mmar22 closed 1 year ago
Hi @mmar22, can you please explain your setup more?
In the chain USB -> MCU1 -> RX/TX -> ESP
, is MCU1
a MCU configured to act as a USB-to-serial bridge or is it a devkit where a separate USB-to-serial chip is present? If the latter, is the MCU on the devkit disabled? It could be sending some unexpected data over the TX/RX lines.
MCU configured to act as a USB-to-serial bridge
Please try: 1) Updating to the latest esptool (v4.6.2) 2) Setting longer timeouts with a configuration file
If the USB-to-serial implementation running on the secondary MCU is not fast enough, it might be bottlenecking the comms.
Please i add trace show me where is timeout and i accept trying , now isnt clean. Work same way 19200-921600
You can create an esptool.cfg file in your current directory with this content:
[esptool]
timeout = 10
max_timeout = 240
erase_write_timeout_per_mb = 40
mem_end_rom_timeout = 1
serial_write_timeout = 10
If that doesn't help, you can try increasing the numbers.
Nothing changes and i cant update tool. pip error. Why you dont say me if trace data is ok or is any fail here. Why load to RAM fail ?
If you don't provide more information and refuse to properly try any of my recommendations, there is nothing I can do to help you.
Nothing changes and i cant update tool. pip error.
This tells me nothing. Sharing the error log would be better.
Why you dont say me if trace data is ok or is any fail here.
The data is ok up to the A fatal error occurred: Failed to write to target RAM (result was 01070000: Operation timed out)
error. This is returned by the ESP because your MCU acting as a USB-to-serial bridge is slow.
I write nothing changes , because i test as you write with timeouts config file and too with bigger timeouts. Trace log result no change say as is writed. And sorry in trace is time info then show me operation time with timeout.
I download and test now latest exe version with same result lastver.log My tip, USB-to-serial isnt slow, but quick result to timeout calculated 0 and this result to error in esptools.?
PS: Nazdar Radime, hod to do stroje . Optimalne nekomu kto zna source esptool. :-) A ten trace tiez by mohol ukazovat co je problem... Takto je to na dve veci aj s more info...
@mmar22 Error Failed to write to target RAM (result was 01070000: Operation timed out
vcelku jasně říká, že při zápisu do RAMky (když se nahrává flasher stub) timeoutuje operace. Pokud nepomůže zvýšení timeoutů na straně esptoolu, jedná se tedy o timeout v ROMce, který nelze konfigurovat. V tom případě za to pravděpodobně může nedostatečná implementace USB-to-UART bridge na jiném MCU.
Můžeš zkusit použít esptool bez flasher stubu (esptool.py --no-stub ...
) a vyhnout se tak zápisu do RAMky.
A ten trace tiez by mohol ukazovat co je problem...
Trace ukazuje data putující po seriové lince, nedokáže odhalit všechny problémy, jako např. vadný hardware, crash v ROMce, flashku chráněnou proti zápisu, ...
Ok budeme analyzovat nas MCU ale.
Maly feature request na tento trace: podme od
MAC: 90:38:0c:ac:59:3c Uploading stub... TRACE +0.002 command op=0x05 data len=16 wait_response=1 timeout=3.000 data=680d0000010000000018000000e00b40 TRACE +0.000 Write 26 bytes: c000051000000000 00680d0000010000 | .........h...... 000018000000e00b 40c0 | ........@.
jasne oznacene co sa deje avsak dalsi write vyzera inak
TRACE +0.000 Received full packet: 010504003c59ac0c00000000 TRACE +0.002 command op=0x07 data len=3448 wait_response=1 timeout=3.000 data= 680d000000000000 0000000000000000 | h............... 0800f43f1c00f43f 0000f43f00c0fc3f | ...?...?...?...? ...
potom
0322a0db1df00000 | ."...... TRACE +0.002 Write 3548 bytes: c00007780de70000 00680d0000000000 | ...x.....h......
a na zaver
`TRACE +0.000 Received full packet: 010704003c59ac0c01070000
A fatal error occurred: Failed to write to target RAM (result was 01070000: Operation timed out)`
ziadny checksum zidne info o prenose a problem urcite nieje timeout. Pravdepodobne su poskodene data alebo ina vec.
Command op=0x05
je začátek nahrávání flasher stubu do RAM paměti, command op=0x07
už jsou ta samotná data stubu. To lze vypnout pomocí --no-stub
, tím se tento upload přeskočí. Při přenosu toho velkého bloku dat ale espčko vyhodí timeout error (01070000: Operation timed out
) - tento error nepochází z host počítače ale z ROM bootloaderu v espčku.
Vidím, že při přenosu bloku dat je timeout nastavený na 3s (timeout=3.000
v logu). Pokud je tedy tento přenos pomalejší než 3s, failne. Timeout se dá prodloužit pomocí configuration file. Pomalejší přenos je způsobený právě třeba i nedostatečnou implementací USB-to-UART bridge na druhém MCU.
problem urcite nieje timeout. Pravdepodobne su poskodene data alebo ina vec.
Error Operation timed out
tvrdí opak.
Tohle není problém esptoolu. Je to program na sériovou komunikaci. Plně tedy závisí na funkčním seriovém spojení. Zavírám tedy tohle issue.
Hi! I faced with similar problem on stub uploading (01070000: Operation timed out
). My problem was in MCU, part of bytes was dropped due to "high" speed serial connection. Incoming data buffer in MCU solved this problem.
Operating System
W10 64
Esptool Version
v4.4
Python Version
3.8.7
Chip Description
ESP32
Device Description
custom with Wrover module
Hardware Configuration
USB -> MCU1 -> RX/TX -> ESP
How is Esptool Run
powershell
Full Esptool Command Line that Was Run
esptool.py -p com5 -b 921600 --after no_reset --trace read_mac
Esptool Output
More Information
same result on other speeds trace seems be good is timeouts setup in esptool OK?
Other Steps to Reproduce
No response
I Have Read the Troubleshooting Guide