Re: [ECOS] MPC860 - hal_arbitration_isr_cpm

Re: [ECOS] MPC860 - hal_arbitration_isr_cpm

[nprasad3]

Hi,
> > 1. I keep getting interrupt # 10 (control makes it to 
> > cyg_hal_default_isr). Nothing is attached to IRQ5# as that 
> > line is supposed to cause this interrupt. 
eCos vector numbers start from 1 as opposed to 0 which is what the MPC860 documentation uses. interrupt #10 was 9 (internal level 4 used by PIT so that was correct). Any specific reason why the vector #'s in eCos don't co-incide with the 860 docs?

An unrelated problem, does return to redboot after executing a Ram application work? My application terminates but I never see the redboot prompt.

Thanks in advance
Nirmal




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

Re: [ECOS] MPC860 - hal_arbitration_isr_cpm

[Gary Thomas]

On Thu, 2003-12-18 at 07:13, nprasad3@gmu.edu wrote:
> The problem was traced down to some faulty intr_attach 
> which was causing hal_arbitration_isr_cpm to be called 
> for non-cpm interrupt. Still have some issues with interrupts though.
> 
> 1. I keep getting interrupt # 10 (control makes it to 
> cyg_hal_default_isr). Nothing is attached to IRQ5# as that 
> line is supposed to cause this interrupt. I'm trying to 
> locate the cause of this spurious interrupt. Interrupt 
> keeps coming at a rapid pace.Most likely a level-triggered 
> one and source needs to be satisfied to bring the line down.
> 2. As a consequence, if I use the seperate stack to handle i
> nterrupts option, I get a machine check exception after 
> about 10-15 times that it handles the interrupt. Using the 
> common stack, things last longer.
> 3. The cyghal_default_interrupt_vsr and cyghal_default_exception_vsr 
> handlers have enable_mmu (doesn't really change MMU bits as it uses 
> CYG_MSR whose bits are conditional) but shouldn't this be in a conditional 
> based on whether MMU is to be turned on? 

No, because that code (misnamed/miscommented) also [re]enables 
the FPU as well.

> 
> Thanks
> Nirmal
> 
> 
> ----- Original Message -----
> From: nprasad3@gmu.edu
> Date: Tuesday, December 16, 2003 9:35 pm
> Subject: [ECOS] MPC860 - hal_arbitration_isr_cpm
> 
> > Hi,
> > 
> > I keep getting hal_arbitration_isr_cpm with civr of 0. According 
> > to the documentation this is the Error vector where the interrupt 
> > was cleared by the user before the core serviced and there are no 
> > pending interrupts for the cpm.
> > 
> > 1. Why am I seeing this behavior? Who is clearing the interrupt?
> > 2. hal_arbitration_isr_cpm returns a 0 everytime civr = 0 instead 
> > of cyg_isr_handled. Can this be a problem?
> > 
> > Thanks in advance
> > Nirmal
> > 
> > 
> > 
> > -- 
> > Before posting, please read the FAQ: 
> > http://sources.redhat.com/fom/ecosand search the list archive: 
> > http://sources.redhat.com/ml/ecos-discuss
> > 
> > 
> > 
-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


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

Re: [ECOS] MPC860 - hal_arbitration_isr_cpm

[nprasad3]

The problem was traced down to some faulty intr_attach which was causing hal_arbitration_isr_cpm to be called for non-cpm interrupt. Still have some issues with interrupts though.

1. I keep getting interrupt # 10 (control makes it to cyg_hal_default_isr). Nothing is attached to IRQ5# as that line is supposed to cause this interrupt. I'm trying to locate the cause of this spurious interrupt. Interrupt keeps coming at a rapid pace.Most likely a level-triggered one and source needs to be satisfied to bring the line down.
2. As a consequence, if I use the seperate stack to handle interrupts option, I get a machine check exception after about 10-15 times that it handles the interrupt. Using the common stack, things last longer.
3. The cyghal_default_interrupt_vsr and cyghal_default_exception_vsr handlers have enable_mmu (doesn't really change MMU bits as it uses CYG_MSR whose bits are conditional) but shouldn't this be in a conditional based on whether MMU is to be turned on? 

Thanks
Nirmal


----- Original Message -----
From: nprasad3@gmu.edu
Date: Tuesday, December 16, 2003 9:35 pm
Subject: [ECOS] MPC860 - hal_arbitration_isr_cpm

> Hi,
> 
> I keep getting hal_arbitration_isr_cpm with civr of 0. According 
> to the documentation this is the Error vector where the interrupt 
> was cleared by the user before the core serviced and there are no 
> pending interrupts for the cpm.
> 
> 1. Why am I seeing this behavior? Who is clearing the interrupt?
> 2. hal_arbitration_isr_cpm returns a 0 everytime civr = 0 instead 
> of cyg_isr_handled. Can this be a problem?
> 
> Thanks in advance
> Nirmal
> 
> 
> 
> -- 
> Before posting, please read the FAQ: 
> http://sources.redhat.com/fom/ecosand search the list archive: 
> http://sources.redhat.com/ml/ecos-discuss
> 
> 
> 


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

[ECOS] MPC860 - hal_arbitration_isr_cpm

[nprasad3]

Hi,

I keep getting hal_arbitration_isr_cpm with civr of 0. According to the documentation this is the Error vector where the interrupt was cleared by the user before the core serviced and there are no pending interrupts for the cpm.

1. Why am I seeing this behavior? Who is clearing the interrupt?
2. hal_arbitration_isr_cpm returns a 0 everytime civr = 0 instead of cyg_isr_handled. Can this be a problem?

Thanks in advance
Nirmal



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