## Debug Boot AS7 / AVR Dragon / ATmega128 - Cannot debug ELF or view disassembly (SLOVED Hardware Issue)

32 posts / 0 new
Author
Message

I am trying to debug an object file from a bootloader (ELF file flashed at 0x1E000) using Atmel Studio 7.0.1645 and and AVR Dragon probe (JTAG).

I have programmed the fuses, the content of Flash and the content of the EEPROM using an existing Makefile that used atprogram. I have AS7 to save the content of the EEPROM and Flash to make sure they contain the expected values. I have checked the Fuses that seem reasonable (assuming BOOTSZ is using 16-bits words and the "true" start address is 0x1E000 where I flashed by boot file).

I created a project from "Open Object File for Debugging", configured the programming settings with "Skip programming" and "Preserve EEPROM" and started debug with "Start Debugging and Break" (expecting the program to start running and stop immediately on the first instruction of the boot).

Instead, I get the PC at 0xFFFF (I was expecting 0X1E000) and I cannot see the content of the Dissassembly passed the first 64 KB (message "Memory Out of Bounds or Read Error").

I have some experience in embedded software development but am new to these tools. Is there some limitation I am not aware of or something I did wrong ?

Thanks

Bastien Continsouzas

Last Edited: Fri. Jun 1, 2018 - 01:37 PM

I would normally not have BOD or WDTON set while debugging.

