Core not Responding (LS1020A)

[perfranck]

UPDATE: THIS ISSUE WAS CAUSED BY AN IMPROPERLY WIRED JTAG PORT.

Hello All.

We have been working with the LS1021A development board on a dev. machine (Ubuntu) using codewarrior with great success. However, we just obtained our own hardware with an LS1020A and a Xilinx FPGA in the same JTAG chain, and we're having some trouble connecting to the processor using codewarrior.

Following the documentation, we created a jtag configuration file "in TDO order", which according to the IDcode.tcl script in CodeWarrior Connection Server was:

CCS scanboard output
TDO -----         |         * Device 0  IDCODE: 13919093  Device: Unknown Device         * Device 1  IDCODE: 5BA00477  Device: Unknown Device         * Device 2  IDCODE: 16B0001D  Device: FSL LS1 Device rev 2.x         | TDI -----

After searching the forums here we learned that the BA00744 is the id code for the DAP, the 3919093 is the id code for the Xilinx part. In other words, the TDO order is Xilinx --> DAP --> LS1020A, our jtag config file therefore was

JTAG Config File 1
Generic 6 1 0x3F DAP LS1020A

The Generic 6 1 0x3F was set to identify the Xilinx IR length, bypass instruction length, and bytecode.

When attempting to connect to the board using CodeWarrior, we get the following error message in CCS and CW.

CodeWarrior console output

ccs_open   ipaddr = 127.0.0.1   port = 41475   timeout = 60   serverh = 0   ccs_open; ccs_error = 0 ccs_get_connection_count   serverh = 0   count = 1   ccs_get_connection_count; ccs_error = 0 ccs_available_connections   serverh = 0   count = 1   ccs_available_connections; ccs_error = 0 ccs_get_connection_count   serverh = 0   count = 1   ccs_get_connection_count; ccs_error = 0 ccs_available_connections   serverh = 0   count = 1   ccs_available_connections; ccs_error = 0 ccs_available_connections   serverh = 0   count = 1   ccs_available_connections; ccs_error = 0 ccs_delete_cc   serverh = 0   count = 0   ccs_delete_cc; ccs_error = 0 ccs_config_cc   serverh = 0   config_string = cwtap:0   ccs_config_cc; ccs_error = 0 ccs_available_connections   serverh = 0   count = 1   ccs_available_connections; ccs_error = 0 ccs_cc_version   serverh = 0   cc = 0   version.major = 0   version.minor = 0   ccs_cc_version; ccs_error = 0 ccs_set_timeout   serverh = 0   timeout = 60   ccs_set_timeout; ccs_error = 0 ccs_get_config_chain   serverh = 0   device_list: (size = 0)   ccs_get_config_chain; ccs_error = 0 ccs_config_server   serverh = 0   cc = 0   server_config = 0   value = 10000   ccs_config_server; ccs_error = 0 ccs_config_chain   serverh = 0   cc = 0   device_list: (size = 3)   device[0]:: core_type=Generic Device(0); device_descr=[ir_length:6;dr_bypass_length:1;bypass_instruction:0x3F,0x00,0x00,0x00]   device[1]:: core_type=DAP(232)   device[2]:: core_type=LS1020A(273)   ccs_config_chain; ccs_error = 39   Error message: LS1020A: Invalid parameter ccs_get_subcore_error   serverh = 0   cc = 0   error = 6   chain_pos = 2   ccs_get_subcore_error; ccs_error = 0; duration=10 ms ccs_close   serverh = 0   ccs_close; ccs_error = 0

We have searched high and low what this "Invalid Parameter" might mean, we tried adding RCW parameters to the LS1020A line, we tried more newlines in the file, but nothing seems to work.

CCS Output

