Hello all Im new to using Atmel devices and AVR studio. We have built a project with avr-gcc and Im using AVR studio version 4.08 to debug. the device is the ATMEGA162. My problem is that we have an array of structures declared in C and when I place a watch in the watch window the SRAM address is given as 0x051E which is outside the SRAM space of the device which has 1k of SRAM starting at 0x0100. How do I debug this array? Thanks for any assistance in advance. Denis
AVR studio Watch window giving unbelievable result.
Started by ●August 16, 2004
Reply by ●August 16, 20042004-08-16
>My problem is that we have an array of structures declared in C and >when I place a watch in the watch window the SRAM address is given as >0x051E which is outside the SRAM space of the device which has 1k of SRAM >starting at 0x0100 > >How do I debug this array?>Well, first I'd recommend you get the latest AVR Studio (version 4.09). Just in case there's some weird bug that was in 4.08 that could be causing this. It might not be your watch window that is giving the unbelievable result. I'm sure whatever linker you are using has some switch or option that allows you to generate a map file. This shows what memory locations have been assigned to parts of your program. It could be that you've told the linker that RAM starts at some other address. Or perhaps you are using more RAM than allowable.
Reply by ●August 16, 20042004-08-16
> Im new to using Atmel devices and AVR studio. > We have built a project with avr-gcc and Im using AVR studio > version 4.08 to debug. the device is the ATMEGA162. > > My problem is that we have an array of structures declared in C and when > I place a watch in the watch window the SRAM address is given as 0x051E > which is outside the SRAM space of the device which has 1k of SRAMstarting at 0x0100.> > How do I debug this array? > > Thanks for any assistance in advance. > > DenisRemember that the ATmega162 has an external bus capability. One thing to check for is that you have not a link file which allows data to be in external memory. Then the array can go there even if there is no memory in your system. AVR Studio 4.08 does not support gcc-avr very well. The object file formats get converted and symbolic info is lost in the process. --Upgrade to AVR Studio 4.09. Apply the new patch that reads ELF/DWARF. This it is available on www.atmel.com and/or www.avrfreaks.net Get the latest WinAVR with ELF/DWARF support (avrfreaks). Hopefully things should improve... AVR Studio 4.10 should have the ELF/DWARF support inside without any need for patching. Have not tried it myself yet.... -- Best Regards Ulf Samuelsson ulf@a-t-m-e-l.com This is my personal opinion which may (or may not) be shared by my employer Atmel Nordic AB
Reply by ●August 17, 20042004-08-17
Hi Guys Thanks for the suggestions. I just love reading .map files. Still if thats where the answer is. I have included a section of the .map file below that is causing me some confusion. I understand the .data and this runs from 0x00800100 to 0x008004FF. After that my device has no external SRAM connected so anything placed after that is not going to be there when the program goes looking. What is .bss? How do I control it? Why is data being automatically placed here? Thanks again for your assistance. Denis P.S. While Im at it. Ulf I understand I should get the AVR studio 4.09 and the patch for ELF/DWARF. What are ELF/DWARF? Is this what is origionally generated before conversion to coff? Also what is WinAVR? ________________________________________________________________________________ .data 0x00800100 0x2ec load address 0x000029ba 0x00800100 PROVIDE (__data_start, .) *(.data) .data 0x00800100 0x10 ../ddd/ddd.o 0x00800100 DTMF_digit_to_digit .data 0x00800110 0x129 ../gcd/gcd.o .data 0x00800239 0x9 ../urt/urt.o .data 0x00800242 0x14 ../ccp/ccp.o 0x00800242 state_ftn_table .data 0x00800256 0x190 ../ccp/telnum.o 0x00800256 Fixed_Telephone_Numbers .data 0x008003e6 0x6 C:\WinAVR\bin\..\lib\gcc-lib\avr\3.3.2\..\..\..\..\avr\lib\avr5\libc.a(malloc.o) 0x008003e8 __malloc_heap_start 0x008003ea __malloc_heap_end 0x008003e6 __malloc_margin *(.gnu.linkonce.d*) 0x008003ec . = ALIGN (0x2) 0x008003ec _edata = . 0x008003ec PROVIDE (__data_end, .) .bss 0x008003ec 0x1f0 0x008003ec PROVIDE (__bss_start, .) *(.bss) .bss 0x008003ec 0x2 ../lmd/lmd.o .bss 0x008003ee 0x2 ../ohd/ohd.o .bss 0x008003f0 0x2 ../tgd/tgd.o .bss 0x008003f2 0xfa ../gcd/gcd.o .bss 0x008004ec 0x2c ../urt/urt.o .bss 0x00800518 0x6 ../evg/evg.o .bss 0x0080051e 0x58 ../tmm/tmm.o .bss 0x00800576 0x4 ../tmm/tmmproc.o .bss 0x0080057a 0x2 ../uip/uip.o .bss 0x0080057c 0x1a ../ccp/ccp.o .bss 0x00800596 0x2c ../printfiod/printfd.o .bss 0x008005c2 0x4 C:\WinAVR\bin\..\lib\gcc-lib\avr\3.3.2\..\..\..\..\avr\lib\avr5\libc.a(malloc.o) *(COMMON) COMMON 0x008005c6 0xc ../ddd/ddd.o 0x0 (size before relaxing) 0x008005c6 DTMF_read_ind 0x008005c7 DTMF_digits 0x008005d1 DTMF_write_ind COMMON 0x008005d2 0x4 ../ccp/ccp.o 0x0 (size before relaxing) 0x008005d2 cpp_call_duration COMMON 0x008005d6 0x6 C:\WinAVR\bin\..\lib\gcc-lib\avr\3.3.2\..\..\..\..\avr\lib\avr5\libc.a(fdevopen.o) 0x0 (size before relaxing) 0x008005d6 __iob 0x008005dc PROVIDE (__bss_end, .) 0x000029ba __data_load_start = LOADADDR (.data) 0x00002ca6 __data_load_end = (__data_load_start + SIZEOF (.data)) .noinit 0x008005dc 0x0 0x008005dc PROVIDE (__noinit_start, .) *(.noinit*) 0x008005dc PROVIDE (__noinit_end, .) 0x008005dc _end = . 0x008005dc PROVIDE (__heap_start, .) .eeprom 0x00810000 0x0 load address 0x00002ca6 *(.eeprom*) 0x00810000 __eeprom_end = . .stab 0x00000000 0x6498 *(.stab) .stab 0x00000000 0x1a4 start.o .stab 0x000001a4 0x690 ../lmd/lmd.o 0x6a8 (size before relaxing) .stab 0x00000834 0x354 ../ddd/ddd.o 0x4b0 (size before relaxing) .stab 0x00000b88 0x300 ../ohd/ohd.o 0x45c (size before relaxing) .stab 0x00000e88 0x5dc ../tgd/tgd.o 0x81c (size before relaxing) .stab 0x00001464 0x186c ../gcd/gcd.o 0x1adc (size before relaxing) .stab 0x00002cd0 0x4f8 ../urt/urt.o 0x690 (size before relaxing) .stab 0x000031c8 0x3fc ../evg/evg.o 0x4c8 (size before relaxing) .stab 0x000035c4 0x714 ../tmm/tmm.o 0x978 (size before relaxing) .stab 0x00003cd8 0x270 ../tmm/tmmproc.o 0x3a8 (size before relaxing) .stab 0x00003f48 0x33c ../proc/proc.o 0x474 (size before relaxing) .stab 0x00004284 0x618 ../uip/uip.o 0x864 (size before relaxing) .stab 0x0000489c 0x1194 ../ccp/ccp.o 0x1464 (size before relaxing) .stab 0x00005a30 0x180 ../ccp/telnum.o 0x228 (size before relaxing) .stab 0x00005bb0 0x450 ../mlm/mlm.o 0x6fc (size before relaxing) .stab 0x00006000 0x498 ../printfiod/printfd.o 0x630 (size before relaxing) "Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote in message news:<NtaUc.16466$qn2.2835@nntpserver.swip.net>...> > Im new to using Atmel devices and AVR studio. > > We have built a project with avr-gcc and Im using AVR studio > > version 4.08 to debug. the device is the ATMEGA162. > > > > My problem is that we have an array of structures declared in C and when > > I place a watch in the watch window the SRAM address is given as 0x051E > > which is outside the SRAM space of the device which has 1k of SRAM > starting at 0x0100. > > > > How do I debug this array? > > > > Thanks for any assistance in advance. > > > > Denis > > Remember that the ATmega162 has an external bus capability. > One thing to check for is that you have not a link file which allows data to > be in external memory. > Then the array can go there even if there is no memory in your system. > > AVR Studio 4.08 does not support gcc-avr very well. > The object file formats get converted and symbolic info is lost in the > process. --Upgrade to AVR Studio 4.09. > Apply the new patch that reads ELF/DWARF. This it is available on > www.atmel.com and/or www.avrfreaks.net > Get the latest WinAVR with ELF/DWARF support (avrfreaks). > Hopefully things should improve... > AVR Studio 4.10 should have the ELF/DWARF support inside without any need > for patching. > > Have not tried it myself yet....
Reply by ●August 17, 20042004-08-17
On 17 Aug 2004 08:57:24 -0700, dgleeson-2@utvinternet.com (Denis Gleeson) wrote:>Hi Guys > >Thanks for the suggestions. >I just love reading .map files. Still if thats where the answer is.Always good for your mental health...> >I have included a section of the .map file below that is causing me >some confusion. > >I understand the .data and this runs from 0x00800100 to 0x008004FF. >After that my device has no external SRAM >connected so anything placed after that is not going to be there when >the program goes looking. > >What is .bss? How do I control it? Why is data being automatically >placed here?BSS is short for "Block Starting with Symbol," which probably doesn't make a lot of sense. But that's OK, it doesn't have to. It is the traditional location of uninitialized data. Just like executable code traditionally goes into "text." For example, given int x; int y = 0; int z = -1; x will be placed in BSS, and z will be placed in data (and initialized). y will most likely (and should) be placed in data as well, since it is explicitly initialized, but it could go in either since it is initialized to zero. BSS is normally zeroed before program execution starts. [...]> .bss 0x008003f0 0x2 ../tgd/tgd.o > .bss 0x008003f2 0xfa ../gcd/gcd.o > .bss 0x008004ec 0x2c ../urt/urt.o > .bss 0x00800518 0x6 ../evg/evg.oIf RAM truly runs from 0x00800100 to 0x008004FF as you state earlier, you just overran it. Regards, -=Dave -- Change is inevitable, progress is not.
Reply by ●August 18, 20042004-08-18
"Denis Gleeson" <dgleeson-2@utvinternet.com> skrev i meddelandet news:184c35f9.0408170757.72544239@posting.google.com...> Hi Guys > > Thanks for the suggestions. > I just love reading .map files. Still if thats where the answer is. > > I have included a section of the .map file below that is causing me > some confusion. > > I understand the .data and this runs from 0x00800100 to 0x008004FF. > After that my device has no external SRAM > connected so anything placed after that is not going to be there when > the program goes looking. > > What is .bss? How do I control it? Why is data being automatically > placed here?.bss is the uninitialized data section .data is the initialized data section .text is the code section Based on this and your map file, I think that data starts at 0x100 but needs to be initialized from the flash. The flash address is 0x000029ba. Maybe AVR Studio assumes this is a data address. (Remember that the AVR is a Harvard Architecture)> > Thanks again for your assistance. > > Denis > > P.S. While Im at it. Ulf I understand I should get the AVR studio 4.09 > and the patch for ELF/DWARF. What are ELF/DWARF? Is this what is > origionally generated before conversion to coff? > Also what is WinAVR?ELF = Extended Link Format DWARF = <please fill in if you know> The object file formats. WinAVR is "the" gcc distribution for AVR> >____________________________________________________________________________ ____> > .data 0x00800100 0x2ec load address 0x000029ba > 0x00800100 PROVIDE (__data_start, .) > *(.data) > .data 0x00800100 0x10 ../ddd/ddd.o > 0x00800100 DTMF_digit_to_digit... not so interesting ....> 0x008005d6 __iob > 0x008005dc PROVIDE (__bss_end, .)+++++++++++++++++++++++++++++++++++++++++> 0x000029ba __data_load_start = LOADADDR > (.data) > 0x00002ca6 __data_load_end = > (__data_load_start + SIZEOF (.data)) >-------------------------------------------------------------- ... code area follows ...> .noinit 0x008005dc 0x0 > 0x008005dc PROVIDE (__noinit_start, .)-- Best Regards Ulf at atmel dot com These comments are intended to be my own opinion and they may, or may not be shared by my employer, Atmel Sweden.
Reply by ●August 18, 20042004-08-18