Debugging Interrupt Vector Tables (IVTs)

Hi,

How to debug IVT (Interrupt Vector Tables) ? Kindly provide some ideas/views for doing this.

Thx in advans, Karthik Balaguru

Reply to
karthikbg
Loading thread data ...

Jesus, not another one.

Reply to
Geronimo W. Christ Esq

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,

Gord> Hi,

Reply to
gordy

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

Reply to
karthikbg

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.

Reply to
gordy

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.