This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem with GDB/insight debugging standalone interrupt driven code


Hi Nick

My startup code only sets up the stacks and copies the IRQ vector 
instruction
		 ldr     PC, [PC,#-0xFF0]  

to the IRQ vector (after remap)
		  ldr     r0,=0xe51ffff0
             ldr	r1,=0x40000018
		  str     r0,[r1]           

I the zero .bss and copy .data and jump to main

When I step through my code the following instruction which enables 
IRQ's causes GDB to hang

asm volatile (" msr  cpsr, %0" : /* no outputs */ : "r" (val)  );

As I mentioned earlier, the code seems to work fine when I use gdb to 
load and run this application


Best regards



To:             	Miklos.Pflancer@dbresearch.co.uk
Copies to:      	ecos-discuss@sourceware.org
Subject:        	Re: [ECOS] Problem with GDB/insight debugging standalone interrupt driven code
From:           	Nick Garnett <nickg@ecoscentric.com>
Date sent:      	21 Sep 2006 11:40:26 +0100

Miklos.Pflancer@dBResearch.co.uk writes:

> HI
> 
> Target - ARM LPC2292 Embest development board running Redboot
> 
> I think I have a problem with gdb stubs in redboot.
> 
> I can load and run a  standalone application which uses interrupts 
> into external ram  using gdb, however If I set breakpoints or try 
to 
> single step the application stops and gdb becomes unresponsive. 
> 
> I can burn the same application into flash and load with Redboot 
and 
> this works fine.
> 
> I was wondering if  there are options in the configtool which 
should 
> be selected but are'nt. I am not familiar with many of these 
> settings. 
> 
> Can anyone offer any advice on this matter


It is likely that your standalone application is reprogramming the
hardware under the stubs feet. Perhaps it is changing the serial line
baud rate, perhaps it is redirecting the exception vectors to its own
code, perhaps it is overwriting RedBoot's data area. Any of these
would cause the stubs to fail to catch an exception or fail to
communicate.

You need to take a close look at what the application does during
startup. You may also need to single step it from its entry point
until you find where it messes up the hardware. 


-- 
Nick Garnett                                 eCos Kernel Architect
http://www.ecoscentric.com            The eCos and RedBoot experts


Miklos Pflancer
Electronics Engineer

--------------------------------------------------
email : miklos@dbresearch.co.uk
--------------------------------------------------
dB Research Ltd
Concept House
Merton Road
Bootle
Liverpool L20 3BG
UK

Tel (+44)(0)151 330 0800
Fax (+44)(0)151 330 0808
--------------------------------------------------

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]