[ECOS] EDOSK2674 GDB stub problem 2

[ECOS] EDOSK2674 GDB stub problem 2

[Uwe Kindler]

Hello,

just a short question about my problem with the GDB stub.

In the ecos reference manual is written for HAL Startup

"Initialize various CPU status registers. Most importantly, the CPU
interrupt mask should be set to disable
interrupts."

But there is no point in HAL startup where interrupts will be enabled. Does
this mean, that i.e. Redboot
ist started with all interrupts disabled by CPU interrupt mask? But how is
then gdb break support possible for
Redboot if this interrupt is disabled? Or does a RAM application have to
enable interrupts at startup in order
to use CTRL C support.

And then another point. At startup hal_ctrlc_isr_init have to be called in
order to use GDB break support.
But when I look into this function then I can read:

// A ROM monitor never enables the interrupt itself. This is left
// to the (RAM) application.

Does this mean, if I have a very simple RAM application without any eCos
stuff inside, i.e. only a very simple
main routine, I can not use CTRL C support because I have to call
hal_ctrlc_isr_init from my RAM application?

So what is the right way for CTRL C debugging and when / where should
interrupts be enabled or the
CPU interrupt mask be unmasked and who provides the CTRL C isr - the ROM
monitor or the RAM application

Thank you in advance.

Regards, Uwe


-- 
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] EDOSK2674 GDB stub problem 2

[Nick Garnett]

"Uwe Kindler" <uwe_kindler@web.de> writes:

> Hello,
> 
> just a short question about my problem with the GDB stub.
> 
> In the ecos reference manual is written for HAL Startup
> 
> "Initialize various CPU status registers. Most importantly, the CPU
> interrupt mask should be set to disable
> interrupts."
> 
> But there is no point in HAL startup where interrupts will be enabled. Does
> this mean, that i.e. Redboot
> ist started with all interrupts disabled by CPU interrupt mask? But how is
> then gdb break support possible for
> Redboot if this interrupt is disabled? Or does a RAM application have to
> enable interrupts at startup in order
> to use CTRL C support.

Yes. This is true for both eCos applications and for newlib based
applications. RedBoot unmasks the appropriate interrupt source in the
interrupt controller, but it is the responsibility of the application
to enable interrupts in the CPU.

> 
> And then another point. At startup hal_ctrlc_isr_init have to be called in
> order to use GDB break support.
> But when I look into this function then I can read:
> 
> // A ROM monitor never enables the interrupt itself. This is left
> // to the (RAM) application.
> 
> Does this mean, if I have a very simple RAM application without any eCos
> stuff inside, i.e. only a very simple
> main routine, I can not use CTRL C support because I have to call
> hal_ctrlc_isr_init from my RAM application?


No, it just means that the application must enable interrupts. This is
usually done in crt0.s.

> 
> So what is the right way for CTRL C debugging and when / where should
> interrupts be enabled or the
> CPU interrupt mask be unmasked and who provides the CTRL C isr - the ROM
> monitor or the RAM application
> 

In theory, the application should not need to do anything other than
enable CPU interrupts when it is happy for interrupts to be delivered.


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


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