[parsec67]

Thanks, yes I looked at the OTA example but it helps me only halfway as in my application I update by polling a web server periodically. Unfortunately I have not been able to get this to work, always getting “please check the bin file” after upgrade download has started and downloaded some bytes.

I did use the ESPImageTool.exe to generate .bin files and they are correctly identified as App1 and App2. Also tried with esptool.py 2.1 using elf2image and –version=2 option but same problem with both methods. I believe this is not a VisualGDB related issue but can’t be sure, the resources I have found online are not very clear on how to identify the problem.

I noticed that when switching configurations as per tutorial example, if the Embedded Project->Default linker script is changed from App1 to App2 it will also change for all configurations. It doesn’t seem to impact the binaries and the MSBuild linker script setting is unchanged.

[parsec67]

Hi again,

Does the updated R14 toolchain in some circumstances automatically flash blank.bin in addition to esp_init_data_default.bin?

I’ve now moved over to an Adafruit Huzzah (4MB) and noticed that WiFi credentials that are saved at memory address 0x3FE000 will sometimes get erased after flashing. I have not been able to discern any pattern, sometimes this sector is left untouched after flashing while other times it will be modified.

[parsec67]

Thanks for checking, I will give R14 toolchain a spin.

> You can program the FLASH memory without debugging via Debug->Program Firmware without Debugging.

Of course, it was there right in front of me all this time…

[parsec67]

I had something similar happen to me a while back, in my case me it was improper line endings that caused Clang Intellisense to see  bomb out. See this thread:

Clang Intellisense out of whack

I’ve also noticed it happen sometimes when there is a syntactical error somewhere in the code, such as a missing closing brace, but it is very rare.

[parsec67]

A slightly related followup question: Is there any way to just flash ESP from VisualGDB? That is, to bypass the “connecting to GDB stub” part?

[parsec67]

Hi,

Yes, this is the address I was using.

Cant’ tell if it wasn’t flashed at all or flashed to wrong address, the progress bar stops reporting after boot and user code is downloaded. The boot loop I had was exactly as described on your link, i.e. rf_cal[0] !=0x05,is 0xFF

 

[parsec67]

I call Bingo on this one!

Explicitly setting esp_init_data_default.bin to be flashed under “Additional flash resources…” fixed my problem. I now have serial communication working again.

Thanks for all your help!

[parsec67]

Another thing that popped up. After flashing Arduino code and then re-flashing VGDB code the ESP will go into a boot loop.

The reason seems to be esp_init_data_default.bin is never flashed/flashed to wrong address by VGDB. In my project settings I have the default option set in Debug settings->Additional flash resources to program, Initialization data file: $$SYS:BSP_ROOT$$/IoT-SDK/bin/esp_init_data_default.bin

I was under the impression that this would be flashed automatically to correct memory address based on flash size setting which is 2MB for this board?

 

EDIT: I got around this by flashing with ESP download tool. The problem remains, however.

• This reply was modified 6 years, 2 months ago by parsec67. Reason: additional clarification

[parsec67]

Alright, using VGDB, building and uploading code that prints out 0x55h in a loop and I measure nothing on the scope. There doesn’t seem to be any output other than briefly after resetting.

Back to Arduino, tried the same thing and when baud rate is configured to 9600 I get 4.8 kHz, for 74880 baud I see 37.4kHz. So UART looks okay to me.

I tried flashing VGDB binaries from within Visual Studio and independently using ESP Download tool but the result is the same.

[parsec67]

Hi,

I only have two baud rate options in project settings. Of these 74880 was working fine until today.

I’ll try analyzing the uart output speed but I cannot understand why this would change all of a sudden when it has worked reliably for several days (and still works with Arduino code flashed)?

Also could you please remove my email address in my previous post, thanks.

[parsec67]

Hi,

Sorry, using a different e-mail address on forums to reduce chance of password hacking. Email for VGDB license is <removed per user request>

[parsec67]

Hi,

I have reported it, will update this thread with any news from ST.

[parsec67]

Hi,

Attached zip file contains the gpdsc file and the files copied by CubeMX. This is the project using “Copy only the necessary library files” option for code generation.

I just now noticed there is one additional file that is referenced but not copied (stm32f4xx_ll_dmamux.h) and will obviously also fail to open in VS after project has been imported by VGDB. Firstly it is odd that it is referenced in gpdsc at all because no other project source file is including this file. Secondly,  stm32f4xx_ll_dmamux.h doesn’t even exist in Cube repository so there is nowhere to copy it from. This all sounds like a bug in CubeMX.

Attachments:

You must be logged in to view attached files.

[parsec67]

In regard to my project that was generated with “Copy only the necessary library files” and failed to build;

After some additional digging I’ve found that adding the two files stm32f4xx_hal.h/.c manually to the project from the Cube repository, and also adding the repository Drivers include path to the VGDB Include directories, the project will build successfully.

So it is possible to use “Copy only the necessary library files” option in CubeMX after all, only that a couple of extra steps (add the missing files + repo path) are required to get it to build.

I’m not sure if these missing HAL files are not copied by CubeMX due to a bug or by design but the important thing is that both ways I’ve tried turned out to work after sorting out the quirks.

[parsec67]

Hi,

Your answer gave me a valuable clue to get it to work; In CubeMX->Project->Settings->Code generator tab there is an option “Copy all used libraries into the project folder” which must be selected. Previously I had not used the VGDB CubeMX importer and only copied necessary library files when generating code, which I think is also the default setting.

After changing this option, generating the code and then importing into VisualGDB as per tutorial it almost worked. One additional step was necessary and that was to define USE_FULL_LL_DRIVER in VisualGDB Makefile settings/Pre-processor macros, otherwise the build will fail due to unknown type names.

After doing the above I can now build, run and debug LL projects. My blinky test project is blinking much more efficiently than with HAL 🙂

I’m still not sure why it wouldn’t work before but looking in the gpdsc file I found one reference to HAL drivers:

<component Cclass="Device" Cgroup="STM32Cube HAL" Csub="COMMON" Cversion="1.3.2">
      <description>CubeMX Generated HAL COMMON</description>
      <files>
        <file category="header" name="Drivers\STM32F4xx_HAL_Driver\Inc\stm32f4xx_hal.h"/>
        <file category="sourceC" name="Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal.c"/>
      </files>
    </component>

Both files are referenced in the imported project in VS Project explorer but not copied/cannot be opened (Error “Could not find file…”). So I guess the answer is to make sure that “Copy all used libraries into the project folder” is selected when generating code in CubeMX.

[Author]

Posts