I'm trying to debug a file compiled in Eclipse with the uVision version V220.127.116.11 in a microcontroller STR912FAW47. I can insert breakpoints in the assembler windows but the option is disable when I try to do the same in the windows with the C code (figure). Do I need to add something on the makefile to activate the debbuging?
Thanks in advance
Presumably, when you say Eclipse - that means that the code was compiled with GCC ?
It's the Compiler (and Linker, etc) that's significant - rather than the IDE it's hiding behind.
In theory, it should be possible - but, yes, you do need to make special efforts to get everything lined-up and compatible:
It might be easier to just do the debugging in Eclipse ...
That's what I did in the end.
(especially as ST now have a ready-to-go Eclipse-based IDE for their products - which wasn't the case back then)
Thanks for the reply Andy, I tried to change the symbols for debugging, but the options to set the breakpoints in the C code are not yet activated.
Did you follow the link to the 'launchpad' thread - where user 'steven_cooreman' suggested some settings to try ?
Or try Eclipse?
I tried adding the flags in the post but -gdwarf-3 and -gstrict-dwarf creates some problems (-gdwarf-2 works fine). I have the message "debug output level not recognized" dwarf-3 ""
Like I said, I ended up just using Eclipse to debug Eclipse-generated code.
Back in the days of that thread, setting up debugging on Eclipse was a bit of a pain - but it worked fine once I got it going.
Now that ST have their own solution, I have found that "just works" ...
Please can you tell us a bit more about the file that you have loaded into the Debugger? If the Debugger is not letting you set breakpoints in the C code, then I suspect your file does not contain debug information. Is it an ELF file (e.g. .axf), or a plain binary file? Plain binary files does not contain debug information.
If it is ELF, and you are building with GCC, then use "objdump --debugging" or "readelf --debug-dump" to check if the objects & executable contain debug information. If building with the Arm Compiler, use "fromelf -g".
If you see no debug information, then check that the compile step is adding debug information into the ELF objects (I see you are using -gdwarf-2 already, so that should be OK), and then check that the link step isn't accidentally removing the debug information with e.g. --strip-debug.
The STR912FAW47 is an ARM966E-S based device, so you may fare better by using a single toolchain for building and debugging your code, such as the Arm Development Studio developer.arm.com/.../arm-development-studioThe STR912-family boards are supported directly by Arm Development Studio via DSTREAM/DSTREAM-ST debug hardware.
I'm uploading an .elf file that is for sure, what I find a little bit strange is that commands like -gdwarf-3 are not recognized by the compiler, it could be because the project was based on ECOS (old OS for microcontrollers) and maybe -gdwarf-3 wasn't created at the time.
The compiler that I'm using is the arm-elf-gcc and I'm not sure how to use --debugging or --debug-dump, I tried to add it as a symbol for debugging but it is not recognizing neither of those by the compiler.
Thanks for the help
Hi AlanThe objdump and readelf utilities are normally provided with gcc. If you are using arm-elf-gcc, then they will be named arm-elf-objdump and arm-elf-readelf.eCos seems to have a lot of debug configurations options, such as CYGVAR_KERNEL_THREADS_LIST. You may need to check the settings of these options.
Hope this helps you to progress.
The arm-elf-readelf works as a command, when I run it I got in the cmd this message:
I'm not sure what should I look in this file, I already saved it in a document.
Hi AlanI've not seen that error before, but it might indicate that the debug information is being generated incorrectly, which might then explain why the debugger is unable to handle it.A quick Google search for "Location lists in .debug_info section aren't in ascending order" points to this being caused by a bug in the toolchain. To avoid this, you could try changing your source code, or reducing the optimization level.As a quick check, try compiling a simple Hello World program with "-g", then use readelf. You should see something like::Contents of the .debug_info section: Compilation Unit @ offset 0x0: Length: 0x22 (32-bit) Version: 2 Abbrev Offset: 0x0 Pointer Size: 4 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit) <c> DW_AT_stmt_list : 0x0 <10> DW_AT_low_pc : 0x80010128 <14> DW_AT_high_pc : 0x80010278:Then load the image into the debugger. Are you able to debug Hello World at source level?
View all questions in Keil forum