debug application in sdram (microblaze system)

Hi,

Is it possible to debug an application which is in sdram by use of xmdstub?
I have a small bootloader program which programs a final application into
sdram (by use of xmodem). Now I want to debug this application, is that
possible or should I use the opb mdm device?! If it's possible, I guess I
have to build a bootloader with the xmdstub and make a connection. But how
to get my application into the sdram? Can I use the "dow" command at the xmd
command line or an option inside gdb to download the application into sdram
(I'm asking this, because in the normal way the user has to give some input
via the serial port, but that's the same port for debugging thus I can't
give any input). And how to step through the code when the application is in
the sdram?!

TIA,
Frank

Frank,

Yes, you can do exactly what you have described.  When you use the "dow" 
command from the XMD command prompt (after an mbconnect), XMD will use 
the available memory interface core to place the .elf at whatever 
location has been specified in your linker script.  Therefore, you want 
to "dow" the final application, not the bootloader.  You are essentially 
letting MDM/XMD act as your bootloader in this case.

Once the .elf is downloaded, you can then "con" to run or "stp" (step) 
from the command line and see what instruction is causing the problem 
you described in your previous post.  If the system hangs on one of your 
first steps then you probably have a problem with your hardware (likely 
logical or timing issue with your memory interface and/or board).  If 
this is the case, try using the "mwr" and "mrd" commands from XMD to see 
if you can get data in and out of your memory correctly.

You can also try to "dow" your .elf file, do an object dump (mb-objdump) 
of the .elf, then use "mrd" on a large block of the instruction memory, 
and do a comparison between the dumped .elf and what's in the memory. 
If there are any mismatches then there's likely a problem with the 
memory interface hardware/timing.

If it's many instructions into the run, and that instruction memory 
location looks correct, then the software is likely at fault.  Use that 
dumped .elf file to figure out which instruction is causing the problem 
and debug accordingly.

Hopefully you are able to resolve the problem using this information. 
If not then please contact our support hotline for more help.


Best regards,
Ryan Laity
Xilinx Applications

Frank van Eijkelenburg wrote:
> Hi,
> 
> Is it possible to debug an application which is in sdram by use of xmdstub?
> I have a small bootloader program which programs a final application into
> sdram (by use of xmodem). Now I want to debug this application, is that
> possible or should I use the opb mdm device?! If it's possible, I guess I
> have to build a bootloader with the xmdstub and make a connection. But how
> to get my application into the sdram? Can I use the "dow" command at the xmd
> command line or an option inside gdb to download the application into sdram
> (I'm asking this, because in the normal way the user has to give some input
> via the serial port, but that's the same port for debugging thus I can't
> give any input). And how to step through the code when the application is in
> the sdram?!
> 
> TIA,
> Frank
> 
> 

It looks like there are some troubles with debugging an application in sdram
while caching is enabled (both instruction cache and data cache are
enabled). If I remove the cache, I am able to debug my application from
sdram. Could anyone confirm this (I saw a few postings at the xilinx
microblaze forum, but I couldn't find an confirmation from xilinx about this
behaviour)?!

Frank


"Ryan Laity" <ryan_dot_laity@x-i-l-i-n-x_pleasenospam_dot_com> wrote in
message news:c0dod1$5kk1@cliff.xsj.xilinx.com...
> Frank,
>
> Yes, you can do exactly what you have described.  When you use the "dow"
> command from the XMD command prompt (after an mbconnect), XMD will use
> the available memory interface core to place the .elf at whatever
> location has been specified in your linker script.  Therefore, you want
> to "dow" the final application, not the bootloader.  You are essentially
> letting MDM/XMD act as your bootloader in this case.
>
> Once the .elf is downloaded, you can then "con" to run or "stp" (step)
> from the command line and see what instruction is causing the problem
> you described in your previous post.  If the system hangs on one of your
> first steps then you probably have a problem with your hardware (likely
> logical or timing issue with your memory interface and/or board).  If
> this is the case, try using the "mwr" and "mrd" commands from XMD to see
> if you can get data in and out of your memory correctly.
>
> You can also try to "dow" your .elf file, do an object dump (mb-objdump)
> of the .elf, then use "mrd" on a large block of the instruction memory,
> and do a comparison between the dumped .elf and what's in the memory.
> If there are any mismatches then there's likely a problem with the
> memory interface hardware/timing.
>
> If it's many instructions into the run, and that instruction memory
> location looks correct, then the software is likely at fault.  Use that
> dumped .elf file to figure out which instruction is causing the problem
> and debug accordingly.
>
> Hopefully you are able to resolve the problem using this information.
> If not then please contact our support hotline for more help.
>
>
> Best regards,
> Ryan Laity
> Xilinx Applications
>
> Frank van Eijkelenburg wrote:
> > Hi,
> >
> > Is it possible to debug an application which is in sdram by use of
xmdstub?
> > I have a small bootloader program which programs a final application
into
> > sdram (by use of xmodem). Now I want to debug this application, is that
> > possible or should I use the opb mdm device?! If it's possible, I guess
I
> > have to build a bootloader with the xmdstub and make a connection. But
how
> > to get my application into the sdram? Can I use the "dow" command at the
xmd
> > command line or an option inside gdb to download the application into
sdram
> > (I'm asking this, because in the normal way the user has to give some
input
> > via the serial port, but that's the same port for debugging thus I can't
> > give any input). And how to step through the code when the application
is in
> > the sdram?!
> >
> > TIA,
> > Frank
> >
> >
>

