Yahoo Groups archive

AVR-Chat

Index last updated: 2026-04-28 22:41 UTC

Thread

malloc/heap issues?

malloc/heap issues?

2004-10-05 by James Russo

Hello,

    Ok, I give up. Spent the last 4 hours on this problem. I have a ~12k 
application trying to go into a atmega128. I seem to have this problem 
when this one module is loaded in, malloc starts returning large values 
greater then the size of ram. Its like it almost thinks that I have 65k 
of memory installed. Removing the one module seems to solve the 
problem?  I am using a JTAG-ICE to debug the problem.

Here is the avr-size output.

   text       data        bss        dec        hex    filename
  12426        192        846      13464       3498    main.elf

The first address returned should be 192 + 846 + 2 (malloc size).

can someone give me a hint?

Thanks,

-James

Re: [AVR-Chat] malloc/heap issues?

2004-10-05 by James Russo

Replying to my own email... But I found out more information...

If the following statement is included the problem occurs:

char *my_packet_types[]
    = {"unk","ping","pong","unk","unk","ack","nak","eeread","eeresp",
        "alive","eedetailsreq","eedetailsresp","updaterp",
        "esensordata","sensordata","reset"};

I can easily reproduce the problem by just watching the 
__malloc_heap_start variables in either the avr simulator or using the 
jtag-ice on the hardware.  It seems like the DATA is somehow becoming 
corrupt when loading the default values from program memory. That is how 
it works, right? The initialized values are loaded from program memory 
in one of the .init sections.. When the above piece of code is included, 
somehow my sram contains various strings from the AVRStudio like 
"Loading Program Memory", but in double byte format (unicode?). I see 
the same data in the program memory, at the end of the program. So the 
program memory is somehow not getting the right value and this is then 
being copied to SRAM...

In the process of writing this email, I think I found it might be a 
ELF/dwarf-2 problem. It happens with the .elf file in avr studio, but 
not the .hex file from the same build. I was trying to use GDB and 
simulavr to determine if the problem is in avr studio or in the 
elf/dwarf-2 creation, but didn't get anywhere.

I am willing to provide the .hex and .elf file if someone else would be 
willing to take a look at it.

Thanks!

-jr

James Russo wrote:
Show quoted textHide quoted text
> Hello,
>
>     Ok, I give up. Spent the last 4 hours on this problem. I have a ~12k
> application trying to go into a atmega128. I seem to have this problem
> when this one module is loaded in, malloc starts returning large values
> greater then the size of ram. Its like it almost thinks that I have 65k
> of memory installed. Removing the one module seems to solve the
> problem?  I am using a JTAG-ICE to debug the problem.
>
> Here is the avr-size output.
>
>    text       data        bss        dec        hex    filename
>   12426        192        846      13464       3498    main.elf
>
> The first address returned should be 192 + 846 + 2 (malloc size).
>
> can someone give me a hint?
>
> Thanks,
>
> -James
>
> *Yahoo! Groups Sponsor*
> ADVERTISEMENT
> click here 
> <http://us.ard.yahoo.com/SIG=129s2s9n8/M=295196.4901138.6071305.3001176/D=groups/S=1706554205:HM/EXP=1097034954/A=2128215/R=0/SIG=10se96mf6/*http://companion.yahoo.com> 
>
>
>
> ------------------------------------------------------------------------
> *Yahoo! Groups Links*
>
>     * To visit your group on the web, go to:
>       http://groups.yahoo.com/group/AVR-Chat/
>        
>     * To unsubscribe from this group, send an email to:
>       AVR-Chat-unsubscribe@yahoogroups.com
>       <mailto:AVR-Chat-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>

RE: [AVR-Chat] malloc/heap issues?

2004-10-05 by Larry Barello

