EDK: Microblaze with XMdstub

Apr 09, 2005 4 Replies

hi, How do I setup my MicroBlaze design to use XMDStub for debugging my embedded design?I am using virtex-II pro ML310 platform and EDK 6.3. When I am creating a new system with microblaze i come to an option : Processor Confirguration debug I/F



1.on chip H/W debug module
2.XMD with S/W debug stub
3.no debug I choose XMD with S/W debug stub.Then later on after i write the code for my design and have to intilize the bram,Should i initialize it with my executable code or the xmdstub or both?

thanx.



Never done this myself and I'm not sure of the answer even after reading the xmd part of the manual. Why not use MDM--I use that all the time and it avoids the whole sw stub issue?

Paul

snipped-for-privacy@gmail.com wrote:

snipped-for-privacy@gmail.com wrote in news:1113076705.654974.7640 @g14g2000cwa.googlegroups.com:

I believe you should mark the xmdstub so it will be initialized into the BRAM. Once you download to the FPGA, the xmdstub starts executing and I think it looks for debug commands arriving through the serial port. You can use your debugger to download your application code through the serial port. I've never actually done it, so I stand to be corrected.

---------------------------------------------------------------- Dave Van den Bout XESS Corp. PO Box 33091 Raleigh NC 27636 Phn: (919) 363-4695 Fax: (801) 749-6501 devb@xess.com http://www.xess.com

I also have an interrupt controller in my system.If I include the xmdstub then wont it overwrite my interrupt handler which is at

0X00000010?I read somewhere that xmdstub is 800 bytes and starts from 0x00000000 memory location.How does this work then? Does anyone has experience in dealing with a system in which microblaze will have several interrupts through the OPB_INTC?I am having hard time figuring out what exactly the INTC sends to the microblaze when it gets an interrupt request. Thanx.

xmdstub is a software-intrusive tool, and has certain limitations as a result. Unless you are really tight on logic, I recommend following Paul Hartke's earlier suggestion to use the MDM hardware debug capability. It's totally non-intrusive, and makes it trivial to debug otherwise difficult situations like interrupt handlers and so on.

It will maybe take you a couple of hours to integrate MDM into your system and learn the (very) slightly modified development/debug flow that results, but after that you will never look back.

Regards,

John

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required