Forums

AVR studio Watch window giving unbelievable result.

Started by Denis Gleeson August 16, 2004
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
>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.
> 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.... -- 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
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....
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.o
If RAM truly runs from 0x00800100 to 0x008004FF as you state earlier, you just overran it. Regards, -=Dave -- Change is inevitable, progress is not.
"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.
On Wed, 18 Aug 2004 11:20:00 +0200, "Ulf Samuelsson"
<ulf@atmel.dot.com> wrote:

[...]
> >ELF = Extended Link Format >DWARF = <please fill in if you know>
Debug With Arbitrary Record Format Regards, -=Dave -- Change is inevitable, progress is not.