I am using Cortex M0 in Designstart FPGA with the Arty A35 and DAPlink board with Keil.
But on loading the Demo software I get the following message box:
After Rest Target it works.
The same issue arises if I set a breakpoint or remove one.
I played with several settings in the Keil debug dialog but it didn't help.
This happens also on the reference Cortex M0 bit file.
Is that a known limitation or is something wrong with my DAPLInk board.
It Sounds like you are using a Digient Arty A7-35T board digilent.com/.../arty-a7-artix-7-fpga-development-board
I see at least one other user had issues connecting to this board, and had to go through Digilent support to fix it. Have you tried that? digilent.com/.../
To make sure the board is not damaged, Could you test it with the "Xilinx Software Development Kit" as described in section 2 of: digilent.com/.../reference-manual
[If you know the board is working]
that MDK message usually means the device is asleep, has locked up, or there is some sort of issue with the pins meant for JTAG communication (pins using alternate function, clocking turned off, etc.)
Hello Kevin,
I do not think that the board is defect.
I can program the FPGA with my own Cortex M0 synthesised bit-files.
I can also download the M0 software in Keil and start the debugger.
Debugging in Keil works but behaves a bit strange.
I think the problem is either the M0 Coresight or the DAPLink board.
I will check if CortexM3 Designstart shows the same behaviour.
did you swap out USB cables? Try debugging with a lower core clock? Those might fix intermittent communication issues
If only one particular project has this issue, did you look at "t MDK message usually means the device is asleep, has locked up, or there is some sort of issue with the pins meant for JTAG communication (pins using alternate function, clocking turned off, etc.)"
I finally found the reason for this behaviour and a workaround
The V2C DAPLink board maps XIP Flash at address 0.
Executing from XIP flash is slow and debugging seems not properly working.
To circumvent this, I changed the scatter file for the CortexM1 sample application such that it relocates the code to address 0x10000000, where FPGA RAM is located.
Now the application runs much faster and debugging works perfectly.
The scatter file I use is as follows:
LR_IROM1 0x00000000 0x00010000 { ; load region size_region ER_IROM1 0x00000000 0x00010000 { ; load address = execution address *.o (RESET, +First) system_ARTY_CM1.o startup_ARTY_CM1.o *(InRoot$$Sections) .ANY (+RO) .ANY (+XO) } RW_IRAM1 0x20000000 0x00008000 { ; RW data .ANY (+RW +ZI) } RW_IRAM2 0x10000000 0x00010000 { *.o .ANY (+RW +ZI) } }