CCSAPI connection #1 accepted from localhost at Mon May 16 10:44:23 2016 check_min_version(serverh=0,*version)   api version: 00000004 00000006 get_connection_count(serverh=0,cc_index=0,*count)   count:1 available_connections(serverh=0,*count,*cc)   connections: {0,73,0xa9fe965f} available_connections(serverh=0,*count,*cc)   connections: {0,73,0xa9fe965f} available_connections(serverh=0,*count,*cc)   connections: {0,73,0xa9fe965f} available_connections(serverh=0,*count,*cc)   connections: {0,73,0xa9fe965f} available_connections(serverh=0,*count,*cc)   connections: {0,73,0xa9fe965f} available_connections(serverh=0,*count,*cc)   connections: {0,73,0xa9fe965f} cc_version(serverh=0,cc_index=0,index=0,*version) get_config_chain(serverh=0,cc=0) config_server(config_reg=0,config_data=0x00002710) config_chain(serverh=0,cc=0,count=3,*devlist,*generic)   devlist: unknown(0),dap,ls1020a   ERROR(39): Subcore error encountered during multicore operation parse_error_ext(coreh.{serverh=0,cc_index=0,chain_pos=0}, 39)   error: LS1020A: Invalid parameter get_subcore_error(serverh=0,cc=0,*error,*chain_pos)   error: Invalid parameter   chain_pos: 2 CCSAPI connection #1 from localhost closed at Mon May 16 10:44:25 2016 (bin) 56 %

We then ran scanboard on our development board and got the following output...

CCS scanboard output on DEV board.
TDO -----         |         * Device 0  IDCODE: 5BA00477  Device: Unknown Device         * Device 1  IDCODE: 16B0001D  Device: FSL LS1 Device rev 2.x         | TDI -----

We noticed that here, we only see the DAP and the LS1020A, but they list in TDO order: DAP --> LS1020A, which is contrary to the example JTAG configuration files we were given with the IDE.

Dev Board JTAG Config File
LS1020A DAP SAP2

In addition, the Dev board JTAG Config file lists "SAP2" Which we have not been able to figure out what it is. Do we need this in custom hardware, or is it only a part of the dev board?

We modified our JTAG config file to this

JTAG Config File 2
LS1020A DAP Generic 6 1 0x3F

Now, we got a new error in CodeWarrior

CodeWarrior output

ccs_open   ipaddr = 127.0.0.1   port = 41475   timeout = 60   serverh = 0   ccs_open; ccs_error = 0 ccs_get_connection_count   serverh = 0   count = 1   ccs_get_connection_count; ccs_error = 0 ccs_available_connections   serverh = 0   count = 1   ccs_available_connections; ccs_error = 0 ccs_available_connections   serverh = 0   count = 1   ccs_available_connections; ccs_error = 0 ccs_cc_version   serverh = 0   cc = 0   version.major = 0   version.minor = 0   ccs_cc_version; ccs_error = 0 ccs_set_timeout   serverh = 0   timeout = 60   ccs_set_timeout; ccs_error = 0 ccs_get_config_chain   serverh = 0   device_list: (size = 0)   ccs_get_config_chain; ccs_error = 0 ccs_config_server   serverh = 0   cc = 0   server_config = 0   value = 10000   ccs_config_server; ccs_error = 0 ccs_config_chain   serverh = 0   cc = 0   device_list: (size = 3)   device[0]:: core_type=LS1020A(273)   device[1]:: core_type=DAP(232)   device[2]:: core_type=Generic Device(0); device_descr=[ir_length:6;dr_bypass_length:1;bypass_instruction:0x3F,0x00,0x00,0x00]   ccs_config_chain; ccs_error = 39   Error message: LS1020A: Core not responding ccs_get_subcore_error   serverh = 0   cc = 0   error = 5   chain_pos = 0   ccs_get_subcore_error; ccs_error = 0; duration=10 ms ccs_close   serverh = 0   ccs_close; ccs_error = 0

We now get "Core Not Responding" as the error message. At this point we started looking at the hardware to ensure that all the reset pins are set/cleared as they should be during the start-up sequence, all the voltages that are required are present, and all clocks as well. From our standpoint, we are following the start-up sequence in hardware to the letter.

CCS output