Frank,

I was not aware that you were using cache with your SDRAM in this 
system.  To debug with cache support, you must use the MDM.

Ryan Laity
Xilinx



Frank van Eijkelenburg wrote:
> It looks like there are some troubles with debugging an application in sdram
> while caching is enabled (both instruction cache and data cache are
> enabled). If I remove the cache, I am able to debug my application from
> sdram. Could anyone confirm this (I saw a few postings at the xilinx
> microblaze forum, but I couldn't find an confirmation from xilinx about this
> behaviour)?!
> 
> Frank
> 
> 
> "Ryan Laity" <ryan_dot_laity@x-i-l-i-n-x_pleasenospam_dot_com> wrote in
> message news:c0dod1$5kk1@cliff.xsj.xilinx.com...
> 
>>Frank,
>>
>>Yes, you can do exactly what you have described.  When you use the "dow"
>>command from the XMD command prompt (after an mbconnect), XMD will use
>>the available memory interface core to place the .elf at whatever
>>location has been specified in your linker script.  Therefore, you want
>>to "dow" the final application, not the bootloader.  You are essentially
>>letting MDM/XMD act as your bootloader in this case.
>>
>>Once the .elf is downloaded, you can then "con" to run or "stp" (step)
>>from the command line and see what instruction is causing the problem
>>you described in your previous post.  If the system hangs on one of your
>>first steps then you probably have a problem with your hardware (likely
>>logical or timing issue with your memory interface and/or board).  If
>>this is the case, try using the "mwr" and "mrd" commands from XMD to see
>>if you can get data in and out of your memory correctly.
>>
>>You can also try to "dow" your .elf file, do an object dump (mb-objdump)
>>of the .elf, then use "mrd" on a large block of the instruction memory,
>>and do a comparison between the dumped .elf and what's in the memory.
>>If there are any mismatches then there's likely a problem with the
>>memory interface hardware/timing.
>>
>>If it's many instructions into the run, and that instruction memory
>>location looks correct, then the software is likely at fault.  Use that
>>dumped .elf file to figure out which instruction is causing the problem
>>and debug accordingly.
>>
>>Hopefully you are able to resolve the problem using this information.
>>If not then please contact our support hotline for more help.
>>
>>
>>Best regards,
>>Ryan Laity
>>Xilinx Applications
>>
>>Frank van Eijkelenburg wrote:
>>
>>>Hi,
>>>
>>>Is it possible to debug an application which is in sdram by use of
> 
> xmdstub?
> 
>>>I have a small bootloader program which programs a final application
> 
> into
> 
>>>sdram (by use of xmodem). Now I want to debug this application, is that
>>>possible or should I use the opb mdm device?! If it's possible, I guess
> 
> I
> 
>>>have to build a bootloader with the xmdstub and make a connection. But
> 
> how
> 
>>>to get my application into the sdram? Can I use the "dow" command at the
> 
> xmd
> 
>>>command line or an option inside gdb to download the application into
> 
> sdram
> 
>>>(I'm asking this, because in the normal way the user has to give some
> 
> input
> 
>>>via the serial port, but that's the same port for debugging thus I can't
>>>give any input). And how to step through the code when the application
> 
> is in
> 
>>>the sdram?!
>>>
>>>TIA,
>>>Frank
>>>
>>>
>>
> 
>