VisualGDB not flashing device

[loripino21]

Hi,

I downloaded VisualGDB trial and I am evaluating in on Visual Studio 2015 Enterprise and on a ST STM32F429ZiT6U.

I ran the demo project (LEDBlink) and all went fine. Now I am trying to get the project I am working on running: it is based on a custom kernel (miosix: https://miosix.org/) then I deleted all references to BSP  and HAL from the demo project and I modified the visualGDB makefile to get all compiling. And it compiles perfectly without errors, and create all .elf and .bin files.

Now the problem is: if I hit F5, visualGDB DOESN’T flash my board and starts the debug, which incredibly starts WITHOUT any error but is unable to hit any breakpoint obiviously. The debug is started, openocd says target cpu halted, but visual studio is like in running state and everything is stuck. If I manually flash my board using the generated .bin file, and restart debugging in VisualGDB, debug WORKS fine!

I tried all ways to enable VisualGDB verbose mode, both http://visualgdb.com/features/advanced/verbosemode.php and http://visualgdb.com/features/common/gdblogs.php but I am unable to find any errors, but also I am unable to find any flash commands!!

Can someone help me? I spent a whole working day to set up my project compiling on visualgdb and I don’t want to see my time wasted!

Thanks!!

[support]

Hi,

Sure, please share the gdb log showing the commands VisualGDB is issuing and the GDB responses so that we could help you figure out why programming is broken.

[loripino21]

Hi,

I have tried to run again the debug. I have just now noticed the option “RAW output from GDB” and I was able to see even flash commands. But I can swear the device is not baing flashed: I am working with a simple ledon/off and even if I switch led in the code the board keeps flashing always the same. In the zip you can find debug.mak and Makefile modified by me, according to the demoMakefile which is included with the kernel. Notice the ‘include Makefile.inc’ command, that file is attached. LINKER_SCRIPT is not configured in debug.mak since it’s already set by makefile.inc when including it; I have put it in the zip if it may be needed.

https://www.dropbox.com/s/a2tg6coc7rb2twl/VisualGDBIssue.zip?dl=1

Thanks for the help!!

[loripino21]

I thought it would be better to attach the whole demo project to let you test everything. I use a customized toolchain, you can download it from https://miosix.org/wiki/index.php?title=Miosix_Toolchain.

The demo project: https://www.dropbox.com/s/jen77y8xg3rit92/EmbeddedProject1.zip?dl=1

You can test if VisualGDB is flashing by going to definition of ledOn/Off and change the pin number.

[support]

Hi,

Based on a quick look, you are using a custom linker script, so the problem might be inside it.

Please use the GDB Session window to run the following commands:

• compare-sections
• maint info sections

The first command will compare each section of the ELF file (e.g. code, data, interrupt handlers) to the memory contents on the device and will pinpoint the mismatching ones.

The second command will list all sections in the ELF file. Please check that each section marked with the LOAD attribute is within your device FLASH or RAM bounds, e.g.:

 [1]     0x0400->0x092c at 0x00008400: .text ALLOC LOAD READONLY CODE HAS_CONTENTS

Section size = 0x92c – 0x400 = 0x52C, range = 0x8400 – 0x892C => within FLASH range (0x0000 – 0xFFFF). The RAM and FLASH addresses and sizes can be found in your device datasheet.

If this does not help solve the problem, please let us know the exact device you are using and attach the output of both commands.

Note that sections like .debug_info do not have the LOAD attribute and hence do not need to be checked as they are not loaded into the device.

[loripino21]

Here is the output of compare-sections:

compare-sections
&”compare-sections\n”
~”Section .text, range 0x8000000 — 0x8016590: MIS-MATCHED!\n”
~”Section .ARM.exidx, range 0x8016590 — 0x8017118: MIS-MATCHED!\n”
~”Section .data, range 0x8017118 — 0x8017628: MIS-MATCHED!\n”
&”warning: One or more sections of the remote executable does not match\nthe loaded file\n”
&”\n”
^done

As expected, all sections mismatch.

maint info sections
&”maint info sections\n”
~”Exec file:\n”
~”    `D:\\Documenti\\Programmazione\\BoardSTM33F429I\\Miosix\\EmbeddedProject1\\Debug\\EmbeddedProject1.elf’, file type elf32-littlearm.\n”
~”    0x8000000->0x8016590 at 0x00008000: .text ALLOC LOAD READONLY CODE HAS_CONTENTS\n”
~”    0x8016590->0x8017118 at 0x0001e590: .ARM.exidx ALLOC LOAD READONLY DATA HAS_CONTENTS\n”
~”    0xd0000000->0xd0000510 at 0x00020000: .data ALLOC LOAD DATA HAS_CONTENTS\n”
~”    0xd0000510->0xd0000878 at 0x00020510: .bss ALLOC\n”
~”    0x0000->0xfbd86 at 0x00020510: .debug_info READONLY HAS_CONTENTS\n”
~”    0x0000->0x192d8 at 0x0011c296: .debug_abbrev READONLY HAS_CONTENTS\n”
~”    0x0000->0x4f9ba at 0x0013556e: .debug_loc READONLY HAS_CONTENTS\n”
~”    0x0000->0x2638 at 0x00184f28: .debug_aranges READONLY HAS_CONTENTS\n”
~”    0x0000->0xc2f8 at 0x00187560: .debug_ranges READONLY HAS_CONTENTS\n”
~”    0x0000->0x2355f at 0x00193858: .debug_line READONLY HAS_CONTENTS\n”
~”    0x0000->0x2c988 at 0x001b6db7: .debug_str READONLY HAS_CONTENTS\n”
~”    0x0000->0x0011 at 0x001e373f: .comment READONLY HAS_CONTENTS\n”
~”    0x0000->0x0037 at 0x001e3750: .ARM.attributes READONLY HAS_CONTENTS\n”
~”    0x0000->0x680c at 0x001e3788: .debug_frame READONLY HAS_CONTENTS\n”
^done

All sections are within flash range of my device, ST STM32F429ZiT6U.  The only strange thing to me is that .bss section has not the load attribute.

Any hints?

[support]

Hi,

Yes, the addresses look normal. The .bss section contains uninitialized variables, so it does not have the LOAD attribute by design.

Then the problem is either in the faulty hardware or in your OpenOCD settings. Please try creating a new project for the same chip using default settings and programming it. Does this work?

If yes, please replace the ELF file of the project that is broken with the ELF file from the project that works. Then run the project without rebuilding it (Debug->Start debugging with GDB). Does VisualGDB load the other project file using the current project settings correctly? Does compare-sections succeed? If no, what is different between the 2 projects’ settings. If yes, what is different between the 2 ELF files (you can enable the .map file generation to dump a general overview of the ELF file structure during building)?

[loripino21]

Hi, I tried everything.

If I create a demo project, for example LED flashing HALDemo, it works perfectly. I completely erased the device flash, run debug again and everything worked flawlessy, breakpoints included.

Then I replaced generated elf and bin file with those of non-working project, started debugging without recompiling and the device was flashed correctly!! compare-sections succeds.

I tried creating similar projects with different toolchains, and guess what? When I select SysGCC toolchain for projects, it always flash correctly the device. When I select my custom miosix toolchain, it won’t flash, regardless the file to flash was generated with one or the another toolchain.

How to fix this problem? How is toolchain involved in flashing process?

[support]

Hi,

This is very strange. Please try using the OpenOCD’s FLASH programming commands instead of the GDB ones.

You can issue them from the GDB Session window by prefixing them with “mon”, e.g. “mon program c:/project.elf verify”. If it does not work with the ELF files, would it work with the BIN files?

[loripino21]

I tried it, flashing does NOT work using .bin file:

mon program D:/Documenti/Programmazione/BoardSTM33F429I/Miosix/MiosixProject/Debug/HALDemo.bin verify
&”mon program D:/Documenti/Programmazione/BoardSTM33F429I/Miosix/MiosixProject/Debug/HALDemo.bin verify\n”
@”target state: halted\n”
@”target halted due to debug-request, current mode: Thread \n”
@”xPSR: 0x01000000 pc: 0x08012070 msp: 0x10000200\n”
@”** Programming Started **\n”
@”auto erase enabled\n”
@”no flash bank found for address 0\n”
@”wrote 0 bytes from file D:/Documenti/Programmazione/BoardSTM33F429I/Miosix/MiosixProject/Debug/HALDemo.bin in 0.000000s (nan KiB/s)\n”
@”** Programming Finished **\n”
@”** Verify Started **\n”
@”target state: halted\n”
@”target halted due to breakpoint, current mode: Thread \n”
@”xPSR: 0x61000000 pc: 0x2000002e msp: 0x10000200\n”
@”checksum mismatch – attempting binary compare\n”
@”diff 0 address 0x00000001. Was 0x02 instead of 0x00\n”
@”diff 1 address 0x00000002. Was 0x00 instead of 0x02\n”
@”diff 2 address 0x00000003. Was 0x10 instead of 0x20\n”
@”diff 3 address 0x00000004. Was 0x71 instead of 0x09\n”
@”diff 4 address 0x00000005. Was 0x20 instead of 0x00\n”
@”diff 5 address 0x00000006. Was 0x01 instead of 0x00\n”
[…..]
@”More than 128 errors, the rest are not printed.\n”
@”embedded:startup.tcl:454: Error: ** Verify Failed **\n”
@”in procedure ‘program’ \n”
@”in procedure ‘program_error’ called at file \”embedded:startup.tcl\”, line 498\n”
@”at file \”embedded:startup.tcl\”, line 454\n”
^done

But WORKS with .elf file!!

mon program D:/Documenti/Programmazione/BoardSTM33F429I/Miosix/MiosixProject/Debug/HALDemo.elf verify
&”mon program D:/Documenti/Programmazione/BoardSTM33F429I/Miosix/MiosixProject/Debug/HALDemo.elf verify\n”
@”target state: halted\n”
@”target halted due to debug-request, current mode: Thread \n”
@”xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc\n”
@”** Programming Started **\n”
@”auto erase enabled\n”
@”target state: halted\n”
@”target halted due to breakpoint, current mode: Thread \n”
@”xPSR: 0x61000000 pc: 0x20000042 msp: 0xfffffffc\n”
@”wrote 16384 bytes from file D:/Documenti/Programmazione/BoardSTM33F429I/Miosix/MiosixProject/Debug/HALDemo.elf in 0.625011s (25.600 KiB/s)\n”
@”** Programming Finished **\n”
@”** Verify Started **\n”
@”target state: halted\n”
@”target halted due to breakpoint, current mode: Thread \n”
@”xPSR: 0x61000000 pc: 0x2000002e msp: 0xfffffffc\n”
@”verified 264 bytes in 0.046877s (5.500 KiB/s)\n”
@”** Verified OK **\n”
^done

I can agree that the device is flashed correctly and debug works.

Ok. Now? Is there any method to overwrite default flash command?

P.S.: I did other tests. If I create a new project using default SysGCC toolchain, but i manually modify Makefile such that it compiles using my toolchain but it runs debug using SysGCC (i.e. for the command –interpreter mi xxx.elf), it compiles & flashes correctly!

At this point I guess there is some incompatibilities between visualgdb and my modified toolchain…

 

[loripino21]

Ok, it flashes but if I try to set more than 4 breakpoints:

Info : no flash patch comparator unit available for hardware breakpoint
Error: can’t add breakpoint: resource not available

• This reply was modified 9 years ago by loripino21.

[support]

Hi,

If the flashing is broken when you use the GDB from your toolchain, but works with our GDB, this looks like a bug in your GDB executable. You can simply replace it with the gdb from SysGCC.

You can also add the OpenOCD flashing command to the startup commands in the VisualGDB Project Properties window. This should invoke the programming automatically.

The error message is shown because you have used all the hardware breakpoints on your device. You can work around this using one of the following methods:

• Place some of the code or the entire program into RAM so that the software breakpoints will work
• Do not use more than 4 breakpoints at the same time
• Use Segger J-Link with Segger software that supports unlimited software breakpoints in FLASH (please confirm the specific versions and device compatibility with Segger)

[loripino21]

Ok, it works now! Thanks!

Regarding Segger J-Link: i can’t understand if my device is supported and if I will be able to use the current STLink USB interface or I need to buy their hardware.

My device is a ST STM32F429 discovery. Thanks, Lorenzo

[support]

Hi,

We would recommend checking device compatibility with Segger support. Their software is usually pretty reliable, so it might be a good investment to get a J-Link.

[Author]

Posts