Jim

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713... Total votes: 0 I tried again with the fuses EXTENDED.WDTON and LOW.BODEN unchecked but the result was the same. I tried relinking the bootloader at address 0x0, flashing it at the start of the Flash and starting without HIGH.BOOTRST (just to see if it was going to start at address 0x0 and do some stuff - even if it was not functional). The outcome is the same; when I start debugging, it stops at PC 0xFFFF. I noticed that the addresses in the Disassembly view are in words (2 bytes for each address) which explains why the valid addressing stops at 0xFFFF (128 KB). But that raises a question about something I do not understand. When I look at address 0x0, I expect to see the instructions I wrote to the Flash at address 0 but I can only see zeroes. It looks like the debugger only executes these NOP instructions and stops at the end. Bastien Continsouzas Total votes: 0 AS7 "caches" flash content. This gets in the way when debugging bootloading so you need to switch the caching off (in which case, when it breaks, it will read back the flash to display) Total votes: 0 As suggested, I unchecked the "Cache all flash memory except" debug setting but it does not solve my issue. Atmel Studio says that it is "Debugging" but I can only see zeroes (for register values, flash content, EEPROM content...). Looking more closely at the documentation about debugging an Object File, it seems that I have an (undocumented) issue during the project creation. So the debugger is probably in an undefined state that cannot work anyway. Bastien Continsouzas Last Edited: Thu. May 31, 2018 - 01:23 PM Total votes: 0 Why aren't you simply debugging "normally"? Have the source of the bootloader in AS7, let it build it, then let it download the code before you start to debug it. Total votes: 0 I am trying to run a legacy project with a Makefile that can build the bootloader and application and program the flash/EEPROM and fuses on our custom test board. This is something that has worked in the past (someone else was using this). When I power-on the board, the soft does not seem to do anything so I first wanted to check the state of that micro. This is something I usually do with ARM CPU / Texas Instrument tooling (load stuff in RAM, attach a debug session, reset the processor or move the program counter...) but I am not familiar with the debug capabilities for ATmega128. I also tried to create a project from the source with "Create Project from Makefile" for the bootloader part. It builds the ELF file and does the programming (I checked the content of Flash). But when I start debugging, Atmel Studio displays an error message: I set the HIGH.OCDEN fuse and get a different result when starting Debugging with the ELF object. • Program Counter is 0x0000F001 (address of the bootloader + 1) • All areas of Flash report values 0xff 0xff • All registers and EEPROM report values 0x89 0x89 I am not sure what to make of it. Thanks for the support. Bastien Continsouzas Total votes: 0 As I say, I'd just put the bootloader sources into an AS7 project and build it there. Then debug the result. Total votes: 0 I created a project from scratch (New Project > GCC C Executable Project), added the source files and used Atmel Studio "Build Solution" to build the ELF. Done building target "Build" in project "GccBasic.cproj". Done building project "GccBasic.cproj". Build succeeded. ========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========  I get the exact same message as when using the sources built from my custom Makefile: The only message in the output pane says: The program '[0] basic.elf' has exited with code 0 (0x0). I even tried with an empty test project and had the same outcome: int main(void) { /* Replace with your application code */ while (1) { } }  With such a simple operation failing, I followed the hardware lead, found that one difference between programming (working) and debugging (not working) is that the latter requires a valid clock. I managed to get support from a hardware guy that confirmed the oscillator on my test board was KO. For once, it was not software's fault. Bastien Continsouzas Total votes: 0 bcontins wrote: For once, it was not software's fault. Glad you found the solution ! Total votes: 0 Hello, my question is, can an .elf file generated from avr in linux be loaded in AS7? And will the debug work ok? I am having a very nasty problem, and without a debugger probably I can't solve it. This solution seems the easiest at the moment, as the setup is too complicated in linux to be reproduced and compiled in AS. My understanding from what I read is that it is necessary that the elf file is generated with the dwarf2 format, and some fuses must be enabled? The uc is an AT90CAN128 running at 16MHz. Total votes: 0 bbogdanmircea wrote: I am having a very nasty problem, and without a debugger probably I can't solve it. You can though maybe not as quickly. https://www.avrfreaks.net/forum/led-indicator-software-debugging#comment-2421756 "Dare to be naïve." - Buckminster Fuller Total votes: 0 ELF (or rather DWARF) debugging works by labelling certain ranges of opcodes with the path to the source file and line number(s). If you build in Linux and deug in Windows the Linux paths will not be valid. Total votes: 0 Yes, you can debug an ELF file generated in Linux on a Windows PC. And vice-versa. It should contain all the details of arrays, structs, variables, special registers, ... However it is unlikely that your Windows PC can access the same source files in the same locations. I debug ELF generated by the Arduino IDE files in Rowley. Works fine as long as the source files are all accessible and available. David. p.s. ARM-ELF files work well in Rowley. Less well in AS7.0 AVR-ELF object files are not very good in AS7.0 Simple veriables should be fine. Deeply nested C++ classes, structs, ... are iffy. Last Edited: Sat. Jul 13, 2019 - 08:05 PM Total votes: 0 I don't think I can use you lib for my problem. My uC stops during my problem, so there would be no comm basically. Total votes: 0 I managed to load the elf in AS7 and start in Debug Mode, I can see the memory with the assembler instructions, the cursor jumps when I run the debug, I can see all the registers and pin registers when I stop the debug. The only problem is that I can't see the source code, so how can I set up some breakpoints? I guess I could read the .map file and then based on the addresses to set some breakpoints but this looks extremely slow. Is there some way to tell to AS which source files were used for generating the elf file? Total votes: 0 Was the code originally built with -g ? Like I say, I *think* that when the ELF loader finds a pathname it can't locate it will throw a dialog asking you to say where the new location of the .c is. But to do this is needs debug references in the first place and they get embedded as a result of -g EDIT: OK so I tried a Windows-Windows test. In AS7 I created a built a project with main.c. Then I closed the solution and moved main.c to another location. Next I used the option in AS7 to start debugging an ELF. When I did that it showed: While the three green ticks seem to suggest it thinks it has found all the files I know it cannot have found main.c and the summary at the bottom says "Missing: 2" (the other one will be the CRT). So when you see a dialog like this on loading the ELF you should be able to set up "alias paths" for some of the source files to say what the new (non Linux) file locations are. Last Edited: Mon. Jul 15, 2019 - 08:53 AM Total votes: 0 If your source tree is on a Windows directory, Windows can find the individual files. Build the ELF in Linux if you like. Linux can read all your Windows files. Load the ELF into AS7.0 as "object file project" When it prompts for a source file you can Browse the Winndows filesystem. . Quite honestly. Why don't you build the ELF in the Windows filesystem with AS7.0 in the first place? . David. Total votes: 0 The thing is that an ELF built in Linux is going to have paths in the debug part of the ELF to files like /home/foo/projects/AS7/clock/main.c or whatever. But in Windows the file is more likely C:\users\foo\projects\AS7\clock\main.c or similar. Now what I've done in the past is either run Windows on top of Linux or Linux on top of Windows and set up shared folders so /home/foo/data appears as something like D:\data or similar so the tree of files is visible in both but the complete paths still differ in that they are rooted at /home/user/data/ versus d:\data\ or similar. Like David, I'd just do all the development in one environment. As AS7 is the "best" tool for debugging AVR then I'd err towards Windows rather than Linux. So put all the source there, build them all there and debug them all there. Total votes: 0 You will probably find the files are relative to the ELF. So it is only necessary to browse for one file. Then all the others get located at the same time. . I regularly debug SAM3X, SAMD21 elf files generated by Arduino IDE. Ok, Rowley does it better. But AS7.0 will locate all the source filles and give you full debugging. . I attempted to do the same with AVR elf files and AS7.0 is not very good for walking through complex C++ classes. . Explain what you want to do e.g. C, C++, ASM, ... and with which targets. I suspect that a reader somewhere will have done something similar. . Remember that MPLABX and Eclipse exist. Some masochists must have got on top of them. And one day they might become usable. So Linux will be a practical platform one day. Actually Rowley AVR C works well on Linux. They have lost interest in AVR. But they are excellent for ARM. . David. Last Edited: Mon. Jul 15, 2019 - 09:48 AM Total votes: 0 I tried today but to no avail. The .elf file built in Linux loads only in assembler mode, I have no option to add source files whatsoever. Instead if I build a simple project in ATMEL, then load the .elf from it as an Object file and it loads then the source file and I can debug it no problem. I then looked at the Debug configuration and saw that the option -g2 and -DDEBUG is used so I added also these 2 to my compile line in Linux but still doesn't work. What I could do is to copy all the compile flags from AtmelStudio to my Linux Compile line to see at least if this is the problem. If there are some experts in what compilation flags are needed to generate and elf that has also the source information that would be also very helpful. Total votes: 0 Go on. Explain what you want to do. Yes, of course you can build an ELF file in Linux. Or you could build an ELF in Windows or MAC. The avr-gcc command line(s) are exactly the same in Linux, Windoze or MAC You would store the project Source files in exactly the same form of directory tree. I am 99.99% confident that the binary ELF file will be identical on each platform regardless of native integer-size, endian-ness, day of the week, ... Likewise I would be 99.99% confident that all the GCC tools will work on each platform. I would be less confident about AS7.0 with bigendian-ness etc. Creating ELF files for AVR requires quite a few arguments and switches for the Harvard architecture. If you omit some you end up with missing Sections. Post the actual command lines that you are using with Linux. Quote the version numbers of the GCC tools. You can even post a ZIP that contains your Source files with your Linux generated ELF. The real mystery is: Why don't you build and debug in AS7.0 ? Many readers can even debug on a real m128 with a real Dragon. David. Last Edited: Mon. Jul 15, 2019 - 12:54 PM Total votes: 0 A typical AS7 build seems to be: -x c -funsigned-char -funsigned-bitfields -DDEBUG -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\Atmel\ATmega_DFP\1.3.300\include" -Os -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -pedantic -mmcu=atmega328p -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\Atmel\ATmega_DFP\1.3.300\gcc\dev\atmega328p" -c -std=gnu99 -H -Q -save-temps -MD -MP -MF "$(@:%.o=%.d)" -MT"$(@:%.o=%.d)" -MT"$(@:%.o=%.o)"