CCSAPI connection #1 accepted from localhost at Mon May 16 10:39:55 2016 check_min_version(serverh=0,*version)   api version: 00000004 00000006 get_connection_count(serverh=0,cc_index=0,*count)   count:1 available_connections(serverh=0,*count,*cc)   connections: {0,73,0xa9fe965f} available_connections(serverh=0,*count,*cc)   connections: {0,73,0xa9fe965f} available_connections(serverh=0,*count,*cc)   connections: {0,73,0xa9fe965f} available_connections(serverh=0,*count,*cc)   connections: {0,73,0xa9fe965f} available_connections(serverh=0,*count,*cc)   connections: {0,73,0xa9fe965f} available_connections(serverh=0,*count,*cc)   connections: {0,73,0xa9fe965f} cc_version(serverh=0,cc_index=0,index=0,*version) get_config_chain(serverh=0,cc=0) config_server(config_reg=0,config_data=0x00002710) config_chain(serverh=0,cc=0,count=3,*devlist,*generic)   devlist: ls1020a,dap,unknown(0)   ERROR(39): Subcore error encountered during multicore operation parse_error_ext(coreh.{serverh=0,cc_index=0,chain_pos=0}, 39)   error: LS1020A: Core not responding get_subcore_error(serverh=0,cc=0,*error,*chain_pos)   error: Core not responding   chain_pos: 0 CCSAPI connection #1 from localhost closed at Mon May 16 10:39:58 2016

The last thing we attempted was to add the SAP2 to the config file. Since the examples given with the development board all used this entry. We tried this file reversed (TDO order) as well, but got the "Invalid parameter" error again.

JTAG config file 3
LS1020A DAP SAP2 Generic 6 1 0x3F

Now, the error message is again different.

CodeWarrior console output

ccs_open   ipaddr = 127.0.0.1   port = 41475   timeout = 60   serverh = 0   ccs_open; ccs_error = 0 ccs_get_connection_count   serverh = 0   count = 1   ccs_get_connection_count; ccs_error = 0 ccs_available_connections   serverh = 0   count = 0   ccs_available_connections; ccs_error = 0 ccs_available_connections   serverh = 0   count = 0   ccs_available_connections; ccs_error = 0 ccs_config_cc   serverh = 0   config_string = cwtap:0   ccs_config_cc; ccs_error = 0 ccs_available_connections   serverh = 0   count = 1   ccs_available_connections; ccs_error = 0 ccs_cc_version   serverh = 0   cc = 0   version.major = 0   version.minor = 0   ccs_cc_version; ccs_error = 0 ccs_set_timeout   serverh = 0   timeout = 60   ccs_set_timeout; ccs_error = 0 ccs_get_config_chain   serverh = 0   device_list: (size = 0)   ccs_get_config_chain; ccs_error = 0 ccs_config_server   serverh = 0   cc = 0   server_config = 0   value = 12500   ccs_config_server; ccs_error = 0 ccs_config_chain   serverh = 0   cc = 0   device_list: (size = 4)   device[0]:: core_type=LS1020A(273)   device[1]:: core_type=DAP(232)   device[2]:: core_type=SAP2(272)   device[3]:: core_type=Generic Device(0); device_descr=[ir_length:6;dr_bypass_length:1;bypass_instruction:0x3F,0x00,0x00,0x00]   ccs_config_chain; ccs_error = 0 ccs_get_config_chain   serverh = 0   device_list: (size = 4)   ccs_get_config_chain; ccs_error = 0 ccs_get_config_chain   serverh = 0   device_list: (size = 4)   device[0]:: core_type=LS1020A(273)   device[1]:: core_type=DAP(232)   device[2]:: core_type=SAP2(272)   device[3]:: core_type=Generic Device(0)   ccs_get_config_chain; ccs_error = 0 ccs_available_connections   serverh = 0   count = 1   ccs_available_connections; ccs_error = 0 ccs_delete_cc   serverh = 0   count = 0   ccs_delete_cc; ccs_error = 0 ccs_close   serverh = 0   ccs_close; ccs_error = 0

