Debugging Interrupt Vector Tables (IVTs)

Jesus, not another one.

How about:

1. reading a book
2. taking a look at the manual for the processor in question

Come on this is group about embedded Linux. We expect you to have done
a little bit of reading before you ask your first question.

A more useful question would be centred on why you want to "debug IVT".
What kind of problem are you having? Is your CPU disappearing off into
la-la land when it handles an interrupt? Do you have any kind of JTAG
debugger attached to the processor? Can you stop the CPU and see what
it is executing?

More information would be a LOT more helpful. Big picture questions
about how do I do X will not be weel received.

Regards,

Gordon

karthikbg wrote:

Hi,

Thx for your replies.
Yes, My CPU disappears off into la-la land when it handles an interrupt
and so my SRAM gets cleared ?
(I have some Boot signatures stored in SRAM which is used for the
booting either the 'A' application or 'B' application  , But this gets
zeroed.I am into debugging the problem)

I am able to individually load and  single step within either boot
loader/ application . I am
able to debug using the debugger without loosing any control if i debug

within the bootloader /application .  But, i am unable to
debug at the point the control is handed over from the bootloader to
application. I loose the control
over the debugger and i am unable to debug the issues oriented towards
the booting of my application from the bootlaoder

Consider, the bootloader transfers the control to application . Iam
able
to single step till the point the control is within the bootloader.
But,
when the bootloader invokes the application , I loose control of
debugger
and we are unable to step into application.

I am able  to single-step through the bootloader alone. COnsider, i
place a
breakpoint in the application and say run to cursor. ( I am calling the

application from the bootloader in the code. The breakpoint is at the
entry point of the application).  I am unable to debug from the point
at which the application is invoked from the bootloader.  I loose
control of the debugger and unable to trace the things that happen at
the point

Please suggest some way to do this debugging .

How to debug this "bootloader to application transfer of control and
continue to debug the application "  ?  I use OMAP 5912.

Thx in advans,
Karthik Balaguru

So this is the symptom.



Hmm, it sounds as if the switch from the bootloader to the application
causes some remapping of memory. Remember that Linux (on ARM) expects
to start executing at  a particular address and will ensure that memory
is remapped accordingly.



Which bootloader are you using? Perhaps that is significant.



Is it possible that your bootloader disables debugging when it switches
over to the application?



If you can afford it, I would hook up a JTAG debugger and set a
breakpoint with it.  You can probably set it to catch the interrupt
that is causing your problem.

I am sure that there is some other way of doing this with your
bootloader debugger but since I don't know what it is I cannot be more
helpful.