Sysprogs forums › Forums › VisualGDB › No such thing as "Program and Start Without Debugging" with ESP8266
- This topic has 5 replies, 2 voices, and was last updated 8 years, 7 months ago by support.
-
AuthorPosts
-
January 7, 2016 at 18:20 #7440bojanpotocnikParticipant
Hello!
I switched from custom Eclipse environment to Visual GDB ESP8266 programming and stumbled on very frustrating thing. I do not want to debug ESP8266, I just want to write code and program it (as fast as possible or at least with as few steps as possible).
I cannot find method to program ESP8266 without debugging. When I press option “Program and Start Without Debugging” I am – always – presented with dialog:
where I press No every time, despite the fact I did not tick “Enable UART GDB Stub” while creating project,
then I manually reset ESP8266 with my Python serial-port-splitter script, despite the fact that esptool.py (can) do that automatically (tested and used in my previous environment, that is the reason for serial port split – to be able to program with esptool.py and watching debug output at the same time without any changes in the serial terminal or esptool.py)
so FW is successfully programmed:
but then the most annoying thing happen – VisualGDB tries to connect to UART GDB Stub:
and it even ignores Cancel button!
This windows blocks whole Visual Studio and it takes forever (1-2 minutes?) to finally timeout.
I gave up and tried to program it manually with batch script, but converting the image works OK:
C:\SysGCC\esp8266\python27\python.exe "C:\SysGCC\esp8266\esp8266-bsp\esptool.py" elf2image "G:\ESP8266\Test\Test/Release/Test.elf" --flash_freq 40m --flash_mode qio --flash_size 16m-c1
which completes successfully, but programming:
C:\SysGCC\esp8266\python27\python.exe "C:\SysGCC\esp8266\esp8266-bsp\esptool.py" --port COM11 --baud 74880 write_flash 0x01000 "G:\ESP8266\Test\Test/Release/Test.bin"
for some reason throws error:
Connecting...
reply
reply
reply
reply
reply
reply
reply
reply
Erasing flash...
Traceback (most recent call last):
File "C:\SysGCC\esp8266\esp8266-bsp\esptool.py", line 563, in <module>
esp.flash_begin(blocks*esp.ESP_FLASH_BLOCK, address)
File "C:\SysGCC\esp8266\esp8266-bsp\esptool.py", line 199, in flash_begin
struct.pack('<IIII', size, num_blocks, ESPROM.ESP_FLASH_BLOCK, offset))[1] != "":
File "C:\SysGCC\esp8266\esp8266-bsp\esptool.py", line 112, in command
raise Exception('Invalid head of packet')
Exception: Invalid head of packet
Thank you for your help
January 9, 2016 at 12:08 #7452bojanpotocnikParticipantI solved the problem when I discovered that VisualGDB doesn’t support (at least I didn’t find it) firmware building for OTA Upgrades (that means single .bin instead of .flash.bin + .irom0text.bin combination).
Firstly, I edited the main project Makefile and added two sections. First,
###### Generate user.bin file for OTA Update enabled applications OBJDUMP := $(TOOLCHAIN_ROOT)/bin/xtensa-lx106-elf-objdump.exe NM := $(TOOLCHAIN_ROOT)/bin/xtensa-lx106-elf-nm.exe UPGRADEEDIR := $(BINARYDIR)/upgrade # boot_mode: # 0 = none # 1 = old (v1.2) # 2 = new (v1.4+) BOOT_MODE := 2 # flash_mode: # 0 = QIO (Default) # 1 = QOUT # 2 = DIO # 3 = DOUT FLASH_MODE := 0 # flash_clk_div: # 0 = 80 MHz / 2 = 40 MHz (Default) # 1 = 80 MHz / 3 = 26.1 MHz # 2 = 80 MHz / 4 = 20 MHz # 15 = 80 MHz / 1 = 80 MHz FLASH_CLK_DIV := 0 # flash_size_map: # 0 = 512 KB (256 KB + 256 KB) # 1 = 256 KB # 2 = 1024 KB (512 KB + 512 KB) # 3 = 2048 KB (512 KB + 512 KB) # 4 = 4096 KB (512 KB + 512 KB) # 5 = 2048 KB (1024 KB + 1024 KB) # 6 = 4096 KB (1024 KB + 1024 KB) FLASH_SIZE_MAP := 5 # Add to the end of output files PRIMARY_OUTPUTS += $(UPGRADEEDIR)/$(basename $(TARGETNAME)).bin #################################################################
was added before
all: $(PRIMARY_OUTPUTS)
statement (rule). Second,###### Generate user.bin file for OTA Update enabled applications $(UPGRADEEDIR): mkdir "$(UPGRADEEDIR)" # gen_appbin.py app.elf/app.out boot_mode flash_mode flash_clk_div flash_size_map # gen_appbinVGDB.py app.elf boot_mode flash_mode flash_clk_div flash_size_map app.sym app.text.bin app.data.bin app.rodata.bin app.irom0text.bin output $(UPGRADEEDIR)/$(basename $(TARGETNAME)).bin: $(BINARYDIR)/$(TARGETNAME) |$(UPGRADEEDIR) @$(NM) -g $< > $(basename $@).sym @$(OBJCOPY) --only-section .text -O binary $< $(basename $@).text.bin @$(OBJCOPY) --only-section .data -O binary $< $(basename $@).data.bin @$(OBJCOPY) --only-section .rodata -O binary $< $(basename $@).rodata.bin @$(OBJCOPY) --only-section .irom0.text -O binary $< $(basename $@).irom0text.bin @$(TOOLCHAIN_ROOT)/Python27/python.exe $(BSP_ROOT)/RTOS-SDK/tools/gen_appbinVGDB.py \ $< $(BOOT_MODE) $(FLASH_MODE) $(FLASH_CLK_DIV) $(FLASH_SIZE_MAP) \ $(basename $@).sym $(basename $@).text.bin $(basename $@).data.bin $(basename $@).rodata.bin $(basename $@).irom0text.bin $@ @echo Generated upgrade file $@ with boot=$(BOOT_MODE), flash_mode=$(FLASH_MODE), flash_clk=$(FLASH_CLK_DIV), flash_size_map=$(FLASH_SIZE_MAP) #################################################################
was added after
clean:
rule. Then I copiedC:\SysGCC\esp8266\esp8266-bsp\RTOS-SDK\tools\gen_appbin.py
file toC:\SysGCC\esp8266\esp8266-bsp\RTOS-SDK\tools\gen_appbinVGDB.py
and made this changes:** Next line is line 117 in original gen_appbin.py # if len(sys.argv) != 6: if len(sys.argv) != 12: # print 'Usage: gen_appbin.py eagle.app.out boot_mode flash_mode flash_clk_div flash_size_map' print 'Usage: gen_appbinVGDB.py app.elf boot_mode flash_mode flash_clk_div flash_size_map app.sym app.text.bin app.data.bin app.rodata.bin app.irom0text.bin output' sys.exit(0)
** Next line is line 132 in original gen_appbin.py # irom0text_bin_name = 'eagle.app.v6.irom0text.bin' # text_bin_name = 'eagle.app.v6.text.bin' # data_bin_name = 'eagle.app.v6.data.bin' # rodata_bin_name = 'eagle.app.v6.rodata.bin' # flash_bin_name ='eagle.app.flash.bin' irom0text_bin_name = sys.argv[10] text_bin_name = sys.argv[7] data_bin_name = sys.argv[8] rodata_bin_name = sys.argv[9] flash_bin_name = sys.argv[11] app_sym_name = sys.argv[6]
** Next line is line 132 in original gen_appbin.py # irom0text_bin_name = 'eagle.app.v6.irom0text.bin' # text_bin_name = 'eagle.app.v6.text.bin' # data_bin_name = 'eagle.app.v6.data.bin' # rodata_bin_name = 'eagle.app.v6.rodata.bin' # flash_bin_name ='eagle.app.flash.bin' irom0text_bin_name = sys.argv[10] text_bin_name = sys.argv[7] data_bin_name = sys.argv[8] rodata_bin_name = sys.argv[9] flash_bin_name = sys.argv[11] app_sym_name = sys.argv[6]
** Next line is line 149 in original gen_appbin.py # if os.getenv('COMPILE')=='xcc' : # cmd = 'xt-nm -g ' + elf_file + ' > eagle.app.sym' # else : # cmd = 'xtensa-lx106-elf-nm -g ' + elf_file + ' > eagle.app.sym' # # os.system(cmd) # fp = file('./eagle.app.sym') fp = file(app_sym_name)
** Next line is line 277 in original gen_appbin.py # cmd = 'rm eagle.app.sym' # os.system(cmd) os.remove(irom0text_bin_name) os.remove(text_bin_name) os.remove(data_bin_name) os.remove(rodata_bin_name) os.remove(app_sym_name)
And after this modifications there is always also
Test.bin
file inRelease\upgrade\
folder which I can program with a press of a button via epstool.py script:G:\ESP8266\Test\Test\Release\upgrade\>esptool.py -p COM11 -b 921600 write_flash 0x01000 Test.bin Connecting... Erasing flash... Wrote 267264 bytes at 0x00001000 in 16.8 seconds (127.3 kbit/s)... Leaving...
So programming now works. Next thing I must to repair is sections – I see you use some custom sections in your example project? ESP bootloader reports errors and cannot start the example application properly. I think I will just use Espressif template project in examples
RTOS-SDK\project_template\
folder.January 9, 2016 at 18:16 #7453bojanpotocnikParticipantBug fix – function
write_file
opens file in append mode, therefore a bit of additional code is needed in following block.Original:
** Next line is line 132 in original gen_appbin.py # irom0text_bin_name = 'eagle.app.v6.irom0text.bin' # text_bin_name = 'eagle.app.v6.text.bin' # data_bin_name = 'eagle.app.v6.data.bin' # rodata_bin_name = 'eagle.app.v6.rodata.bin' # flash_bin_name ='eagle.app.flash.bin' irom0text_bin_name = sys.argv[10] text_bin_name = sys.argv[7] data_bin_name = sys.argv[8] rodata_bin_name = sys.argv[9] flash_bin_name = sys.argv[11] app_sym_name = sys.argv[6]
Fixed:
** Next line is line 132 in original gen_appbin.py # irom0text_bin_name = 'eagle.app.v6.irom0text.bin' # text_bin_name = 'eagle.app.v6.text.bin' # data_bin_name = 'eagle.app.v6.data.bin' # rodata_bin_name = 'eagle.app.v6.rodata.bin' # flash_bin_name ='eagle.app.flash.bin' irom0text_bin_name = sys.argv[10] text_bin_name = sys.argv[7] data_bin_name = sys.argv[8] rodata_bin_name = sys.argv[9] flash_bin_name = sys.argv[11] app_sym_name = sys.argv[6] try: os.remove(flash_bin_name) except: pass
January 9, 2016 at 22:07 #7454bojanpotocnikParticipantSo programming now works. Next thing I must to repair is sections – I see you use some custom sections in your example project? ESP bootloader reports errors and cannot start the example application properly.
I forgot to flash boot_v1.4(b1).bin to 0x00000. Now it works! 🙂
I also “fixed” debugging – right click on project -> Properties and changed values which are now bold:
Content of programUpgradeBin.bat file located in project folder:
C:\SysGCC\esp8266\python27\python.exe "C:\SysGCC\esp8266\esp8266-bsp\esptool.py" -p COM11 -b 921600 write_flash 0x01000 "%1" exit /b 0
And now pressing F5 simply start up CMD window showing flashing progress. And the most beautiful thing (for me) – Visual Studio is not blocked while programming (CMD is running in background)! The only thing which happens in Visual Studio windows after pressing F5 is simple text:
The program '[5476] programUpgradeBin.bat' has exited with code 0 (0x0).
in Output window when programming completes.
Sorry for bothering you. Maybe this will be helpful to someone in future or maybe even to you if you decide to implement such program-only feature. I switched to Visual Studio because there is by far no such programming IDE as Visual Studio 2015 + Visual Assist X + JetBrains ReSharper.
- This reply was modified 8 years, 10 months ago by bojanpotocnik.
January 12, 2016 at 02:45 #7458supportKeymasterWow, thanks for the detailed description!
We indeed don’t support OTA out-of-the-box, to the instructions you provided should be very useful for the other users looking for it.
We will also consider supporting it directly in one of the next versions.
We’ve also fixed the ‘cancel’ button behavior during the connection attempt in the upcoming VisualGDB 5.1 Preview 2.
April 24, 2016 at 00:29 #8066supportKeymasterOK, VisualGDB now fully supports the OTA mechanism. It will automatically generate the OTA binaries, program them, configure the bootloader and can even serve the binaries over HTTP to the ESP8266 device. Read this tutorial for more details: http://visualgdb.com/tutorials/esp8266/ota/
-
AuthorPosts
- You must be logged in to reply to this topic.