Cortex-M0 DesignStart R2

I don't see any problem with the connectivity in the deliverables. What I did was re-use the CXDT which is included with Cortex-M3 DesignStart Eval (where there is a more complex debug system, and tests to exercise this).

1. Download Cortex-M3 DesignStart Eval, and unpack the deliverables.

2. Copy the test vector binary from this download:

cp AT421-MN-80001-r0p0-02rel0/m3designstart/logical/testbench/integration_cssoc/validation/bin/discovery-CXDT-1-CPU-NONE/CXDT.bin systems/cortex_m0_mcu/rtl_sim

3. Copy the debug engine ffom this download:

cp -r AT421-MN-80001-r0p0-02rel0/m3designstart/logical/testbench/cxdt systems/cortex_m0_mcu

4. Edit tbench_M0_DS.vc to add:

-y ../cxdt/verilog

5. Edit tb_cmsdk_mcu.v to instantiate the CXDT component:

 // --------------------------------------------------------------------------------
 // Debug tester connection -
 // --------------------------------------------------------------------------------

   CXDT #(.IMAGENAME ("./CXDT.bin"))
   u_cxdt(.CLK       (XTAL1),
          .PORESETn  (NRST),
          .TDO       (TDO),
          .TDI       (TDI),
          .nTRST     (nTRST),
          .SWCLKTCK  (SWCLKTCK),
          .SWDIOTMS  (SWDIOTMS));
 // No debug connection for Cortex-M0 DesignStart
// assign nTRST    = NRST;
// assign TDI      = 1'b1;
// assign SWDIOTMS = 1'b1;
// assign SWCLKTCK = 1'b1;

6. Edit the source for hello.c to include an endless loop (using virtual) - CXDT will stop the simulation.

7. Compile the test and the code, run the test

make compile
make testcode TESTNAME=hello
make sim TESTNAME=hello

This test will read the DPIDR value (and the test will fail, since the precompiled vector is expecting the system from Cortex-M3, but it will read the correct value for Cortex-M0.

# CXDT: Starting Debug Stimulus
# ========================================
# DP 0
# DPIDR 0x0bb11477 : Unknown DP  ***ERROR*** Unrecognised ID  ***ERROR*** Unrecognised Revision
# ----------------------------------------

You should see signals like this on the SWD port for the first handshake:

I don't see any problem with the connectivity in the deliverables. What I did was re-use the CXDT which is included with Cortex-M3 DesignStart Eval (where there is a more complex debug system, and tests to exercise this).

1. Download Cortex-M3 DesignStart Eval, and unpack the deliverables.

2. Copy the test vector binary from this download:

cp AT421-MN-80001-r0p0-02rel0/m3designstart/logical/testbench/integration_cssoc/validation/bin/discovery-CXDT-1-CPU-NONE/CXDT.bin systems/cortex_m0_mcu/rtl_sim

3. Copy the debug engine ffom this download:

cp -r AT421-MN-80001-r0p0-02rel0/m3designstart/logical/testbench/cxdt systems/cortex_m0_mcu

4. Edit tbench_M0_DS.vc to add:

-y ../cxdt/verilog

5. Edit tb_cmsdk_mcu.v to instantiate the CXDT component:

 // --------------------------------------------------------------------------------
 // Debug tester connection -
 // --------------------------------------------------------------------------------

   CXDT #(.IMAGENAME ("./CXDT.bin"))
   u_cxdt(.CLK       (XTAL1),
          .PORESETn  (NRST),
          .TDO       (TDO),
          .TDI       (TDI),
          .nTRST     (nTRST),
          .SWCLKTCK  (SWCLKTCK),
          .SWDIOTMS  (SWDIOTMS));
 // No debug connection for Cortex-M0 DesignStart
// assign nTRST    = NRST;
// assign TDI      = 1'b1;
// assign SWDIOTMS = 1'b1;
// assign SWCLKTCK = 1'b1;

6. Edit the source for hello.c to include an endless loop (using virtual) - CXDT will stop the simulation.

7. Compile the test and the code, run the test

make compile
make testcode TESTNAME=hello
make sim TESTNAME=hello

This test will read the DPIDR value (and the test will fail, since the precompiled vector is expecting the system from Cortex-M3, but it will read the correct value for Cortex-M0.

# CXDT: Starting Debug Stimulus
# ========================================
# DP 0
# DPIDR 0x0bb11477 : Unknown DP  ***ERROR*** Unrecognised ID  ***ERROR*** Unrecognised Revision
# ----------------------------------------

You should see signals like this on the SWD port for the first handshake:

Maybe I have a problem with the sysrom table. In my case, it seems to be completly empty:

 // ------------------------------------------------------------
    // ROM Table Manufacturer, Part Number and Revision
    // ------------------------------------------------------------
    parameter [6:0]    JEPID           = 7'b0000000, // JEP106 identity code
    parameter [3:0]    JEPCONTINUATION = 4'h0,       // number of JEP106
                                                     // continuation codes
    parameter [11:0]   PARTNUMBER      = 12'h000,    // part number
    parameter [3:0]    REVISION        = 4'h0,       // part revision

That could explain why the debugger is not able to detect it.

That is a bit misleading, but I don't believe it's the problem, since the version we've been testing in FPGA is the same. With M0, there are no other CoreSight components which would need to be enumerated in the ROM table, and I believe that tools ought to discover the CPU regardless in this scenario.

We've only tested debug using the Arm toolchains - and there you can see both the probe and the SW-DP identified. The important part to confirm that the FPGA is correct would be the box at the top right here.

Trying to connect, I get

SEGGER J-Link Commander V6.00d (Compiled Jul 29 2016 19:08:27)
DLL version V6.20b, compiled Sep 22 2017 17:57:26

Connecting to J-Link via USB...O.K.
Firmware: J-Link V9 compiled Sep 22 2017 17:42:08
Hardware version: V9.30
S/N: 269300240
License(s): FlashBP, GDB
OEM: SEGGER-EDU
VTref = 0.000V


Type "connect" to establish a target connection, '?' for help
J-Link>connect
Please specify device / core. <Default>: CORTEX-M0
Type '?' for selection dialog
Device>?
Please specify target interface:
  J) JTAG (Default)
  S) SWD
