EDK: Microblaze with XMdstub

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.

Reply to
kittyawake
Loading thread data ...

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:

Reply to
Paul Hartke

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
Reply to
Dave Vanden Bout

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.
Reply to
kittyawake

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

Reply to
John Williams

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.