This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
RE: [Fwd: Re: problem about interrupt end]
- From: "jiang jet" <jetjiang at hotmail dot com>
- To: michael dot pederson at freescale dot com
- Cc: ecos-discuss at ecos dot sourceware dot org
- Date: Mon, 04 Dec 2006 08:20:01 +0800
- Subject: [ECOS] RE: [Fwd: Re: [ECOS] problem about interrupt end]
- Bcc:
sorry I'm so late to see your letter..
the situation I met is : when I add some diag_printf in dsr of realtime
clock, then the return address is destried...I trace the program and print
out the memory content, I found it's diag_printf that overide the content,
so I remove them and the problem is resolved,
but the root cause,I think, should be the distance between sp of interrupt
and general sp is too short..
BTW: it's better that you have a tools to help u trace the stack ,that will
help u a lot!
hope these info give u a little bit help:)
jet
-------- Original Message --------
Subject: Re: [ECOS] problem about interrupt end
Date: Thu, 30 Nov 2006 11:05:21 -0600
From: Michael Pederson <michael.pederson@freescale.com>
To: ecos-discuss@ecos.sourceware.org
References: <BAY104-F36BD3157823142929DE23DFDB0@phx.gbl>
Jiang, I would be most appreciative if you could elaborate for me the
problem you were seeing with diag_printf. I have also been seeing some
stack corruption that only appears when it is used.
jiang jet wrote:
>
> hi, I have resolved that problem:)
> it's caused by diag_printf:)
> thanks again
> jet
>
>> From: Nick Garnett <nickg@ecoscentric.com>
>> To: "jiang jet" <jetjiang@hotmail.com>
>> CC: ecos-discuss@ecos.sourceware.org
>> Subject: Re: [ECOS] problem about interrupt end
>> Date: 29 Nov 2006 11:24:34 +0000
>>
>> "jiang jet" <jetjiang@hotmail.com> writes:
>>
>> > I think i have excluded the reason of repeating interrupt causing
this
>> > problem...
>> > I prolong the timer to a very big number..so I can see for the first
>> > timer interrput the breakdown occurs...
>> > since the board and cpu is designed by ourself, I doubt if the
>> > assembly code for processing the interrupt needed to be modified(I
>> > refer to the code process
>> > :__defualt_intterrupt_vsr-->hal_interrupt_handlers-->isr--here code
>> > crashed))???is it possible?
>>
>> In that case it looks like memory corruption from some other
>> source. Perhaps thread stack overflow. If the board is your own design
>> then check that RAM address decode is being handled correctly and not
>> wrapping unexpectedly.
>>
>> --
>> Nick Garnett eCos Kernel Architect
>> http://www.ecoscentric.com The eCos and RedBoot experts
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss