Windows Atmel Studio 6.2.1502 Sp1 does not take a linux elf for debugging.

Go To Last Post
54 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm trying to use Atmel Studio 6.2.1502 Sp1 to debug an elf file created in linux with AVR gcc toolchain:

 

$ avr-gcc -v
Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/misc/apps/avr8/avr8-gnu-toolchain-linux_x86_64/bin/../libexec/gcc/avr/4.8.1/lto-wrapper
Target: avr
Configured with: /data2/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/src/gcc/configure LDFLAGS=-L/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86_64/lib CPPFLAGS= --target=avr --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86_64 --libdir=/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86_64/lib --enable-languages=c,c++ --with-dwarf2 --enable-doc --disable-shared --disable-libada --disable-libssp --disable-nls --with-avrlibc=yes --with-mpfr=/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86_64 --with-gmp=/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86_64 --with-mpc=/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86_64 --enable-fixed-point --with-pkgversion=AVR_8_bit_GNU_Toolchain_3.4.3_1072 --with-bugurl=http://www.atmel.com
Thread model: single
gcc version 4.8.1 (AVR_8_bit_GNU_Toolchain_3.4.3_1072)

 

I've created it with -gdwarf-2 and the like, but the Atmel Studio 6.2.1502 Sp1 refuses to accept it. Complains that it is not compatible with any of the readers...

 

Anybody knows what could be the problem?

David F.

Last Edited: Tue. Dec 16, 2014 - 03:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do an avr-readelf -h on the .elf file you produced - what does it say? I'll post the same from something the avr-gcc in Studio 6 built...

 

EDIT: ta da....

C:\Documents and Settings\asl\My Documents\Atmel Studio\6.2\test\test\Debug>avr-readelf -h test.elf
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Atmel AVR 8-bit microcontroller
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          52 (bytes into file)
  Start of section headers:          2720 (bytes into file)
  Flags:                             0xb3
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         2
  Size of section headers:           40 (bytes)
  Number of section headers:         15
  Section header string table index: 12

As long as you can create ELF with the same format then Studio should be happy.

 

Of course this doesn't mean it contains debug info - a file that dies shows:

C:\Documents and Settings\asl\My Documents\Atmel Studio\6.2\test\test\Debug>avr-readelf -S test.elf
There are 15 section headers, starting at offset 0xaa0:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .data             PROGBITS        00800100 0001f2 000000 00  WA  0   0  1
  [ 2] .text             PROGBITS        00000000 000074 00017e 00  AX  0   0  2
  [ 3] .comment          PROGBITS        00000000 0001f2 000030 01  MS  0   0  1
  [ 4] .debug_aranges    PROGBITS        00000000 000222 000020 00      0   0  1
  [ 5] .debug_info       PROGBITS        00000000 000242 000275 00      0   0  1
  [ 6] .debug_abbrev     PROGBITS        00000000 0004b7 00018e 00      0   0  1
  [ 7] .debug_line       PROGBITS        00000000 000645 000169 00      0   0  1
  [ 8] .debug_frame      PROGBITS        00000000 0007b0 000034 00      0   0  4
  [ 9] .debug_str        PROGBITS        00000000 0007e4 0001a2 01  MS  0   0  1
  [10] .debug_loc        PROGBITS        00000000 000986 000073 00      0   0  1
  [11] .debug_ranges     PROGBITS        00000000 0009f9 000010 00      0   0  1
  [12] .shstrtab         STRTAB          00000000 000a09 000096 00      0   0  1
  [13] .symtab           SYMTAB          00000000 000cf8 000510 10     14  23  4
  [14] .strtab           STRTAB          00000000 001208 00030e 00      0   0  1

Oh and remember that DWARF2 does not contain C source but just paths to files in the local filesystem so if you lift a .elf from one place and try and debug it in another the filesystem paths may not be valid.