The error doesn't appear in the log, instead a popup says "CCSProtocolPlugin::Can't connect to CCS".

CCS output

CCSAPI connection #1 accepted from localhost at Mon May 16 15:19:54 2016 check_min_version(serverh=0,*version)   api version: 00000004 00000006 get_connection_count(serverh=0,cc_index=0,*count)   count:1 available_connections(serverh=0,*count,*cc)   connections: available_connections(serverh=0,*count,*cc)   connections: setup_cc(serverh=0,config_string= cwtap:0 ) available_connections(serverh=0,*count,*cc)   connections: {0,73,0xa9fe965f} available_connections(serverh=0,*count,*cc)   connections: {0,73,0xa9fe965f} available_connections(serverh=0,*count,*cc)   connections: {0,73,0xa9fe965f} cc_version(serverh=0,cc_index=0,index=0,*version) get_config_chain(serverh=0,cc=0) config_server(config_reg=0,config_data=0x000030D4) config_chain(serverh=0,cc=0,count=4,*devlist,*generic)   devlist: ls1020a,dap,sap2,unknown(0) get_config_chain(serverh=0,cc=0) available_connections(serverh=0,*count,*cc)   connections: {0,73,0xa9fe965f} delete_cc(serverh=0,cc=0) CCSAPI connection #1 from localhost closed at Mon May 16 15:20:07 2016

There is no explanation as to why the "connection failed".

How are we supposed to fashion our jtag config files? has anyone else used a xilinx part (or similar) together with a LS1020A (or similar nxp device)? How do we debug this?

Thanks for any help.

Per Franck

[addiyi]

Please try the followings to test jtag interface and provide the output:

ccs::config_server 0 20
ccs::config_chain testcore
jtag::lock
jtag::reset_tap 1

jtag::reset_tap 1
jtag::scan_io ir 64 -1

jtag::unlock

ccs::config_server 0 20

ccs::config_chain testcore

jtag::lock

jtag::reset_tap 1

jtag::reset_tap 1

jtag::scan_in dr 256

jtag::scan_in dr 256

jtag::unlock

Adrian

[perfranck]

The following is the output from the suggested commands ..

(bin) 106 % ccs::config_server 0 20
(bin) 107 % ccs::config_chain testcore
(bin) 108 % jtag::lock
(bin) 109 % jtag::reset_tap 1
(bin) 110 % jtag::reset_tap 1
(bin) 110 % jtag::scan_io ir 64 -1
0xFFFFFFFFFFFC0475
(bin) 111 % jtag::unlock
(bin) 112 % ccs::config_server 0 29
(bin) 113 % ccs::config_server 0 20
(bin) 114 % ccs::config_chain testcore
(bin) 115 % jtag::lock
(bin) 116 % jtag::reset_tap 1
(bin) 117 % jtag::reset_tap 1
(bin) 117 % jtag::scan_in dr 256
0x000000000000000000000000000000000000000016B0001D5BA0047713919093
(bin) 118 % jtag::scan_in dr 256
0x000000000000000000000000000000000000000016B0001D5BA0047713919093
(bin) 118 % jtag::unlock
(bin) 119 % 

[addiyi]

You could check if the board is out of reset with the following command:

ccs::config_server 0 20

ccs::config_chain {{6 1} ls1020a dap sap2}

display ccs::get_config_chain

display ccs::read_reg 3 tresetsr 1

Should be 0x180 if out of reset.

Adrian

[perfranck · Accepted solution]

Hello Adrian. Thank you for your diligence with this issue. It turns out that our JTAG port was improperly wired. After that was fixed, this issue was resolved.

[addiyi]

After applying the RCW override configuration, a reset is needed for the SoC to take the new RCW config. This is done with ccs::reset_to_debug. If no error is return, means that RCW config is correct.

Of course, error when ccs::reset_to_debug, could be reason for other issues, not only RCW.

Adrian

[addiyi]

For full rcw override, in jtag config file you have to use:

LS1020A (0 0x9B) (0x1000 0x80000001) ....all the rcw settings. The rcw source is not mandatory.