The latest winavr has the elf/dwarf support.  It is new.  You probably
should direct these questions to the avr-gcc-list (http://avr1.org)  One way
around this is to use the previous versions avr-coff and avr-coff-ext output
formats.  The latter works pretty well with studio 4.xxx allowing most
structs to be displayed.
Show quoted textHide quoted text
-----Original Message-----
From: James Russo [mailto:jr@halo3.net]
Sent: Tuesday, October 05, 2004 6:16 AM
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] malloc/heap issues?



Replying to my own email... But I found out more information...

If the following statement is included the problem occurs:

char *my_packet_types[]
    = {"unk","ping","pong","unk","unk","ack","nak","eeread","eeresp",
        "alive","eedetailsreq","eedetailsresp","updaterp",
        "esensordata","sensordata","reset"};

I can easily reproduce the problem by just watching the
__malloc_heap_start variables in either the avr simulator or using the
jtag-ice on the hardware.  It seems like the DATA is somehow becoming
corrupt when loading the default values from program memory. That is how
it works, right? The initialized values are loaded from program memory
in one of the .init sections.. When the above piece of code is included,
somehow my sram contains various strings from the AVRStudio like
"Loading Program Memory", but in double byte format (unicode?). I see
the same data in the program memory, at the end of the program. So the
program memory is somehow not getting the right value and this is then
being copied to SRAM...

In the process of writing this email, I think I found it might be a
ELF/dwarf-2 problem. It happens with the .elf file in avr studio, but
not the .hex file from the same build. I was trying to use GDB and
simulavr to determine if the problem is in avr studio or in the
elf/dwarf-2 creation, but didn't get anywhere.

I am willing to provide the .hex and .elf file if someone else would be
willing to take a look at it.

Thanks!

-jr

James Russo wrote:

