RE: [ECOS] Redboot-GDB

["Doyle, Patrick" <WPD at dtccom dot com>]

This probably doesn't help a whole lot, but I ran into the same problem, and
went down the same chain of logic as you when debugging the "go" command on
an ARM based platform.  Ultimately, the bug was in my initialization of the
interrupt controller on my target.  IIRC, I didn't mask all of the
interrupts that should have been masked.

See http://sources.redhat.com/ml/ecos-discuss/2003-03/msg00211.html for my
description of my original problem and
http://sources.redhat.com/ml/ecos-discuss/2003-03/msg00212.html for Mark's
response to it.

HTH...

--wpd


> -----Original Message-----
> From: Michael Anburaj [mailto:embeddedeng@hotmail.com] 
> Sent: Wednesday, June 25, 2003 1:58 AM
> To: nickg@ecoscentric.com; msalter@redhat.com
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] Redboot-GDB
> 
> 
> Hi Nick/Mark/All,
> 
> 
> >You can test the basic GDB stub entry/exit handling by typing:
> >
> >   $k#6b
> >
> 
> I was about to try this with the redboot build from the 
> current cvs source, 
> but Redboot was dying while the context was switched to reach 
> trampoline() 
> of redboot\current\src\main.c after receiving '$'.
> 
> After much debugging I found that in hal_thread_load_context 
> at the last 
> instruction "movs    pc,lr" the SPSR (with I bit cleared) was 
> moved to the 
> CPSR. Thus enabling the IRQs. At this point the ECOS-RTC (tick timer) 
> interrupt was pending & because of which the flow never reached 
> trampoline(). This may be the reason for my other problem too.
> 
> Questions (please let me know, which is right & which is not):
> 1. Is this ok? Can the flow, while switching to trampoline() 
> be interrupted? 
> If this is normal, then I need to debug further to find why 
> it did not 
> resume after the ECOS-RTC interrupt was serviced.
> 2. I believe the ECOS-RTC (tick timer) interrupt got unmasked at 
> hal_clock_initialize(). hal_clock_initialize() getting called 
> in Redboot at 
> this point; is it normal?
> 3. hal_clock_initialize() starts the timer & unmasks the 
> interrupt (from 
> this point the timer can generate ARM-IRQs, provided the I 
> bit in CPSR is 
> low). Is this right? Or should hal_clock_initialize() not 
> unmask the timer 
> interrupt.
> 4. The following lines in hal_thread_load_context of 
> context.s moves 0x13 
> (with I & F bits low):
> ldr     r0,[fp,#armreg_cpsr]
> msr     spsr,r0
> Is this right? Or should the I & F bit be high, disabling the 
> IRQs before 
> shifting control to trampoline()?
> 
> 
> Please comment on these questions, so that I can solve this issue...
> 
> Thanks a lot & Cheers,
> -Mike
> 
> _________________________________________________________________
> MSN 8 with e-mail virus protection service: 2 months FREE*  
> http://join.msn.com/?page=features/virus
> 
> 
> -- 
> Before posting, please read the FAQ: 
> http://sources.redhat.com/fom/ecos
> and 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