Adrian

[perfranck]

Adrian, it appears to me that the RCWs are not written to the ARM until after the reset, so.

1. config_chain

2. write_reg (rcw source)

3. config_template (override rcw?)

4. reset

5. write rcw

is this correct? when we run codewarrior, it bails out on step 4 when it cannot reset.

we also tried config_server 2 10000 to see if a longer delay during reset would help, but no

What exactly is CCS looking for to determine the reset was successful? is it polling registers? is it looking at a JTAG pin?

[addiyi]

Ok. Seems that rcw is correctly override. Maybe you must do some adjustment to RCW to fit your with your board and use full rcw (rcw + pll) override option:

ccs::config_template 1 4096 0x80000001;

Adrian

[perfranck]

Thanks, I will poke around at the RCWs.

I notice you specify 0x80000001 here, is bit 31 to override PLL? Is there any documentation regarding ccs::config_template?

Also, do you have to specify RCW_SRC in the JTAG initialization file before the override?

Neither of the hard-coded options (0x9A - 0x9F) fit our board, and since we don't have the NAND or QSPI programmed with RCWs yet, what should we put there, or doesn't it matter as long as we specify (0x1000 1) following that?

lastly, when we specify RCW, are they in little or big endian? meaning, in the 512-bit RCW, which bit am i setting with this statement?

LS102xA (0 0x9B) (0x1000 1) (4097 0x00000001)

is it bit 32 or bit 63 (note, rcw 4097)

Many thanks for all your help, Adrian.

[addiyi]

Please try the following ccs script. It will config the chain (note that for fpga only IR length and bypass length must be passed in ccs command), override the rcw, read RCW and reset. You can adjust the rcw values, according with your board settings.

# script for checking out the board

log v > /dev/null;

delete all;

config cc cwtap;

ccs::config_chain {{6 1} ls1020a dap sap2};

display ccs::get_config_chain;

ccs::config_template 1 4096 1;

ccs::write_reg 1 rcw_src 0x9A;

ccs::write_reg 1 4096 4 {0x0608000a};

ccs::write_reg 1 4097 4 {0x00000000};

ccs::write_reg 1 4098 4 {0x00000000};

ccs::write_reg 1 4099 4 {0x00000000};

ccs::write_reg 1 4100 4 {0x70000000};

ccs::write_reg 1 4101 4 {0x00407900};

ccs::write_reg 1 4102 4 {0xe0025a00};

ccs::write_reg 1 4103 4 {0x21046000};

ccs::write_reg 1 4104 4 {0x00000000};

ccs::write_reg 1 4105 4 {0x00000000};

ccs::write_reg 1 4106 4 {0x00000000};

ccs::write_reg 1 4107 4 {0x00038000};

ccs::write_reg 1 4108 4 {0x00080000};

ccs::write_reg 1 4109 4 {0x48007340};

ccs::write_reg 1 4110 4 {0x00000000};

ccs::write_reg 1 4111 4 {0x00000000};

display ccs::read_reg 1 rcw_src 1;

display ccs::read_reg 1 rcw0 16;

ccs::reset_to_debug;

Adrian

[perfranck]

Hello Adrian. Following is the output from CCS of the script suggested.

(bin) 68 % ::vpg::adrian
CCS Linux Release Build 439p0
Chain Position 0: Generic Device
Chain Position 1: LS1020A
Chain Position 2: DAP
Chain Position 3: SAP2
rcw_src=0x0000009A 
   rcw0=0x0608000A    rcw1=0x00000000    rcw2=0x00000000    rcw3=0x00000000
   rcw4=0x70000000    rcw5=0x00407900    rcw6=0xE0025A00    rcw7=0x21046000
   rcw8=0x00000000    rcw9=0x00000000   rcw10=0x00000000   rcw11=0x00038000
  rcw12=0x00080000   rcw13=0x48007340   rcw14=0x00000000   rcw15=0x00000000
LS1020A: Core not responding
(bin) 69 % 

[addiyi]

Jtag chain file should look as below:

