Re: Debugging Interrupt Vector Tables (IVTs)
- From: "gordy" <gjmilne@xxxxxxxxx>
- Date: 15 Jan 2007 00:54:22 -0800
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)
So this is the symptom.
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
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.
Consider, the bootloader transfers the control to application . Iam
to single step till the point the control is within the bootloader.
when the bootloader invokes the application , I loose control of
and we are unable to step into application.
Which bootloader are you using? Perhaps that is significant.
I am able to single-step through the bootloader alone. COnsider, i
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
Is it possible that your bootloader disables debugging when it switches
over to the application?
Please suggest some way to do this debugging .
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
How to debug this "bootloader to application transfer of control and
continue to debug the application " ? I use OMAP 5912.