As far as debugging goes the only important switch there is -g2 which is what you say you used.

Build an "empty" main.c in Linux then post the ELF as an attachment here.

A typical ELF when objdump'd will show section headers like:

D:\test\test\Debug>avr-objdump -h test.elf

test.elf:     file format elf32-avr

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
0 .data         00000000  00800100  0000009e  00000112  2**0
1 .text         0000009e  00000000  00000000  00000074  2**1
2 .comment      00000030  00000000  00000000  00000112  2**0
3 .note.gnu.avr.deviceinfo 00000040  00000000  00000000  00000144  2**2
4 .debug_aranges 00000020  00000000  00000000  00000184  2**0
5 .debug_info   00000694  00000000  00000000  000001a4  2**0
6 .debug_abbrev 00000604  00000000  00000000  00000838  2**0
7 .debug_line   000001f2  00000000  00000000  00000e3c  2**0
8 .debug_frame  00000024  00000000  00000000  00001030  2**2
9 .debug_str    0000031e  00000000  00000000  00001054  2**0
10 .debug_loc    0000004d  00000000  00000000  00001372  2**0
11 .debug_ranges 00000010  00000000  00000000  000013bf  2**0
CONTENTS, READONLY, DEBUGGING

The .debug* sections are the result of the -g2.

david.prentice wrote:
I am 99.99% confident that the binary ELF file will be identical
Guess again:

