Sysprogs forums › Forums › VisualGDB › ESP8266 – Error on uploading Arduino sketch: upload.py Invalid parameters used
- This topic has 22 replies, 2 voices, and was last updated 4 years, 7 months ago by support.
-
AuthorPosts
-
September 23, 2019 at 22:31 #25874cvalentinParticipant
Hi,
I get an error message when I want to program the flash of an ESP8266 (Arduino sketch). The following error message is shown:
C:\Users\chris\Documents\ArduinoData\packages\esp8266\tools\python\3.7.2-post1\python “C:\Users\chris\Documents\ArduinoData\packages\esp8266\hardware\esp8266\2.5.2/tools/upload.py” –chip esp8266 –port “COM4” –baud “921600” “” version –end –chip esp8266 –port “COM4” –baud “921600” “” write_flash 0x0 “D:\Work\ESP8266\SmartLightSwitch\Output\LOLIN_WEMOS__D1_R2___mini\Debug/SmartLightSwitch.ino.bin” –end
usage: esptool [-h] [–chip {auto,esp8266,esp32}] [–port PORT] [–baud BAUD]
[–before {default_reset,no_reset,no_reset_no_sync}]
[–after {hard_reset,soft_reset,no_reset}] [–no-stub]
[–trace] [–override-vddsdio [{1.8V,1.9V,OFF}]]
{load_ram,dump_mem,read_mem,write_mem,write_flash,run,image_info,make_image,elf2image,read_mac,chip_id,flash_id,read_flash_status,write_flash_status,read_flash,verify_flash,erase_flash,erase_region,version}
…
esptool: error: argument operation: invalid choice: ” (choose from ‘load_ram’, ‘dump_mem’, ‘read_mem’, ‘write_mem’, ‘write_flash’, ‘run’, ‘image_info’, ‘make_image’, ‘elf2image’, ‘read_mac’, ‘chip_id’, ‘flash_id’, ‘read_flash_status’, ‘write_flash_status’, ‘read_flash’, ‘verify_flash’, ‘erase_flash’, ‘erase_region’, ‘version’)Does this mean VisualGDB uses wrong command line arguments? How can I fix this?
Kind Regards,
Christian- This topic was modified 4 years, 7 months ago by cvalentin.
September 25, 2019 at 13:33 #25900cvalentinParticipantIs it possible to change the command line which VisualGDB uses to upload the sketch by myself or do you have to fix that on your side?
Kind Regards,
ChristianSeptember 25, 2019 at 15:55 #25905supportKeymasterHi,
Normally, VisualGDB would launch the Arduino builder that dumps various variables, letting VisualGDB reconstruct the command line. Unfortunately, it is not possible to change it explicitly, however in most of the cases, it should be derived correctly.
Please try checking via Tools->VisualGDB->Manage VisualGDB Packages whether you have multiple versions of the Arduino package installed. If this is the case, please try removing the old package versions. If it still doesn’t help, please let us know and we will investigate this further.
September 25, 2019 at 21:41 #25907cvalentinParticipantI don’t have the Arduino IDE installed. I only use the VisualGDB Arduino packages. I have the following installed:
ESP32 Arduino package: Version 1.0.3
ESP8266 Arduino package: Version 2.5.2The problem also exist if I uninstall the ESP32 package.
What can I check next?
Kind Regards,
ChristianSeptember 25, 2019 at 21:43 #25908supportKeymasterPlease share the exact steps to reproduce the problem from the very beginning (i.e. what exactly to specify on each page of the wizard while creating the project, what exact command to use in order to trigger the problem).
September 25, 2019 at 22:44 #25910cvalentinParticipantHi,
I do the following steps:
Step1:
Step2:
Step3:
Step4:
Step5:
Step6:
To program the flash, I use the following ContextMenu entry:
Please can you check if you have the same issues with a WEMOS D1 mini board? What should I check next?
Kind Regards,
ChristianSeptember 26, 2019 at 00:29 #25911supportKeymasterThanks for the detailed repro steps. It turns out, a recent change to the Arduino ESP8266 package indeed broke FLASH programming for some targets.
We have added a workaround for this to the following build: VisualGDB-5.5.1.3273.msi
September 26, 2019 at 06:18 #25915cvalentinParticipantThanks very much for the really fast fix! I will try it today evening when I am at home back from work.
Kind Regards,
Christian
September 26, 2019 at 16:09 #25920cvalentinParticipantUploading the sketch does work now, but I cannot debug the code. I use the default blinking example which includes the gdbstub and calls gdbstub_init() in the setup method.
After uploading the firmware VisualGDB tries to connect to the gdbstub but it does not work. After a timeout I get the following error message:
Failed to connect to the gdb stub. Please check your settings.This is the detailed output of the error:
-gdb-version
=thread-group-added,id=”i1″
~”GNU gdb (GDB) 8.2.50.20180723-git\n”
~”Copyright (C) 2018 Free Software Foundation, Inc.\n”
~”License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law.”
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
~”\nType \”show copying\” and \”show warranty\” for details.\n”
~”This GDB was configured as \”–host=i686-w64-mingw32 –target=xtensa-lx106-elf\”.\n”
~”Type \”show configuration\” for configuration details.\n”
~”For bug reporting instructions, please see:\n”
~”<http://www.gnu.org/software/gdb/bugs/>.\n”
~”Find the GDB manual and other documentation resources online at:\n <http://www.gnu.org/software/gdb/documentation/>.”
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
~”\n\n”
~”For help, type \”help\”.\n”
~”Type \”apropos word\” to search for commands related to \”word\”…\n”
~”Reading symbols from D:/Work/ESP8266/ArduinoProject1/Output/LOLIN_WEMOS__D1_R2___mini/Debug/ArduinoProject1.ino.elf…”
~”done.\n”
~”GNU gdb (GDB) 8.2.50.20180723-git\n”
~”Copyright (C) 2018 Free Software Foundation, Inc.\n”
~”License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law.”
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
~”\nType \”show copying\” and \”show warranty\” for details.\n”
~”This GDB was configured as \”–host=i686-w64-mingw32 –target=xtensa-lx106-elf\”.\n”
~”Type \”show configuration\” for configuration details.\n”
~”For bug reporting instructions, please see:\n”
~”<http://www.gnu.org/software/gdb/bugs/>.\n”
~”Find the GDB manual and other documentation resources online at:\n <http://www.gnu.org/software/gdb/documentation/>.”
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
~”\n\n”
~”For help, type \”help\”.\n”
~”Type \”apropos word\” to search for commands related to \”word\”.\n”
^done
-list-features
^done,features=[“frozen-varobjs”,”pending-breakpoints”,”thread-info”,”data-read-memory-bytes”,”breakpoint-notifications”,”ada-task-info”,”language-option”,”info-gdb-mi-command”,”undefined-command-error-code”,”exec-run-start-option”]
-gdb-set disassembly-flavor intel
^error,msg=”No symbol \”disassembly\” in current context.”
-gdb-set print demangle off
^done
set serial baud 74880
&”set serial baud 74880\n”
=cmd-param-changed,param=”serial baud”,value=”74880″
^done
target remote \\.\COM4
&”target remote \\\\.\\COM4\n”
~”Remote debugging using \\\\.\\COM4\n”
~”Ignoring packet error, continuing…\n”
&”warning: unrecognized item \”timeout\” in \”qSupported\” response\n”
~”Ignoring packet error, continuing…\n”
&”Remote replied unexpectedly to ‘vMustReplyEmpty’: timeout\n”
^error,msg=”Remote replied unexpectedly to ‘vMustReplyEmpty’: timeout”
-target-disconnect
^error,msg=”You can’t do that when your target is `exec'”
-gdb-exit
^exitThere still seems to be a problem. Please can you advice?
Kind Regards,
ChristianSeptember 26, 2019 at 16:14 #25921supportKeymasterMost likely, the gdb stub baud rate is configured incorrectly.
Please try opening the COM port with SmarTTY and resetting the board. The gdb stub should output the following text (indicating that it’s ready for gdb to attach):
$T05#b9
If you see anything different, please try using different baud rates to see if any of them works. Please also ensure you have followed all other steps from our ESP8266 Arduino tutorial.
September 26, 2019 at 16:52 #25923cvalentinParticipantIf I reset the board, I see the following (Baud rate set to 74880):
ets Jan 8 2013,rst cause:2, boot mode:(3,7)
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v8b899c12
~ldSo it looks like the baud rate is OK, but no GDBStub output?
September 26, 2019 at 16:56 #25924supportKeymasterIf the $T05#b9 message is not shown despite trying different baud rates, the board you are using may not be supported by the gdb stub. Please contact Espressif for further details.
September 26, 2019 at 16:58 #25925cvalentinParticipantIt is a Wemos D1 mini board. Interestingly, it works flawlessly with VisualMicro and I can debug, but I bought a VisualGDB license, so it would be good, if this gets sorted out.
Thanks,
ChristianSeptember 26, 2019 at 17:06 #25926supportKeymasterVisualMicro might be using a different debug mechanism that patches the code at compile-time to handle breakpoints and variable output, that is less flexible than the fully fledged gdb-based debugging, but would not rely on the Espressif’s GDB stub.
Please check what debug method the other tool is using (e.g. gdb stub, JTAG or the compile-time breakpoints) and ensure you are using the same settings with VisualGDB.
Also please do actually try different baud rates (especially 57600, 74880, 115200). The $T05#b9 message might be displayed under a different baud rate than the welcome banner and hence would not be properly visible.
September 26, 2019 at 17:21 #25927cvalentinParticipantThe other tool also uses the GDB stub. I can step through the code. The other debug method you mentioned does not support stepping through code.
It looks like that the GDB stub is not waiting for VisualGDB to connect. Shouldn’t the call to gdbstub_init() within the setup() method wait until VisualGDB has connected?It looks like this does not happen. The LED immediately starts blinking after uploading the code so the loop() method is entered without waiting for a GDB connection.
Do you have any idea what I can check next?
Regards,
Christian -
AuthorPosts
- You must be logged in to reply to this topic.