Last Edited: Tue. Dec 16, 2014 - 03:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here you are (-h seems to give just the file header, I've done -e which equals -hlS):

 

$ avr-readelf -e build_madam_blue/mumfw.elf
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Atmel AVR 8-bit microcontroller
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          52 (bytes into file)
  Start of section headers:          661164 (bytes into file)
  Flags:                             0xea
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         3
  Size of section headers:           40 (bytes)
  Number of section headers:         32
  Section header string table index: 29

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00000000 000094 00d614 00  AX  0   0  2
  [ 2] .rela.text        RELA            00000000 0a1bac 011280 0c     30   1  4
  [ 3] .data             PROGBITS        00802000 00d6a8 0026d0 00  WA  0   0  4
  [ 4] .rela.data        RELA            00000000 0b2e2c 001128 0c     30   3  4
  [ 5] .bss              NOBITS          008046d0 00fd78 001514 00  WA  0   0  1
  [ 6] .noinit           NOBITS          00805be4 00fd78 000409 00  WA  0   0  1
  [ 7] .stab             PROGBITS        00000000 00fd78 0006e4 0c      9   0  4
  [ 8] .rela.stab        RELA            00000000 0b3f54 0000a8 0c     30   7  4
  [ 9] .stabstr          STRTAB          00000000 01045c 000067 00      0   0  1
  [10] .comment          PROGBITS        00000000 0104c3 00005c 01  MS  0   0  1
  [11] .debug_aranges    PROGBITS        00000000 01051f 001368 00      0   0  1
  [12] .rela.debug_arang RELA            00000000 0b3ffc 0015fc 0c     30  11  4
  [13] .debug_pubnames   PROGBITS        00000000 011887 00f85e 00      0   0  1
  [14] .rela.debug_pubna RELA            00000000 0b55f8 000390 0c     30  13  4
  [15] .debug_info       PROGBITS        00000000 0210e5 037862 00      0   0  1
  [16] .rela.debug_info  RELA            00000000 0b5988 0307b0 0c     30  15  4
  [17] .debug_abbrev     PROGBITS        00000000 058947 00b176 00      0   0  1
  [18] .debug_line       PROGBITS        00000000 063abd 00caa6 00      0   0  1
  [19] .rela.debug_line  RELA            00000000 0e6138 00126c 0c     30  18  4
  [20] .debug_frame      PROGBITS        00000000 070564 00413c 00      0   0  4
  [21] .rela.debug_frame RELA            00000000 0e73a4 0024d8 0c     30  20  4
  [22] .debug_str        PROGBITS        00000000 0746a0 0093dc 01  MS  0   0  1
  [23] .debug_loc        PROGBITS        00000000 07da7c 018c68 00      0   0  1
  [24] .rela.debug_loc   RELA            00000000 0e987c 023ce8 0c     30  23  4
  [25] .debug_pubtypes   PROGBITS        00000000 0966e4 009af5 00      0   0  1
  [26] .rela.debug_pubty RELA            00000000 10d564 000390 0c     30  25  4
  [27] .debug_ranges     PROGBITS        00000000 0a01d9 0013c8 00      0   0  1
  [28] .rela.debug_range RELA            00000000 10d8f4 002f88 0c     30  27  4
  [29] .shstrtab         STRTAB          00000000 0a15a1 000109 00      0   0  1
  [30] .symtab           SYMTAB          00000000 11087c 006db0 10     31 1028  4
  [31] .strtab           STRTAB          00000000 11762c 0041a3 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000094 0x00000000 0x00000000 0x0d614 0x0d614 R E 0x2
  LOAD           0x00d6a8 0x00802000 0x0000d614 0x026d0 0x026d0 RW  0x4
  LOAD           0x00fd78 0x008046d0 0x008046d0 0x00000 0x0191d RW  0x1

 Section to Segment mapping:
  Segment Sections...
   00     .text
   01     .data
   02     .bss .noinit

 

David F.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It just says this after selecting the CPU type:

 

Timestamp:    2014-12-16 15:48:50.572
Severity:        ERROR
ComponentId:    15000
StatusCode:    0

Could not create project associated with the object file that was opened for debugging. None of the available object file readers can read the specified object file. Please check the format of the object file

David F.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Then it's not the content as both files appear to have an identical format of AVR Elf/Dwarf info in them.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, that is why I'm so puzzled... Erro message doesn't help much, and seems that Atmel does not give support for its own tools, other than what people get to know in these forums.

David F.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there some reason you cannot simply add the files to an AS6 project and build there? You are bound to be able to debug that.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, this would allow me to build it in the usual way and debug separately.

As my make files are a bit clever using bash, I envisage problems if I try to build in Windows... I've installed the MSYS extension and will give it a try, but this is working a lot around the problem.

 

I've checked that both readelf and gdb in windows installed by Atmel Studio read properly my elf file and load the symbols... so this seems like a question for Atmel...

 

David F.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

so this seems like a question for Atmel...

I agree - as Morten from Atmel no longer seems to frequent these forums I think you are going to need to open a support ticket direct with Atmel.

 

One last grasp at straw - lately AS6 has gained the option to switch the debugger from Atmel to avr-gdb - does it make a difference if you try that?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not sure, the reason why I'm using AS6 is because I'm at a point in debugging where having watchpoints becomes very useful, and as avarice does not support them yet, I'm using the standard Atmel windows tools.

 

If avr-gdb that comes with AS6 supports direc debugging through JTAGICE3, it will, as I can already load the elf in avr-gdb in windows. Do you know what is the target command in windows avr-gdb to connect to a target with JTAGICE3?

David F.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you know what is the target command in windows avr-gdb to connect to a target with JTAGICE3?

Nope, all that is hidden behind the IDE. I just know they added the option to drive their own tools with avr-gdb rather than their proprietary debugger.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Either open a support request or, if possible, mail me the elf file (strip it of anything you don't want me to see :)). My mail should be obvious (append @atmel.com to my profile name). 

 

Interesting that studio reports that no readers are compliant. This basically means that that magic bytes are wrong, which it looks like they aren't. I will have to debug it to find out the underlying reason if possible.

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

Last Edited: Tue. Dec 16, 2014 - 10:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Morten,

 

I've tried to send the elf, but seems there are problems with IT policy, so I've created a support case 00009569, and put you as CC on it. The file is attached to that case.

Let me know what you find.

 

Regards
 

David F.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, just ran i through my dev version, and it worked like a charm. I'll have to dig up the release version and see if the problem is there...

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, can't see any issues in 1502 either.

 

Could you enable diagnostic logs, and reproduce the issue?

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

General output:

13:18:29: [INFO] Changing default Tool settings
13:20:36: [ERROR] Could not create project associated with the object file that was opened for debugging. None of the available object file readers can read the specified object file. Please check the format of the object file

 

Backend agent output:

01 17 48 432: msg send(a8):R 2
01 18 30 011: str recv(a8):C 3 Stream setLogBits 4294967295
01 18 30 011: msg send(a8):R 3
01 20 36 857: msg recv(a8):C 4 LineNumbers getObjectFileInfo "\\\\ukfiler3\\df\\src_sf\\firmwareavr8\\mum\\build_madam_blue\\mumfw.elf"
01 20 36 969: msg send(a8):R 4  []

 

 

Attachment(s): 

David F.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Aha, the file can't be on a UNC path (\\). You should map it to a drive.

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Knew you would scold me for that! But I tried it too and did not work either:

 

General output:

3:33:45: [INFO] Added ToolInfo: JTAGICE mkII
13:33:45: [INFO] Added ToolInfo: mEDBG
13:33:45: [INFO] Added ToolInfo: QT600
13:33:45: [INFO] Added ToolInfo: SAM-ICE
13:33:45: [INFO] Added ToolInfo: Simulator
13:33:45: [INFO] Added ToolInfo: STK500
13:33:45: [INFO] Added ToolInfo: STK600
13:33:53: [INFO] Initializing help package Atmel.VsIde.AvrStudio.Branding.HelpAbout.HelpAboutPackage
13:37:53: [ERROR] Could not create project associated with the object file that was opened for debugging. None of the available object file readers can read the specified object file. Please check the format of the object file

 

Backend agent output:

13:33:41: [INFO] Starting local Backend Agent atbackend.exe 127.0.0.1:0
13:33:41: [INFO] Process: C:\Program Files (x86)\Atmel\Atmel Studio 6.2\atbackend\atbackend.exe /connection-port=55311
13:33:51: [INFO] Connecting to backend agent atbackend.exe(pid:5048) 127.0.0.1:55311
13:33:51: [INFO] Connected to backend at 127.0.0.1:55311
01 33 52 553: msg send(a8):R 1
01 33 52 563: msg recv(a8):E Locator peerAdded {"Port":"55311","Host":"127.0.0.1","ID":"LocalHIL0","Name":"Local HIL","OSName":"Windows","TransportName":"TCP"}
01 35 07 097: msg recv(a8):C 2 Tool pollForTools true
01 35 07 106: msg send(a8):R 2
01 35 07 464: msg send(a8):E Tool attachedToolsChanged [{"ToolType":"com.atmel.avrdbg.tool.simulator","ConnectionType":"","ConnectionProperties":{}},{"ToolType":"com.atmel.avrdbg.tool.jtagicemk3","ConnectionType":"com.atmel.avrdbg.connection.jungousb","ConnectionProperties":{"Type":"com.atmel.avrdbg.connection.jungousb","SerialNumber":"J30200026338","UsbVendorId":1003,"UsbProductId":8464}}]
01 37 07 274: msg recv(a8):C 3 Tool pollForTools false
01 37 07 518: msg send(a8):R 3
01 37 53 083: msg recv(a8):C 4 LineNumbers getObjectFileInfo "Z:\\src_sf\\firmwareavr8\\mum\\build_madam_blue\\mumfw.elf"
01 37 53 236: msg send(a8):R 4  []

 

Attachment(s): 

David F.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can you program the elf file using the programming dialog? It might be issues with parsing the dwarf info, since the source links are encoded as absolute paths... (i only checked programming, not debugging)
 

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

Last Edited: Wed. Dec 17, 2014 - 01:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Probably, but it is not programming what I'm after, but debugging. The file is already programmed in flash.

 

I thought that you could correct the file mapping after it creates the project...

David F.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I see now that the wizard fails when it is enumerating source files... So at leas I can reproduce it.
 

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good, good.

David F.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, this is a bug (AVRSV-6011).

 

When we ask for source file information to start the remap process, then there's a check in studio to see if we got 0 files from the elf parser. If so, then we just abort with the assumption that the elf is invalid or there's a communication issue.

 

It looks like there's an issue with the dwarf info causing this (maybe dwarf2-strict? the dwarf source reference parser ends out with 0 file references). However, I have filed a bug to allow this case to be debugged, which will fall back to disassembly.

 

However, I guess you haven't stripped the elf? Could you try changing the dwarf version and see if it helps?

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I see, if the file mapping is not right from the start, then this might assume the elf is invalid just because the surce file paths have not been fixed yet...

 

I'm currently using -gdwarf-2 and NOT using -gdwarf-strict.

 

Which version do you want me to use? And strict on or off?

David F.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try dwarf2 strict, although I though that we also supported dwarf2...

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No changes with -gstrict-dwarf -gdwarf-2:

 

General output:

16:35:32: [INFO] Found Toolchain Factory Atmel.VsIde.AvrStudio.Extensions.AVRGCC.AVRGCCToolchainFactory:
16:35:32: [INFO] Found Creatable Toolchain Name com.Atmel.AVRGCC32.C from Factory Atmel.VsIde.AvrStudio.Extensions.AVRGCC.AVRGCCToolchainFactory
16:35:32: [INFO] Found Creatable Toolchain Name com.Atmel.AVRGCC32.CPP from Factory Atmel.VsIde.AvrStudio.Extensions.AVRGCC.AVRGCCToolchainFactory
16:35:32: [INFO] Found Creatable Toolchain Name com.Atmel.AVRGCC8.C from Factory Atmel.VsIde.AvrStudio.Extensions.AVRGCC.AVRGCCToolchainFactory
16:35:32: [INFO] Found Creatable Toolchain Name com.Atmel.AVRGCC8.CPP from Factory Atmel.VsIde.AvrStudio.Extensions.AVRGCC.AVRGCCToolchainFactory
16:35:32: [INFO] Found Toolchain Factory Atmel.VsIde.AtmelStudio.Extensions.ARMGCC.ArmGcc32BitToolchainProvider:
16:35:32: [INFO] Found Creatable Toolchain Name com.Atmel.ARMGCC.C from Factory Atmel.VsIde.AtmelStudio.Extensions.ARMGCC.ArmGcc32BitToolchainProvider
16:35:32: [INFO] Found Creatable Toolchain Name com.Atmel.ARMGCC.CPP from Factory Atmel.VsIde.AtmelStudio.Extensions.ARMGCC.ArmGcc32BitToolchainProvider
16:35:32: [INFO] Found Toolchain Factory Atmel.VsIde.AvrStudio.Extensions.AvrAssembler.Toolchain.AssemblerToolchainsProvider:
16:35:32: [INFO] Found Creatable Toolchain Name com.Atmel.AVRAssembler from Factory Atmel.VsIde.AvrStudio.Extensions.AvrAssembler.Toolchain.AssemblerToolchainsProvider
16:35:33: [INFO] Added ToolInfo: Atmel-ICE
16:35:33: [INFO] Added ToolInfo: AVR Dragon
16:35:35: [INFO] Added ToolInfo: AVRISP mkII
16:35:35: [INFO] Added ToolInfo: AVR ONE!
16:35:35: [INFO] Added ToolInfo: EDBG
16:35:35: [INFO] Added ToolInfo: J-Link
16:35:35: [INFO] Added ToolInfo: J-Link ARM-Pro
16:35:35: [INFO] Added ToolInfo: J-Link Ultra
16:35:35: [INFO] Added ToolInfo: JTAGICE3
16:35:35: [INFO] Added ToolInfo: JTAGICE3
16:35:35: [INFO] Added ToolInfo: JTAGICE mkII
16:35:35: [INFO] Added ToolInfo: mEDBG
16:35:35: [INFO] Added ToolInfo: QT600
16:35:36: [INFO] Added ToolInfo: SAM-ICE
16:35:36: [INFO] Added ToolInfo: Simulator
16:35:36: [INFO] Added ToolInfo: STK500
16:35:36: [INFO] Added ToolInfo: STK600
16:35:41: [INFO] Initializing help package Atmel.VsIde.AvrStudio.Branding.HelpAbout.HelpAboutPackage
16:37:09: [ERROR] Could not create project associated with the object file that was opened for debugging. None of the available object file readers can read the specified object file. Please check the format of the object file

 

 

Backend agent output:

16:35:32: [INFO] Starting local Backend Agent atbackend.exe 127.0.0.1:0
16:35:32: [INFO] Process: C:\Program Files (x86)\Atmel\Atmel Studio 6.2\atbackend\atbackend.exe /connection-port=55492
16:35:41: [INFO] Connecting to backend agent atbackend.exe(pid:4188) 127.0.0.1:55492
16:35:41: [INFO] Connected to backend at 127.0.0.1:55492
04 35 41 558: msg send(a8):R 1
04 35 41 563: msg recv(a8):E Locator peerAdded {"Port":"55492","Host":"127.0.0.1","ID":"LocalHIL0","Name":"Local HIL","OSName":"Windows","TransportName":"TCP"}
04 37 09 686: msg recv(a8):C 2 LineNumbers getObjectFileInfo "Z:\\src_sf\\firmwareavr8\\mum\\build_madam_blue\\mumfw.elf"
04 37 09 722: msg send(a8):R 2  []

 

Attachment(s): 

David F.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So, I got a couple of minutes to debug this, and our version of libdwarf fails to parse the second cb (where dwarf version etc are stored). Since this fails, we assume that the dwarf info is corrupt and we won't resolve anything else (since libdwarf can't continue). Not really sure about any timeline to get any deeper into this, with holidays and such...

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm on holidays too, so don't worry, have a merry crhistmas and happy new year, and we can talk about it on january the 12th.

David F.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Back from holidays... ready when you are.

David F.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I haven't made any progress on this unfortunately. I'm holding off since we have in our plans to update the version of libdwarf that we use to parse this info (the problem comes from our current version of libdwarf).

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, no problem, just let me know when that happens.

David F.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How are things? Do you have any idea about when there will be a fix for this?

David F.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No news :(

 

To be frank this is no high priority issue (since it is out of what we support), so fixing this will most probably be a side effect unfortunately.

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, as it is a feature accessible on the GUI, I was expecting that it should work, or be fixed, but I understand that you might have a bigger fish to fry.

 

David F.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello, where can I find a guide of how to debug a file that I generated from a Linux setup?

Is there a way to load the .elf or some other generated file under Windows and then run the debug with ATMEL-ICE?

This topic seems to be on this theme but it remained without any answer ...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What happens when you do load the Linux ELF for debugging. If it's anything like the VS2015 that AS7 is based on, when it finds a reference to a source file it cannot find it will actually throw a file browser asking you to identify where the .c is located. (obviously you need to copy/share a copy of the sources from Linux to Windows)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok thanks. Then I guess I will give it a try to see if it asks for the files. Can I break the uC is something is wrong during the debug?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually I tried today and it doesn't ask for any files when I load the .elf, and there is no option to add files or something.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Then it seems likely it wasn't built with -g

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I built it with -g2 and -DDEBUG, same as Atmel Studio 7 does for the elf that actually works.

Of course the rest of the options are not the same, and this is Linux.

I guess I could try to build in Linux a simple main.c that blinks a LED and then to try and load the .elf to see where really the problem is

I read the elf generated from Linux with readelf and the symbol information seems to be there

Last Edited: Tue. Jul 16, 2019 - 07:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tried to compile an empty main.c and then read the elf:

Loaded it in ATMEL STUDIO7 but still nothing, does not ask for source files, either I am doing something really wrong, either ATMEL STUDIO doesn't like Linux generated .elf files ...

I generated the elf with:

 

avr-g++ -g -mmcu=at90can128 -c main.c

avr-g++ -g -mmcu=at90can128 -o main.elf main.o

avr-readelf -hlS main.elf
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Atmel AVR 8-bit microcontroller
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          52 (bytes into file)
  Start of section headers:          13656 (bytes into file)
  Flags:                             0x33, avr:51
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         2
  Size of section headers:           40 (bytes)
  Number of section headers:         14
  Section header string table index: 11

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .data             PROGBITS        00800100 00015a 000000 00  WA  0   0  1
  [ 2] .text             PROGBITS        00000000 000074 0000e6 00  AX  0   0  2
  [ 3] .stab             PROGBITS        00000000 00015c 000510 0c      4   0  4
  [ 4] .stabstr          STRTAB          00000000 00066c 000dab 00      0   0  1
  [ 5] .comment          PROGBITS        00000000 001417 000011 01  MS  0   0  1
  [ 6] .note.gnu.avr.dev NOTE            00000000 001428 000040 00      0   0  4
  [ 7] .debug_info       PROGBITS        00000000 001468 000a2d 00      0   0  1
  [ 8] .debug_abbrev     PROGBITS        00000000 001e95 0009a0 00      0   0  1
  [ 9] .debug_line       PROGBITS        00000000 002835 00001a 00      0   0  1
  [10] .debug_str        PROGBITS        00000000 00284f 00039f 00      0   0  1
  [11] .shstrtab         STRTAB          00000000 0034cd 000089 00      0   0  1
  [12] .symtab           SYMTAB          00000000 002bf0 000540 10     13  20  4
  [13] .strtab           STRTAB          00000000 003130 00039d 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000074 0x00000000 0x00000000 0x000e6 0x000e6 R E 0x2
  LOAD           0x00015a 0x00800100 0x000000e6 0x00000 0x00000 RW  0x1

 Section to Segment mapping:
  Segment Sections...
   00     .text
   01     .data

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK so post the ELF.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok here is the .elf

 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's very curious. If I use objdump -g on that then for debug lines it says:

aw dump of debug contents of section .debug_line:

  Offset:                      0x0
  Length:                      22
  DWARF Version:               2
  Prologue Length:             16
  Minimum Instruction Length:  2
  Initial value of 'is_stmt':  1
  Line Base:                   -5
  Line Range:                  14
  Opcode Base:                 10

 Opcodes:
  Opcode 1 has 0 args
  Opcode 2 has 1 args
  Opcode 3 has 1 args
  Opcode 4 has 1 args
  Opcode 5 has 1 args
  Opcode 6 has 0 args
  Opcode 7 has 0 args
  Opcode 8 has 0 args
  Opcode 9 has 1 args

 The Directory Table is empty.

 The File Name Table is empty.

 No Line Number Statements.

Yet if I do the same with a program of just a few lines that I built (in AS7):

aw dump of debug contents of section .debug_line:

  Offset:                      0x0
  Length:                      303
  DWARF Version:               2
  Prologue Length:             44
  Minimum Instruction Length:  2
  Initial value of 'is_stmt':  1
  Line Base:                   -5
  Line Range:                  14
  Opcode Base:                 10

 Opcodes:
  Opcode 1 has 0 args
  Opcode 2 has 1 args
  Opcode 3 has 1 args
  Opcode 4 has 1 args
  Opcode 5 has 1 args
  Opcode 6 has 0 args
  Opcode 7 has 0 args
  Opcode 8 has 0 args
  Opcode 9 has 1 args

 The Directory Table (offset 0x18):
  1     ../../../../crt1

 The File Name Table (offset 0x2a):
  Entry Dir     Time    Size    Name
  1     1       0       0       gcrt1.S

 Line Number Statements:
  [0x00000036]  Extended opcode 2: set Address to 0x0
  [0x0000003d]  Advance Line by 60 to 61
  [0x0000003f]  Copy
  [0x00000040]  Advance Line by 2 to 63
  [0x00000042]  Advance PC by fixed size amount 4 to 0x4
  [0x00000045]  Copy
  [0x00000046]  Advance Line by 1 to 64
  [0x00000048]  Advance PC by fixed size amount 4 to 0x8
  [0x0000004b]  Copy
  [0x0000004c]  Advance Line by 1 to 65
  [0x0000004e]  Advance PC by fixed size amount 4 to 0xc
  [0x00000051]  Copy
  [0x00000052]  Advance Line by 1 to 66
  [0x00000054]  Advance PC by fixed size amount 4 to 0x10
  [0x00000057]  Copy
  [0x00000058]  Advance Line by 1 to 67
  [0x0000005a]  Advance PC by fixed size amount 4 to 0x14
  [0x0000005d]  Copy
  [0x0000005e]  Advance Line by 1 to 68
  [0x00000060]  Advance PC by fixed size amount 4 to 0x18
  [0x00000063]  Copy
  [0x00000064]  Advance Line by 1 to 69
  [0x00000066]  Advance PC by fixed size amount 4 to 0x1c
  [0x00000069]  Copy
  [0x0000006a]  Advance Line by 1 to 70
  [0x0000006c]  Advance PC by fixed size amount 4 to 0x20
  [0x0000006f]  Copy
  [0x00000070]  Advance Line by 1 to 71
  [0x00000072]  Advance PC by fixed size amount 4 to 0x24
  [0x00000075]  Copy
  [0x00000076]  Advance Line by 1 to 72
  [0x00000078]  Advance PC by fixed size amount 4 to 0x28
  [0x0000007b]  Copy
  [0x0000007c]  Advance Line by 1 to 73
  [0x0000007e]  Advance PC by fixed size amount 4 to 0x2c
  [0x00000081]  Copy
  [0x00000082]  Advance Line by 1 to 74
  [0x00000084]  Advance PC by fixed size amount 4 to 0x30
  [0x00000087]  Copy
  [0x00000088]  Advance Line by 1 to 75
  [0x0000008a]  Advance PC by fixed size amount 4 to 0x34
  [0x0000008d]  Copy
  [0x0000008e]  Advance Line by 1 to 76
  [0x00000090]  Advance PC by fixed size amount 4 to 0x38
  [0x00000093]  Copy
  [0x00000094]  Advance Line by 1 to 77
  [0x00000096]  Advance PC by fixed size amount 4 to 0x3c
  [0x00000099]  Copy
  [0x0000009a]  Advance Line by 1 to 78
  [0x0000009c]  Advance PC by fixed size amount 4 to 0x40
  [0x0000009f]  Copy
  [0x000000a0]  Advance Line by 1 to 79
  [0x000000a2]  Advance PC by fixed size amount 4 to 0x44
  [0x000000a5]  Copy
  [0x000000a6]  Advance Line by 1 to 80
  [0x000000a8]  Advance PC by fixed size amount 4 to 0x48
  [0x000000ab]  Copy
  [0x000000ac]  Advance Line by 1 to 81
  [0x000000ae]  Advance PC by fixed size amount 4 to 0x4c
  [0x000000b1]  Copy
  [0x000000b2]  Advance Line by 1 to 82
  [0x000000b4]  Advance PC by fixed size amount 4 to 0x50
  [0x000000b7]  Copy
  [0x000000b8]  Advance Line by 1 to 83
  [0x000000ba]  Advance PC by fixed size amount 4 to 0x54
  [0x000000bd]  Copy
  [0x000000be]  Advance Line by 1 to 84
  [0x000000c0]  Advance PC by fixed size amount 4 to 0x58
  [0x000000c3]  Copy
  [0x000000c4]  Advance Line by 1 to 85
  [0x000000c6]  Advance PC by fixed size amount 4 to 0x5c
  [0x000000c9]  Copy
  [0x000000ca]  Advance Line by 1 to 86
  [0x000000cc]  Advance PC by fixed size amount 4 to 0x60
  [0x000000cf]  Copy
  [0x000000d0]  Advance Line by 1 to 87
  [0x000000d2]  Advance PC by fixed size amount 4 to 0x64
  [0x000000d5]  Copy
  [0x000000d6]  Advance PC by fixed size amount 4 to 0x68
  [0x000000d9]  Extended opcode 1: End of Sequence

  [0x000000dc]  Extended opcode 2: set Address to 0x7c
  [0x000000e3]  Advance Line by 204 to 205
  [0x000000e6]  Copy
  [0x000000e7]  Advance PC by fixed size amount 4 to 0x80
  [0x000000ea]  Extended opcode 1: End of Sequence

  [0x000000ed]  Extended opcode 2: set Address to 0x68
  [0x000000f4]  Advance Line by 225 to 226
  [0x000000f7]  Copy
  [0x000000f8]  Advance Line by 1 to 227
  [0x000000fa]  Advance PC by fixed size amount 2 to 0x6a
  [0x000000fd]  Copy
  [0x000000fe]  Advance Line by 1 to 228
  [0x00000100]  Advance PC by fixed size amount 2 to 0x6c
  [0x00000103]  Copy
  [0x00000104]  Advance Line by 9 to 237
  [0x00000106]  Advance PC by fixed size amount 2 to 0x6e
  [0x00000109]  Copy
  [0x0000010a]  Advance Line by 1 to 238
  [0x0000010c]  Advance PC by fixed size amount 2 to 0x70
  [0x0000010f]  Copy
  [0x00000110]  Advance Line by 2 to 240
  [0x00000112]  Advance PC by fixed size amount 2 to 0x72
  [0x00000115]  Copy
  [0x00000116]  Advance PC by fixed size amount 2 to 0x74
  [0x00000119]  Extended opcode 1: End of Sequence

  [0x0000011c]  Extended opcode 2: set Address to 0x74
  [0x00000123]  Advance Line by 309 to 310
  [0x00000126]  Copy
  [0x00000127]  Advance Line by 1 to 311
  [0x00000129]  Advance PC by fixed size amount 4 to 0x78
  [0x0000012c]  Copy
  [0x0000012d]  Advance PC by fixed size amount 4 to 0x7c
  [0x00000130]  Extended opcode 1: End of Sequence

  Offset:                      0x133
  Length:                      187
  DWARF Version:               2
  Prologue Length:             129
  Minimum Instruction Length:  2
  Initial value of 'is_stmt':  1
  Line Base:                   -5
  Line Range:                  14
  Opcode Base:                 10

 Opcodes:
  Opcode 1 has 0 args
  Opcode 2 has 1 args
  Opcode 3 has 1 args
  Opcode 4 has 1 args
  Opcode 5 has 1 args
  Opcode 6 has 0 args
  Opcode 7 has 0 args
  Opcode 8 has 0 args
  Opcode 9 has 1 args

 The Directory Table (offset 0x14b):
  1     ../.
  2     c:\program files (x86)\atmel\studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include

 The File Name Table (offset 0x1a7):
  Entry Dir     Time    Size    Name
  1     1       0       0       main.c
  2     2       0       0       stdint.h

 Line Number Statements:
  [0x000001be]  Extended opcode 2: set Address to 0x80
  [0x000001c5]  Special opcode 9: advance Address by 0 to 0x80 and Line by 4 to 5
  [0x000001c6]  Advance Line by 0 to 5
  [0x000001c8]  Advance PC by fixed size amount 0 to 0x80
  [0x000001cb]  Copy
  [0x000001cc]  Extended opcode 4: set Discriminator to 3
  [0x000001d0]  Advance Line by 4 to 9
  [0x000001d2]  Advance PC by fixed size amount 8 to 0x88
  [0x000001d5]  Copy
  [0x000001d6]  Extended opcode 4: set Discriminator to 3
  [0x000001da]  Advance Line by -1 to 8
  [0x000001dc]  Advance PC by fixed size amount 8 to 0x90
  [0x000001df]  Copy
  [0x000001e0]  Advance Line by 3 to 11
  [0x000001e2]  Advance PC by fixed size amount 2 to 0x92
  [0x000001e5]  Copy
  [0x000001e6]  Advance Line by 1 to 12
  [0x000001e8]  Advance PC by fixed size amount 2 to 0x94
  [0x000001eb]  Copy
  [0x000001ec]  Advance PC by fixed size amount 6 to 0x9a
  [0x000001ef]  Extended opcode 1: End of Sequence

That last section that mentions code addresses 0x80 .. 0x9A relates to this:

00000080 <main>:
#include <avr/io.h>
#include <avr/fuse.h>

int main(void)
{
  80:   80 ea           ldi     r24, 0xA0       ; 160
  82:   96 e8           ldi     r25, 0x86       ; 134
  84:   a1 e0           ldi     r26, 0x01       ; 1
  86:   b0 e0           ldi     r27, 0x00       ; 0
        uint32_t n;

        for (n = 0; n < 100000; n++) {
                PINB |= (1 << 0);
  88:   18 9a           sbi     0x03, 0 ; 3
  8a:   01 97           sbiw    r24, 0x01       ; 1
  8c:   a1 09           sbc     r26, r1
  8e:   b1 09           sbc     r27, r1

int main(void)
{
        uint32_t n;

        for (n = 0; n < 100000; n++) {
  90:   d9 f7           brne    .-10            ; 0x88 <main+0x8>
                PINB |= (1 << 0);
        }
        asm("nop");
  92:   00 00           nop
}
  94:   80 e0           ldi     r24, 0x00       ; 0
  96:   90 e0           ldi     r25, 0x00       ; 0
  98:   08 95           ret

0000009a <_exit>:
  9a:   f8 94           cli

0000009c <__stop_program>:
  9c:   ff cf           rjmp    .-2             ; 0x9c <__stop_program>

which is the results of objdump -S. The source (main.c) it refers to is this:

D:\test\test>cat -n main.c
     1  #include <avr/io.h>
     2  #include <avr/fuse.h>
     3
     4  int main(void)
     5  {
     6          uint32_t n;
     7
     8          for (n = 0; n < 100000; n++) {
     9                  PINB |= (1 << 0);
    10          }
    11          asm("nop");
    12  }

 

Off hand I have no idea how your  own build has failed to make any entries in the .debug_line section but that seems to the the core of the problem.

 

Life will be much easier when you simply move the building to the same place you intend to do the debugging!

Last Edited: Tue. Jul 16, 2019 - 10:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the support.

Did you build also with the same instructions that I used?

Maybe I used some wrong instructions for generating the elf file, or the compiler is missing the part that generates the debug sections correctly?

 

So just to clear this up, when the objdump -g returns similar to what you posted then probably also the .elf file will be read correctly in AS7.

Unfortunately the setup that I use is too complex to move it to AS7, so I guess I must find a way to convince my compiler to generate the right .elf that will be accepted by AS7.

Or configure gdb in Linux to work with ATMEL ICE, but as the .elf is still incomplete probably I will also not have access to the sources when debugging.

 

avr-g++ -g -mmcu=at90can128 -c main.c

avr-g++ -g -mmcu=at90can128 -o main.elf main.o

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
avr-g++ -g -mmcu=at90can128 -o main.elf main.o

When God invented Linux you would just say:

cc main.c

and execute the result with

a.out

Cross-compiling for a foreign Harvard architecture is not so simple.

You need to use a complex set of switches and arguments.

 

You have never explained WHY you build in Linux.

 

Whatever you build in Linux can be built exactly the same in Windoze or Mac.

 

You can control the build with your own Makefile

Or you can add the source files to a GUI.    Add any necessary Symbols or Properties.

 

As I have said several times.    I debug ARM object files that were generated by the Arduino IDE.

 

And in the old days I would debug COFF files generated by Codevision.

 

In principle,   you can build in Linux from source files on a Windows filesytem.

Then use AS7.0 to debug the resultant ELF.    Browse to locate a source file.    

 

David.

Last Edited: Tue. Jul 16, 2019 - 12:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is what happens when you split the discussion across multiple threads. In the other thread where you are discussing this I previously identified that AS7 builds using the following command line options:

-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)" 

The key thing in that is "-g2"

 

For more details see:

 

https://gcc.gnu.org/onlinedocs/gcc-5.5.0/gcc/Debugging-Options.html#Debugging-Options

Last Edited: Tue. Jul 16, 2019 - 12:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello, I am working with Linux just a few months, this is the setup I must use and I can't change it.

 

I also tried avr-c++ with -g2, avr-g++ with -g2 but still the Tables are empty

 

You tried in your Linux and it works?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is nothing to be embarrassed about.

If your employer or teacher wants you to use Linux,  just say so.

 

Explain your position.    Readers can give you practical help.

 

I have no intention of installing Linux myself.

Cliff (and others) use Linux by default.

 

Your trivial avr-g++ command will be ok for a Blinky but will never work with a complex program.

 

Either use a pre-written Makefile or use a respected IDE.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
Cliff (and others) use Linux by default.
Cliff *used* to use Linux. Everything I do (professionally) these days is in Windows in fact so I don't bother with a Linux VM at the moment. Howeever in my stack of old laptops here I have some with a VM set up so let me see if I can run an experiment there..

 

PS just realised that above you are invoking the C++ compiler to compile C. While it will work I kind of wonder why?

Last Edited: Tue. Jul 16, 2019 - 01:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually the setup that I use for the build is super complex (for me), but for obvious reasons I can't post the file here. I just need to do make all to build all the files.

The problem is that I need to debug the .elf file and for this the easiest solution seems to be Windows Atmel Studio for the ATMEL ICE.

I am totally noob related to Linux, all I can do is ls, cd, and the git operations but this was enough for developing until now.

I am trying to learn but not having the basics makes it really difficult to understand, and this is not my main focus.

Unfortunately I have a nasty bug that I can't solve just by trial/error as it is related to CAN.

I already tried to execute in parallel the same instructions in Linux and Windows for generating the .elf, with the same parameters the Linux .elf has no file and directory inside, but the Windows .elf has it.

I even saved the objdump -g to .txt files and compared them in order to understand what is the difference.

 

I really can't say what is different, probably different avr configuration for Linux?

Some other small details that generate this difference? I really can't tell, I already spent 2 days on this topic, I can debug the .elf file in AS in Assembler mode at least and set some Data Read/Write Breakpoints, read the Registers which helped me pinpoint where the problem may be, but without some source code debugging I think it is very difficult to go further.

For me also it doesn't make any sense that the same instruction generated different outputs in Linux and Windows ... but how to solve it?

 

We use cpp for the development, for me it was also strange, as until now I only used ANSI C for embedded, but seems to work without problems ... in Atmel Studio I also compiled the file as C++ and the elf was ok.

Last Edited: Tue. Jul 16, 2019 - 01:33 PM

Pages