Generic 6 1 0x3f

LS1021A

DAP

SAP2

Also, make sure fpga parameters are correct (bypass lenght, bypass instruction). You can also try with

LS1021A

DAP

SAP2

Generic 8 1 0xff

Please open ccs console, activate verbose log using "log v" and provide the output.

Adrian

[perfranck]

Hi Adrian. Thanks for your reply.

I tried the two examples you provided, according to the Xilinx Ultrascale manual the IR length is indeed 6, bypass length 1 bit, and the instruction is 0x3F.

Your previous suggestion of ccs::config_chain {{6 1 0x3F} ls1020a dap sap2} led me in an interesting direction.

I tried a config file that attempts to write the RCWs

JTAG Config
Generic 6 1 0x0000003F LS1020A (0 0x9B) (0x1000 1) (4096 0x0610000a) (4097 0x00000000) (4098 0x00000000) (4099 0x00000000) (4100 0x00000000) (4101 0x00000002) (4102 0x4011D000) (4103 0x00046000) (4104 0x00000000) (4105 0x00000000) (4106 0x00000000) (4107 0x0123e800) (4108 0x20084100) (4109 0x1004c000) (4110 0x00000000) (4111 0x00000000) DAP SAP2

The values for RCWs were given by an FAE for the dev board, just trying them for kicks at this point.

The output from CCS is:

CCS output

config_chain(serverh=0,cc=0,count=4,*devlist,*generic)   devlist: unknown(0),ls1020a,dap,sap2 write_register(coreh.{serverh=0,cc_index=0,chain_pos=1},index=0,size=4,*reg)   reg: 0000009B config_template(coreh.{serverh=0,cc_index=0,chain_pos=1},config_reg=4096,config_data=0x00000001) reset_to_debug(serverh=0,cc=0)   ERROR(39): Subcore error encountered during multicore operation parse_error_ext(coreh.{serverh=0,cc_index=0,chain_pos=0}, 39)   error: LS1020A: Core not responding CCSAPI connection #1 from localhost closed at Thu May 19 09:14:52 2016

As you can see, the config_chain takes, and the commands write_register and config_template don't seem to have any issues. the problem occurs when the reset_to_debug command is handled.

I created a tcl script for CCS as follows:

scan.tcl
# script for checking out the board log v > /dev/null delete all config cc cwtap ccs::config_chain {{6 1 0x3F} ls1020a dap sap2} display ccs::get_config_chain display ccs::read_reg 1 rcw_src 1 display ccs::read_reg 1 rcw0 16

running this, i get.

scan.tcl CCS output

(bin) 16 % source scan.tcl CCS Linux Release Build 439p0 Chain Position 0: Generic Device Chain Position 1: LS1020A Chain Position 2: DAP Chain Position 3: SAP2 rcw_src=0x00000144    rcw0=0x00000000    rcw1=0x00000000    rcw2=0x00000000    rcw3=0x00000000    rcw4=0x00000000    rcw5=0x00000000    rcw6=0x00000000    rcw7=0x00000000    rcw8=0x00000000    rcw9=0x00000000   rcw10=0x00000000   rcw11=0x00000000   rcw12=0x00000000   rcw13=0x00000000   rcw14=0x00000000   rcw15=0x00000000 (bin) 17 %

i then tried using ccs::write_reg 1 rcw9 0x12345678, followed by display ccs::read_reg 1 rcw0 16 and the changes appear after reading them back so it appears to me that we're able to write and read registers (??)

i then immediately follow this with ccs::reset_to_debug but get LS1020A: Core not responding.

So it seems to me I'm on the right track ... I should be able to reset_to_debug without having written any RCWs though, right?

[yipingwang]

Hello Per Franck,

It looks that the return value of ccs_get_config_chain is abnormal, probably JTAG configuration file is still not coincident with the hardware.The devices are enumerated in the direction starting from TDO output to TDI input.

Have a great day,
Yiping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[perfranck]

Thank you for your reply!

When we run scanboard from the IDcode.tcl script in CCS, we get the following output