D:\test\test\Debug>avr-objdump -s -j .debug_line test.elf

test.elf:     file format elf32-avr

Contents of section .debug_line:
0000 2f010000 02002c00 00000201 fb0e0a00  /.....,.........
0010 01010101 00000001 2e2e2f2e 2e2f2e2e  ........../../..
0020 2f2e2e2f 63727431 00006763 7274312e  /../crt1..gcrt1.
0030 53000100 00000005 02000000 00033c01  S.............<.
0040 03020904 00010301 09040001 03010904  ................
0050 00010301 09040001 03010904 00010301  ................
0060 09040001 03010904 00010301 09040001  ................
0070 03010904 00010301 09040001 03010904  ................
0080 00010301 09040001 03010904 00010301  ................
0090 09040001 03010904 00010301 09040001  ................
00a0 03010904 00010301 09040001 03010904  ................
00b0 00010301 09040001 03010904 00010301  ................
00c0 09040001 03010904 00010301 09040001  ................
00d0 03010904 00010904 00000101 0005027c  ...............|
00e0 00000003 cc010109 04000001 01000502  ................
00f0 68000000 03e10101 03010902 00010301  h...............
0100 09020001 03090902 00010301 09020001  ................
0110 03020902 00010902 00000101 00050274  ...............t
0120 00000003 b5020103 01090400 01090400  ................
0130 000101bb 00000002 00810000 000201fb  ................
0140 0e0a0001 01010100 0000012e 2e2f2e00  ............./..
0150 633a5c70 726f6772 616d2066 696c6573  c:\program files
0160 20287838 36295c61 746d656c 5c737475   (x86)\atmel\stu
0170 64696f5c 372e305c 746f6f6c 63686169  dio\7.0\toolchai
0180 6e5c6176 72385c61 7672382d 676e752d  n\avr8\avr8-gnu-
0190 746f6f6c 63686169 6e5c6176 725c696e  toolchain\avr\in
01a0 636c7564 6500006d 61696e2e 63000100  clude..main.c...
01b0 00737464 696e742e 68000200 00000005  .stdint.h.......
01c0 02800000 00130300 09000001 00020403  ................
01d0 03040908 00010002 0403037f 09080001  ................
01e0 03030902 00010301 09020001 09060000  ................
01f0 0101                                 ..

Do you really think the same code built in Linux is going to have embedded within it a mention of C:\Program Files(x86)\atmel\studio\7.0\etc. ??

It's also pretty unlikely this is going to match exactly either:

D:\test\test\Debug>avr-objdump -s -j .comment test.elf

test.elf:     file format elf32-avr

Contents of section .comment:
0000 4743433a 20284156 525f385f 6269745f  GCC: (AVR_8_bit_
0010 474e555f 546f6f6c 63686169 6e5f332e  GNU_Toolchain_3.
0020 362e315f 31373530 2920352e 342e3000  6.1_1750) 5.4.0.

I would, however, hope that .text and .data sections would have binary identical payload.

Yes,  of course the platform housekeeping fields will vary with platform.

I would still expect the target binary and target debug information to be same.

There is nothing new about Studio debugging foreign object files.

I would debug Codevision COFF files in AS4.

There is/was an IAR format that could be debugged in AS4.

AS7.0 can still parse ELF and COFF.    I suspect it can parse some IAR too.

Parsing is one thing.    Following all the intricacies of complex data structures is not always 100%.