> Hello,
>
>     Ok, I give up. Spent the last 4 hours on this problem. I have a ~12k
> application trying to go into a atmega128. I seem to have this problem
> when this one module is loaded in, malloc starts returning large values
> greater then the size of ram. Its like it almost thinks that I have 65k
> of memory installed. Removing the one module seems to solve the
> problem?  I am using a JTAG-ICE to debug the problem.
>
> Here is the avr-size output.
>
>    text       data        bss        dec        hex    filename
>   12426        192        846      13464       3498    main.elf
>
> The first address returned should be 192 + 846 + 2 (malloc size).
>
> can someone give me a hint?
>
> Thanks,
>
> -James
>
> *Yahoo! Groups Sponsor*
> ADVERTISEMENT
> click here
>
<http://us.ard.yahoo.com/SIG=129s2s9n8/M=295196.4901138.6071305.3001176/D=gr
oups/S=1706554205:HM/EXP=1097034954/A=2128215/R=0/SIG=10se96mf6/*http://comp
anion.yahoo.com>
>
>
>
> ------------------------------------------------------------------------
> *Yahoo! Groups Links*
>
>     * To visit your group on the web, go to:
>       http://groups.yahoo.com/group/AVR-Chat/
>
>     * To unsubscribe from this group, send an email to:
>       AVR-Chat-unsubscribe@yahoogroups.com
>       <mailto:AVR-Chat-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
>     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>




Yahoo! Groups Links

Re: [AVR-Chat] malloc/heap issues?

2004-10-05 by James Russo

Larry,

    Thanks for the reply. I am using the latest winavr (20040720) and 
the latest avr studio. I think I found a solution to my problem, but I 
am still testing it.

This thread provides a new parser dll for dwarf.

http://www.avrfreaks.org/phpBB2/viewtopic.php?t=23276&highlight=libelfdwarfparser&sid=f59b47353ba104c20921f5f43f39a4cf

-jr



Larry Barello wrote:
Show quoted textHide quoted text
> The latest winavr has the elf/dwarf support.  It is new.  You probably
> should direct these questions to the avr-gcc-list (http://avr1.org) 
> <http://avr1.org%29>  One way
> around this is to use the previous versions avr-coff and avr-coff-ext 
> output
> formats.  The latter works pretty well with studio 4.xxx allowing most
> structs to be displayed.
>
> -----Original Message-----
> From: James Russo [mailto:jr@halo3.net]
> Sent: Tuesday, October 05, 2004 6:16 AM
> To: AVR-Chat@yahoogroups.com
> Subject: Re: [AVR-Chat] malloc/heap issues?
>
>
>
> Replying to my own email... But I found out more information...
>
> If the following statement is included the problem occurs:
>
> char *my_packet_types[]
>     = {"unk","ping","pong","unk","unk","ack","nak","eeread","eeresp",
>         "alive","eedetailsreq","eedetailsresp","updaterp",
>         "esensordata","sensordata","reset"};
>
> I can easily reproduce the problem by just watching the
> __malloc_heap_start variables in either the avr simulator or using the
> jtag-ice on the hardware.  It seems like the DATA is somehow becoming
> corrupt when loading the default values from program memory. That is how
> it works, right? The initialized values are loaded from program memory
> in one of the .init sections.. When the above piece of code is included,
> somehow my sram contains various strings from the AVRStudio like
> "Loading Program Memory", but in double byte format (unicode?). I see
> the same data in the program memory, at the end of the program. So the
> program memory is somehow not getting the right value and this is then
> being copied to SRAM...
>
> In the process of writing this email, I think I found it might be a
> ELF/dwarf-2 problem. It happens with the .elf file in avr studio, but
> not the .hex file from the same build. I was trying to use GDB and
> simulavr to determine if the problem is in avr studio or in the
> elf/dwarf-2 creation, but didn't get anywhere.
>
> I am willing to provide the .hex and .elf file if someone else would be
> willing to take a look at it.
>
> Thanks!
>
> -jr
>
> James Russo wrote:
>
> > Hello,
> >
> >     Ok, I give up. Spent the last 4 hours on this problem. I have a ~12k
> > application trying to go into a atmega128. I seem to have this problem
> > when this one module is loaded in, malloc starts returning large values
> > greater then the size of ram. Its like it almost thinks that I have 65k
> > of memory installed. Removing the one module seems to solve the
> > problem?  I am using a JTAG-ICE to debug the problem.
> >
> > Here is the avr-size output.
> >
> >    text       data        bss        dec        hex    filename
> >   12426        192        846      13464       3498    main.elf
> >
> > The first address returned should be 192 + 846 + 2 (malloc size).
> >
> > can someone give me a hint?
> >
> > Thanks,
> >
> > -James
> >
> > *Yahoo! Groups Sponsor*
> > ADVERTISEMENT
> > click here
> >
> <http://us.ard.yahoo.com/SIG=129s2s9n8/M=295196.4901138.6071305.3001176/D=gr
> oups/S=1706554205:HM/EXP=1097034954/A=2128215/R=0/SIG=10se96mf6/*http://comp
> anion.yahoo.com>
> >
> >
> >
> > ------------------------------------------------------------------------
> > *Yahoo! Groups Links*
> >
> >     * To visit your group on the web, go to:
> >       http://groups.yahoo.com/group/AVR-Chat/
> >
> >     * To unsubscribe from this group, send an email to:
> >       AVR-Chat-unsubscribe@yahoogroups.com
> >       <mailto:AVR-Chat-unsubscribe@yahoogroups.com?subject=Unsubscribe>
> >
> >     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> >       Service <http://docs.yahoo.com/info/terms/>.
> >
> >
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
> *Yahoo! Groups Sponsor*
> ADVERTISEMENT
> click here 
> <http://us.ard.yahoo.com/SIG=129fkp1m7/M=295196.4901138.6071305.3001176/D=groups/S=1706554205:HM/EXP=1097070140/A=2128215/R=0/SIG=10se96mf6/*http://companion.yahoo.com> 
>
>
>
> ------------------------------------------------------------------------
> *Yahoo! Groups Links*
>
>     * To visit your group on the web, go to:
>       http://groups.yahoo.com/group/AVR-Chat/
>        
>     * To unsubscribe from this group, send an email to:
>       AVR-Chat-unsubscribe@yahoogroups.com
>       <mailto:AVR-Chat-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.