Re: [microblaze-uclinux] dbtrap question

[John Williams <jwilliams@xxxxxxxxxxxxxx>]

Bret,

Bret Ketchum wrote:
> 	Yep, working with the latest distribution and toolset. As far as the
> cause, I was hoping someone could suggest what would cause the microblaze to
> end up in dbtrap, the backtrace shows nothing (as expected) and this occurs
> without a debugger attached. 

Which backtrace are you talkin gabout?  Manually inspecting contents of
r15 to see how you got there?  Also worth looking at r14, and back
tracing at that address.

The only thing that might suggest a cause is
> that the project I'm working on has 20 separate interrupts and it appears
> that I may be missing some of them (the dbtrap thing may be just trapping to
> the wrong address). I've yet to prove that (hope to today) but the IIC core
> tells me it has an interrupt to service yet the INTC core tells me there's
> no pending interrupt to service. As far as the endless loop claim is
> concerned, the console will lock up, I'll invoke the XMD virus and GDB and
> the PC will be sitting in the middle of dbtrap. If you continue and stop the
> microblaze again (and again and again) the PC is still sitting in dbtrap.

Hmm.  when you stop it with XMD, do a register dump, check out r14 and
r15.  Inspect the memory at these addreses - is it a branch or brk to 0x60?

Another possibily is to set a HW breakpoint at 0x60, in XMD, before you
star the kernel.  Then run it, you should trap when you first his the
dbtrap.  A register dump should tell you how you got there.

John
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/