On Mon, Jul 29, 2013 at 6:06 PM, Daniel Beer wrote:
> On Mon, Jul 29, 2013 at 05:50:39PM -0500, Peter Bigot wrote:
> > The extra word is probably the watchdog timer clear value, which is
> > initialized on reset. You can exclude it by using -mdisable-watchdog.
> > mspgcc uses different sections
On Mon, Jul 29, 2013 at 05:50:39PM -0500, Peter Bigot wrote:
> The extra word is probably the watchdog timer clear value, which is
> initialized on reset. You can exclude it by using -mdisable-watchdog.
> mspgcc uses different sections than AVR, and for mspgcc .noinit is not
> merged with .bss. W
The extra word is probably the watchdog timer clear value, which is
initialized on reset. You can exclude it by using -mdisable-watchdog.
mspgcc uses different sections than AVR, and for mspgcc .noinit is not
merged with .bss. With the default linker script .noinit is between the
bottom of the st
On Tue, Jul 30, 2013 at 08:28:14AM +1000, Wayne Uroda wrote:
> Yesterday I was looking at just this and to my surprise there was one extra
> word allocated to ".noinit". I had never seen this before in all my years,
> and I was almost filling over it with a pattern to measure my stack usage. My
Hi Daniel,
Yesterday I was looking at just this and to my surprise there was one extra
word allocated to ".noinit". I had never seen this before in all my years, and
I was almost filling over it with a pattern to measure my stack usage. My point
is that one should add the size of bss and data a
I would like to add to this list the possibility of a stack/heap
collision if dynamic allocation is being used. I am not sure on the
specifics of the project at hand [I will not ask either], but if the
timer interrupt "stops working" that essentially means something turned
off the interrupt somewhe
On Mon, Jul 29, 2013 at 01:47:14PM -0700, ravim wrote:
> Really appreciate your response.
>
> I will try to do what you have suggested. Issue is we fear that so much is
> happening in our code too fast (flash write, blacklist check, then
> communication with different devices etc), we fear we migh
On 2013-07-29, ravim wrote:
> I will try to do what you have suggested. Issue is we fear that so
> much is happening in our code too fast (flash write, blacklist check,
> then communication with different devices etc), we fear we might be
> corrupting stack somehow with so many global and local v
Thanks Grant,
Really appreciate your response.
I will try to do what you have suggested. Issue is we fear that so much is
happening in our code too fast (flash write, blacklist check, then
communication with different devices etc), we fear we might be corrupting
stack somehow with so many global
Thank you so much Daniel, Really appreciate it. This is definitely going to
help.
--
View this message in context:
http://msp430-gcc-users.1086195.n5.nabble.com/Size-of-global-variable-tp6822p6825.html
Sent from the MSP430 gcc - Users mailing list archive at Nabble.com.
---
On 2013-07-29, ravim wrote:
> My apologies if I am asking something irrelevant to this forum. We are using
> mspgcc and mspdebug for our project. We are facing some issues with what we
> assume might be stack overflow. The timer interrupts stops working after
> around 2 hours, however device still
On Mon, Jul 29, 2013 at 12:56:31PM -0700, ravim wrote:
> My apologies if I am asking something irrelevant to this forum. We are using
> mspgcc and mspdebug for our project. We are facing some issues with what we
> assume might be stack overflow. The timer interrupts stops working after
> around 2 h
My apologies if I am asking something irrelevant to this forum. We are using
mspgcc and mspdebug for our project. We are facing some issues with what we
assume might be stack overflow. The timer interrupts stops working after
around 2 hours, however device still receives packets. Also, when we rese
13 matches
Mail list logo