TIF>s
Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>5
Device "CORTEX-M0" selected.


Cannot connect to target.
J-Link>connect
Device "CORTEX-M0" selected.

I changed from J-Link to ULINK pro:

Looks much better, however:

.

I'm not sure what is going on with J-link there - maybe it does the power-up implicitly (and fails).

Not powering up would suggest to me that the CDBGPWRUPREQ to CDBGPWRUPACK loopback (L595 in user_partition under RevC) is missing. This is a CoreSight requirement, even if there is no power control implemented, you need to provide the illusion to the tools that they can both enable and disable debug power.

Sean

Ok, I put the code from user_partition into my design and added the necessary connections. Unfortunately, the result remains the same.

A few things to check:

1) Check reset type to System Reset Request to see if it helps

2) I think the SWJ option can be uncheck as the Cortex-M0 DAP don't have protocol switching

3) Connection of SYSRESETREQ (System Reset Request) - can it generate a system reset?

4) JTAG/SWD clock constraints in synthesis, is it missing?

Hope it helps.

regards,

Joseph

Another suggestion I've had is that maybe there is a clocking or reset with the core domain (since the DAP ID registers are in the SWCLK domain), affecting wither the core or the CDBGPWRUPREQ/CSYSPWRUPREQ and the corresponding acknowledge signals.

If you carry on with ULINKPro for now (we should follow the JLINK problem later), it will be useful to enable the logging:

Dear Sean, dear Joseph,

I solved parts of the problem on Saturday:

your suggestion with the CDBGPWRUPREQ to CDBGPWRUPACK loopback was right.

I copied the code, but forgot the CDBGPWRUPREQ   connection.

So I had

   .CDBGPWRUPREQ    (),
   .CDBGPWRUPACK     (CDBGPWRUPACK),

instead of

   .CDBGPWRUPREQ    (CDBGPWRUPREQ),
   .CDBGPWRUPACK     (CDBGPWRUPACK),

I am now able to download and debug.

I will now try with J-Link and then do the next steps.

I am very grateful for you help and support.

Regards,

Eberhard