These are issues that we have found and workarounds that seem to work.
The solution is to edit the system.mhs file and set the C_HIGHADDR parameter for the appropriate block.
->
Environment->
Program Start Address.
The linker is incorrectly assigning the default program start address to
0x400. This was okay in 6.2 but downloading using XMD now complains
if the program starts there. The 6.3 XMD probably got bigger.
You don't always need to reload the bitstream, as flipping the reset switch will reset the MicroBlaze. However, there is a catch: if the MicroBlaze has gone off and started executing code in some unknown region (lost in the grass), then some of these "instructions" may have overwritten the xmdstub. In this case, the reset switch will not be sufficient. Redownloading the bit stream is a guaranteed fix, but the reset switch option can be used at your own peril.
In other words, after you have used XMD to download the program, if you type run and then stop (or just wait for the program to complete), when you connect to the debugger and then try to "run" the program in the debugger, it will not work - even if you only use the next/step commands.
Even if you have marked the mb0_default application for download to the BRAM, you must still do this step. Otherwise, XMD will not be able to identify that the executable is indeed there. Many students are not doing this step.
Many students are clicking Run. This is because, if they do not download the executable in Step 6, the Continue option will not be available.