The ARM tools are "better".   But debugging AVR has always been fairly respectable.    Certainly compared to MPLABX

David.

Last Edited: Mon. Jul 15, 2019 - 02:51 PM

Tomorrow I will try also to look at the .elf files like you wrote above, but probably the different path is the problem.

If anybody has more experience and can try to generate an .elf in Linux and then load it in AS7 in Windows this would be extremely helpful.

I kind of debugged today, just by setting Data Write Breakpoints and then figuring out what is happening, but it was extremely difficult and

time consuming.

When I load the elf generated in Linux, there is no option to add any source files, even if I build it with both -g2 and -DDEBUG, so something is definitely wrong.

The paths to the source files and the symbol information is all encoded in the .elf file?

Thanks!

Today I even installed avarice on my Linux PC hoping that maybe I can connect gdb to avarice to ATMEL ICE, and then I could at least debug with gdb in Linux

But when I run avarice I received an /dev/avrjtag does not exist, even if I connected ATMEL ICE on USB on my Linux PC.

Maybe this does not belong to this topic

Forget avarice for the time being. Just try loading the ELF in to avr-gdb and use the l (lower case L) command. Do you see the source ? If not then once again this is because of the lack of viable debug info.

Type "apropos word" to search for commands related to "word".
(gdb) file main.elf
(gdb) l
1	#include <avr/io.h>
2
3	int main(void)
4	{
5		DDRA = 0;
6		DDRA |= ((1 << PA3) | (1 << PA4) | (1 << PA5) | (1 << PA6));
7	    /* Replace with your application code */
8	    while (1)
9	    {
10			PORTA |= (1 << PA3);


And sure enough it works.

So I guess the debug symbols are there for avr-gdb but not for Atmel Studio? How does that work?

But you also have the main.elf that I generated, you can also check.

Now If I could only configure avarice to make avr-gdb communicate with the ATMEL ICe, then I could debug in Linux ... any hopes for that?

Try changing -g2 to -gdwarf-2 (I have a feeling you may be getting stabs rather than ELF/DWARF debug info).

OK I will try, even if I managed to make the debug work under Linux with avarice and avr-gdb. It would be even nicer if I could also debug under Atmel Studio, even if avr-gdb is pretty strong from what I can see, it has lots of options, the only think missing is a gui so I don't have to do the print CANSTMOB statements by myself.

Last Edited: Thu. Jul 18, 2019 - 08:19 PM

bbogdanmircea wrote:
... even if avr-gdb is pretty strong from what I can see, it has lots of options, the only think missing is a gui so I don't have to do the print CANSTMOB statements by myself.

What is GPS? | GitHub - AdaCore/gps: The GNAT Programming Studio.

...

[picture, bottom left to right then up - Debugger Console for operator's access to GDB, variables window, breakpoints window, source code windows with breakpoint arrow]

though current GPS may have some light re-work to restore AVR GDB.

AVR Eclipse exists.

Should have more options in Linux IDE for AVR though your mention of GDB GUI may be the easiest fit.

10. Debugging — GPS 20.0w documentation

for AVR that's Windows only, without XMEGA (it's a patched FSF AVR GCC 4.5), ATJTAGICE2 (AVR JTAGICE mkII)

FSF AVR GCC 4.7 adds XMEGA and the new address spaces of __flash, __flash1, __flash2, __flash3, __flash4, __flash5, and __memx

ATJTAGICE2 EOL :

Product Change Notification - WE142203 - 06 Jun 2014 - Product End-of-Life (EOL) Notification

AVR is legacy at AdaCore though still in their catalog.

Atmel® AVR® 8-bit microcontroller | Embedded Development | GNAT Pro | AdaCore

AVR Source-level Debugging in Eclipse (WinXP) with Dragon – Success! | AVR Freaks

edit2 :

Sites and links related to GDB

GDB Front Ends - GDB Wiki

Insight is apparently not being maintained.

DDD has QA issues in Debian.

Code Medic is up-to-date and may be of interest.

"Dare to be naïve." - Buckminster Fuller

Last Edited: Fri. Jul 19, 2019 - 12:58 PM