CCS output IDcode.tcl scanboard
TDO -----         |         * Device 0  IDCODE: 13919093  Device: Unknown Device         * Device 1  IDCODE: 5BA00477  Device: Unknown Device         * Device 2  IDCODE: 16B0001D  Device: FSL LS1 Device rev 2.x         | TDI -----

Would you agree that the devices enumerated in the direction starting from TDO output to TDI input is 13919093, 5BA00477, 16B0001D?

How would a JTAG configuration file be written? We assumed as follows:

JTAG Config File
Generic 6 1 0x3F DAP LS1020A

Is this correct? If not, how should it be written? If it is correct, why do we get "Invalid parameter" error as mentioned above?

[addiyi]

Try with the following configuration into jtag file:

Generic 6 1 0x3F

LS1021A

DAP

SAP2

Also, note that ccs putting the TDO device first. To test your config chain is working you can use the ccs console with followings commands:

delete all

config cc cwtap

ccs::config_chain {{6 1 0x3F} ls1020a dap sap2}

ccs::reset_to_debug

Adrian

[perfranck]

Thanks for your reply. We tried this in our last example above. The output is as follows:

CodeWarrior Popup: CCSProtocolPlugin::Can't connect to CCS

CodeWarrior console output

ccs_config_chain   serverh = 0   cc = 0   device_list: (size = 4)   device[0]:: core_type=Generic Device(0); device_descr=[ir_length:6;dr_bypass_length:1;bypass_instruction:0x3F,0x00,0x00,0x00]   device[1]:: core_type=LS1020A(273)   device[2]:: core_type=DAP(232)   device[3]:: core_type=SAP2(272)   ccs_config_chain; ccs_error = 0 ccs_get_config_chain   serverh = 0   device_list: (size = 4)   ccs_get_config_chain; ccs_error = 0 ccs_get_config_chain   serverh = 0   device_list: (size = 4)   device[0]:: core_type=Generic Device(0)   device[1]:: core_type=LS1020A(273)   device[2]:: core_type=DAP(232)   device[3]:: core_type=SAP2(272)   ccs_get_config_chain; ccs_error = 0 ccs_available_connections   serverh = 0   count = 1   ccs_available_connections; ccs_error = 0 ccs_delete_cc   serverh = 0   count = 0   ccs_delete_cc; ccs_error = 0 ccs_close   serverh = 0   ccs_close; ccs_error = 0

CCS Output

CCSAPI connection #1 accepted from localhost at Wed May 18 08:12:09 2016 check_min_version(serverh=0,*version)   api version: 00000004 00000006 get_connection_count(serverh=0,cc_index=0,*count)   count:1 available_connections(serverh=0,*count,*cc)   connections: available_connections(serverh=0,*count,*cc)   connections: setup_cc(serverh=0,config_string= cwtap:0 ) available_connections(serverh=0,*count,*cc)   connections: {0,73,0xa9fe5178} available_connections(serverh=0,*count,*cc)   connections: {0,73,0xa9fe5178} available_connections(serverh=0,*count,*cc)   connections: {0,73,0xa9fe5178} cc_version(serverh=0,cc_index=0,index=0,*version) get_config_chain(serverh=0,cc=0) config_server(config_reg=0,config_data=0x000030D4) config_chain(serverh=0,cc=0,count=4,*devlist,*generic)   devlist: unknown(0),ls1020a,dap,sap2 get_config_chain(serverh=0,cc=0) available_connections(serverh=0,*count,*cc)   connections: {0,73,0xa9fe5178} delete_cc(serverh=0,cc=0) CCSAPI connection #1 from localhost closed at Wed May 18 08:12:23 2016 (bin) 50 %

As for your suggestion of manual entry into CCS, this is the output.

CCS Manual Entry
(bin) 50 % delete all (bin) 51 % config cc cwtap (bin) 52 % ccs::config_chain {{6 1 0x3F} ls1020a dap sap2} (bin) 53 % ccs::reset_to_debug LS1020A: Core not responding

Any ideas?