Re: [ECOS] problem about interrupt end

["jiang jet" <jetjiang at hotmail dot com>]

I have resolved the problem,but met another problem. 
1)resolved methed: I don't know if it's a bug of ecos source code, in   
 packages/hal/mips/arch/v2_0/src/vector.S
     #ifdef CYGFUN_HAL_COMMON_KERNEL_SUPPORT
            la   vo,cyg_scheduler_sched_lock
            nop                    //added by me, maybe this one is not 
necessary
            lw   a0,0(v0)
            nop                      //added by me,here it's delay 
slot,but original code 
            add a0,a0,1              //just put add a0,a0,1 there, I dobut 
if it's a bug
            sw a0,0(v0)               //but it resolved my problem...
            .........
      #endif
2)the new problem I met
 in unlock_inner, the process is like this:
 
unlock_inner---->Cyg_interupt::call_pending_DSRs()--->hal_interrupt_stack_pending_DSRs-->

interrupt_call_pending_DSRs--->Cyg_interrupt::call_pending_DSRs_inner()-->intr->dsr--->..

 the problem is When I enter the intr->dsr(here is realtime clock dsr),the 
stack is destoried. Before enter DSR,the return address is saved 
in,say,0x80004704(now correct), after enter DSR, the content is changed!!I 
have checked: after enter the dsr ,sp is 0x80004738,and then changed to 
0x80004718, so it is IMPOSSIBLE for dsr procedure to destory the stack 
content(0x800004704),but during this period( inner to DSR), there is no 
other opreations..I wonder what changes this value?? 
  btw: I am using the clocktruth.cxx to have a test...

thanks a lot

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

_________________________________________________________________
免费下载 MSN Explorer:   http://explorer.msn.com/lccn/  


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss