Hi,
I have been trying to add the debug function into my Cortex-M0 design for FPGA implementation targeting at Xilinx Spartan-6.
Both JTAG or SWD are failed to work although the cortex-m0 seem function well (it execute the code and make LED blinky).
What I do is setting the configuration in CORTEXM0INTEGRATIONIMP.v ( yes, I started from the wrapper file) to enable its debug function and JTAG (or SWD in another try), and adding the necessary file under the logical directory and model directory directly. I used the built-in ROM table, so I didn't modify the BASEADDR in CORTEXM0INTERGATION.v. And I add the code in top level module to use TDOEN to control the TDO output (just like what Integration Kit does). When I implement the design in ISE, the TDI, nTRST, TCK, TMS, and TDO was removed in the map phase by the ISE. Then the DS-5 and MDK can't detect the existing of debug port.
I know ARM have offer two Altera FPGA images that support SWD and JTAG in Application Note 226 (ARM DAI0226B). I would like to know if there exist any document to teach people to add the debug port into Cortex-M0. Is overriding the dap model under the model directory a necessary work?
Thanks for your help!
If the debug connection is removed in synthesis, there are several possibilities.
- missing debug reset connection (reset end up tied low and all debug logic get optimized away).
- verilog parameters that cause debug features to be removed.
Also check if there is missing clock definitions for the TCK in your synthesis constraints.
The debug logic have a separated clock domain, see the following paper
Embedded World 2014 - ARM® Cortex®-M Processor based System Prototyping on FPGA
I don't know if you have a support contract. If you have, you can contact support team for additional assistance.
regards,
Joseph
As far as I know the Cortex-M0 design start for FPGA does not support debugging. I assume this is what you're using. I have the core running in an Spartan-6 board and it runs very well, apart from the debug feature. If you really need debugging, I see two options: 1) use the breakpoint instruction. While it triggers a hard fault vector instead of the breakpoint vector you still get a handle to the origin of the break. Basically, you could write your own GDB stub using this feature (I've decided this is too much work for my application). 2) You have an FPGA and the core offers a list of debug signals. Attach a chipscope core to these signals and monitor the operation.
Well, and there's a third one: printf(), like in the old days ...
Regards,
Andreas
Dear sieg70,
It has been quite a while since you wrote the question, if you can, would you please let me know how to program your firmware code into the implemented fpga?
Especially how did you run the blink LED firmware?
sieg70 said:(it execute the code and make LED blinky)