LS2085A: Custom board JTAG connectivity issues

[ramasubramanian]

Hi,

We are trying to connect to our LS2085A based custom board.  We are unable to connect.  Please find below the error message.

(gdb) source  ../../gdb_extensions/flash/cwflash.py

Starting flash programmer services...

Starting local server...

Successfully started gdb server 127.0.0.1:45096.

Set gdb remote timeout to 7200

Connecting to target...

Using LS2085A SoC

Using CWTAP FSL03AE43

Using jtag speed 16000

Connecting to probe...

ccs:Subcore error encountered during multicore operation

GTA: run control cannot suspend core.

connection failed

Traceback (most recent call last):

File "../../gdb_extensions/flash/cwflash.py", line 89, in <module>

fp_initialization()

File "../../gdb_extensions/flash/cwflash.py", line 87, in fp_initialization

start_fp_services(argument)

File "/opt/Freescale/CW4NET_v2016.01/CW_ARMv8/ARMv8/gdb_extensions/flash/../flash/scripts/services.py", line 128, in start_fp_services

return instance.invoke(argument, False)

File "/opt/Freescale/CW4NET_v2016.01/CW_ARMv8/ARMv8/gdb_extensions/flash/../flash/scripts/services.py", line 85, in invoke

ret = self.start_service(argument)

File "/opt/Freescale/CW4NET_v2016.01/CW_ARMv8/ARMv8/gdb_extensions/flash/../flash/scripts/services.py", line 99, in start_service

ret = start(args)

File "/opt/Freescale/CW4NET_v2016.01/CW_ARMv8/ARMv8/gdb_extensions/flash/../flash/scripts/flash_init.py", line 242, in start

if internal_start(args) is False:

File "/opt/Freescale/CW4NET_v2016.01/CW_ARMv8/ARMv8/gdb_extensions/flash/../flash/scripts/flash_init.py", line 47, in internal_start

if internal_connect_to_target(args) is False:

File "/opt/Freescale/CW4NET_v2016.01/CW_ARMv8/ARMv8/gdb_extensions/flash/../flash/scripts/flash_init.py", line 190, in internal_connect_to_target

gdb_execute('monitor ctx connect')

File "/opt/Freescale/CW4NET_v2016.01/CW_ARMv8/ARMv8/gdb_extensions/flash/../flash/scripts/utils.py", line 72, in gdb_execute

raise gdb.GdbError("Error: " + str(exc))

gdb.GdbError: Error: Protocol error with Rcmd

We ran scanboard on ccs command prompt and are able to get the IDCODE that matches to that with LS2085Ardb. This was with TBSCAN_EN_B=1

TDO -----

        |

        * Device 0  IDCODE: 5BA00477  Device: Unknown Device

        |

TDI -----

We tried running scanboard on both rdb and our custom board with TBSCAN_EN_B=0, we got different results.

LS2085A_RDB (TBSCAN_EN_B=0)

===========================

TDO -----

        |

        * Device 0  IDCODE: 0A01E01D  Device: Unmapped FSL Device

        |

TDI -----

Our board (TBSCAN_EN_B=0)

=========================

TDO -----

        |

        * Device 0  IDCODE: 0A01801D  Device: Unmapped FSL Device

        |

TDI -----

Do you have any clue with respect to JTAG connectivity issue?

Thanks

Rams

[ramasubramanian]

Yes, we verified RDB SW3{1:8] + SW4[1] settings against our RCW and it matches.

We ran the CCS commands on the ccs console on our custom board.  It failed in config_chain command.  We could run all the commands on RDB.

(bin) 39 % config cc cwtap:10.10.48.78

(bin) 40 % show cc

(bin) 41 % ccs::config_server 0 1000

(bin) 42 % ccs::config_chain {ls2085a dap}

SAP2: HRESET occurred during transaction

(bin) 43 %

Thanks

Rams

[marius_grigoras]

One more thing please, can you try next commands also from ccs to be sure there is no qixis in the chain?

dele a

config cc cwtap:fsl03af0a

ccs::config_server 0 20
ccs::config_chain testcore
jtag::lock
jtag::reset_tap 1
jtag::scan_io ir 64 -1

tag::unlock

Thank you,

Marius

[ramasubramanian]

Hi Marius,

Please find below the output

(bin) 4 % dele a

(bin) 5 % config cc cwtap:10.10.48.78

(bin) 6 % ccs::config_server 0 20

(bin) 7 % ccs::config_chain testcore

(bin) 8 % jtag::lock

(bin) 9 % jtag::reset_tap 1

(bin) 10 % jtag::scan_io ir 64 -1

0xFFFFFFFFFFFFFFF1

(bin) 11 % jtag::unlock

Thanks

Rams

[marius_grigoras]

Ok, thank you Rams. Seems to be fine from the QIXIS point of view.

After some debugging, seems that I can also reproduce your IDcode setting up the CFG_SVR[0:1] = 00 (from our SW configurations SW4[5:6] = 00, but the default should be 11).

So please make sure cfg_svr is 2'b11 and also check again all signals to be as requested by our board manual - to respect the personality and the board/SoC settings.

Regards,

Marius

[ramasubramanian]

Hello,

We pulled-up the CVG_SVR pins 0:1 which corresponds to CPU pins IFC_A10 and IFC_A11.  Hope it is correct.  It did not change the behaviour.  Still we get the same result.

We ran IDcode test with TBSCAN_EN_B with zero, we still got IDCODE: 0A01801D as opposed to 0A01E01D with RDB.

After these changes, should we get 0A01801D or 0A01E01D?

Thanks

Rams

[marius_grigoras]

Hi Rams,

Setting up CFG_SVR[0:1] = 11 should obtain 0A01E01D (as for RDB). Do you have any local FAE for taking a look?

Thank you,

Marius

[ramasubramanian]

Hi Marius,

We are looking into CFG_SVR[0:1] = 11 on our board.  But our observation was that changing this bits to 00, 10 or 01 in RDB does not cause JTAG connectivity issue.  We just get different IDCODE.  The problem may be not related to this.

Thanks

Rams

[marius_grigoras]

Hi Rams,

I have 2 more ideas:

1. Is the flash (that RCW source points to) empty? In this case, your behavior is normal and a workaround is to issue ccs::reset_to_debug and reconfigure chain, then perform RCW override. Please make next commands from ccs and let me know the output.

(bin) 703 % config cc cwtap:fsl03af0a
(bin) 704 % ccs::config_chain {ls2085a dap}
SAP2: HRESET occurred during transaction
(bin) 705 % ccs::get_config_chain  // Note:  SP is not in the chain
265 232 272
(bin) 706 % ccs::reset_to_debug   
(bin) 707 % ccs::get_config_chain
265 232 272
(bin) 708 % ccs::config_chain {ls2085a dap} 
(bin) 709 % ccs::get_config_chain  // Note: SP is in  the chain.
265 247 232 272
(bin) 710 % display ccs::read_reg 0 rcw_src 1 

2. You said above:

"

We pulled-up the CVG_SVR pins 0:1 which corresponds to CPU pins IFC_A10 and IFC_A11.  Hope it is correct.

"

but in the RDB manual says:

CFG_SVR0 IFC_A0 DIP-SW4[5]

CFG_SVR1 IFC_A1 DIP-SW4[6]

So check again those signals.

Thank you,

Marius

[perdalen]

1) I think we have not been able to connect to target.  Our flash is empty.  We are trying to override our emulator reset logic.  Also, please clarify on the oscillator termination question in my previous post.

(bin) 39 % config cc cwtap:10.10.48.78

(bin) 40 % ccs::config_chain {ls2085a dap}

SAP2: HRESET occurred during transaction

(bin) 41 % ccs::get_config_chain

265 232 272

(bin) 42 %  ccs::reset_to_debug

LS2085A: Core not responding

(bin) 43 % ccs::get_config_chain

265 232 272

(bin) 44 % ccs::config_chain {ls2085a dap}

SAP2: HRESET occurred during transaction

(bin) 45 % ccs::get_config_chain

265 232 272

(bin) 46 % display ccs::read_reg 0 rcw_src 1

HRESET occurred during transaction

2)  Yes, we realized the mistake and are now looking into IFC_A0 and IFC_A1

Thanks

Rams and Per

[ramasubramanian]

Hello Marius,

We are unable to get different IDCode when we try to pull up or down IFC_A0 & IFC_A1. 

1) Does this give you any clue that CPU is still in abnormal state ?

2) When IDCODE instruction is executed, the Device ID Code Register may be read right?

IDcode register might contain version bits, part number bits and manufactured ID bits etc.

But the version bits CFG_SVR0 and CFG_SVR1 which becomes part of IDCODE.  CPU will read these bits during Power-On-Reset sequence.

If CPU has still not finished Power On Reset sequence , it may not fetch these values correctly.  Please correct me if I am wrong.

Does this give you any hint to the issue?

3) You had asked to set useSafeRCW to True in the target init script.  Do you mean that we will not be able to connect to the target if there is no RCW.

When the flash is empty, we should still be able to connect to target if we set useSafeRCW to True right?

Regards

Rams

[marius_grigoras]

Hi Rams,

1 & 2 - I'm afraid these information doesn't help too much.

3. Yes, using useSafeRCW set to True will help to override the RCW (even this is empty), but this doesn't work in your case due of the HRESET signal :smileysad:

From the last ccs commands, seems that SP (Service Processor) is not in the chain. Another thing that can help in your case is to use the reset button and then retry to make the above ccs commands.

Is there any reset button to force the board to complete reset sequence? If I remember correctly, the PASS/FAIL LEDs of the board all turn to “PASS” when I push the reset button. After the first chain configuration turns on some LEDs with FAIL (without SP on the chain). Then the second chain configuration work OK with SP, then RCW override worked. I see the same effect when we issue ccs::reset_to_debug for my local QDS board (all LEDs turn to “PASS”), so we can use it as a workaround.

Thank you,

Marius

[marius_grigoras]

Hi,

Can you please try another work-around/idea?

Please copy/replace the attached cwtap_ccs.gp (unzip first) over {CW_Layout}\Common\CCS\bin and after that re-try the bellow commands and share the output.

(bin) 703 % config cc cwtap:fsl03af0a

(bin) 704 % ccs::config_chain {ls2085a dap}

SAP2: HRESET occurred during transaction

(bin) 705 % ccs::get_config_chain  // Note:  SP is not in the chain

265 232 272

(bin) 706 % ccs::reset_to_debug   

(bin) 707 % ccs::get_config_chain

265 232 272

(bin) 708 % ccs::config_chain {ls2085a dap} 

(bin) 709 % ccs::get_config_chain  // Note: SP is in  the chain.

265 247 232 272

(bin) 710 % display ccs::read_reg 0 rcw_src 1

We disabled SVR read which may case sap error.

If this works, we will think of a better solution in software.

Thank you,

Marius

[ramasubramanian]

Hi Marius,

We tried the commands after updating the cwtap_ccs.gp. Please find below the output.

(bin) 39 % config cc cwtap:10.10.48.78

(bin) 40 % ccs::config_chain {ls2085a dap} CodeWarrior TAP executable differs from local file.

CodeWarrior TAP Boot Loader version 1.0.1 CodeWarrior TAP OS version 1.0.4 Sending code to CodeWarrior TAP.........done Running package script

DAP: HRESET occurred during transaction

(bin) 41 % ccs::get_config_chain

265 247 232 272

(bin) 42 % ccs::reset_to_debug

LS2085A: Core not responding

(bin) 43 % ccs::get_config_chain

265 247 232 272

(bin) 44 % ccs::config_chain {ls2085a dap}

DAP: HRESET occurred during transaction

(bin) 45 % ccs::get_config_chain

265 247 232 272

(bin) 46 % display ccs::read_reg 0 rcw_src 1 HRESET occurred during transaction

(bin) 47 %

1) Could you please clarify on one thing, i sthat possible to connect JTAG if you dont have RCW or if the CPU tries to read RCW from flash which is empty.? Is that possible to bypass reading RCW from flash and use the user provided one?  You gave us option to define UseSafeRCW = True, but that did not solve?  How do we know that it is stick in reading RCW phase?

2) Have you tried erasing RCW on the eval kit and managed to connect JTAG?

Lennart Svensson is our FAE and he is aware that you are helping us.  He is going to check with Austin team on this.

Thanks a lot for your support

Rams

[marius_grigoras]

Hi,

Thanks for trying. So at the final command where try to read the rcw_src you get HRESET again? :smileysad:

1. Is still possible to connect via JTAG even if there is no RCW on the boot rom location if the rcw override mechanism is working (via ccs/debugger). This is what we're trying now with all these above ccs commands and we try to avoid that HRESET signal.

2. Yes, of course. And using the RCW override feature does the trick.

Using the latest cwtap_ccs.gp, can you please try again the bellow ccs commands?

config cc cwtap:fsl036fc1 //here update with out cwtap hostname or simple use cwtap if the probe is connected via usb

show cc

ccs::config_server 0 1000

ccs::config_chain {ls2085a dap}

disp ccs::read_reg 0 0x1008 4

   rcw9=0x00000370   rcw10=0x00003201   rcw11=0x00000000   rcw12=0x00000000

ccs::write_reg 0 0x1008 0x170

disp ccs::read_reg 0 0x1008 4

   rcw9=0x00000170   rcw10=0x00003201   rcw11=0x00000000   rcw12=0x00000000

ccs::config_template 0 0x1000 1

ccs::reset_to_debug

ccs::all_run_mode

disp ccs::get_config_chain

Thank you,

Marius

[ramasubramanian]

Hi Marius,

Please find below the the output of the commands.

(bin) 24 % show cc

0: CodeWarrior TAP (cwtap:10.10.48.78) CC software ver. {0.0}

(bin) 25 % ccs::config_server 0 1000

(bin) 26 % ccs::config_chain {ls2085a dap}

DAP: HRESET occurred during transaction

(bin) 27 % disp ccs::read_reg 0 0x1008 4

HRESET occurred during transaction

(bin) 28 % ccs::write_reg 0 0x1008 0x170

(bin) 29 %

(bin) 29 % disp ccs::read_reg 0 0x1008 4

HRESET occurred during transaction

(bin) 30 %

(bin) 30 % ccs::config_template 0 0x1000 1

(bin) 31 %

(bin) 31 % ccs::reset_to_debug

LS2085A: Core not responding

(bin) 32 % ccs::all_run_mode

CortexA5: Execute Mode

(bin) 33 % disp ccs::get_config_chain

Chain Position 0: LS2085A

Chain Position 1: Cortex-A5

Chain Position 2: DAP

Chain Position 3: SAP2

Our POR configuration pins defaults to NOR flash.  If RCW fails, it will look for secondary source SFP OSPR1[BOOT_IMG_2] as defined in the Reference Manual. How do you actually override Service Processor reading RCW from flash.?  Is there any additional setting in ccs in addition to useSafeRCW?

Thanks

Rams

[marius_grigoras · Accepted solution]

Hi Rams,

I'm afraid that's all I can do from software side. The issue seems to be a design one.

Our ccs team is trying to reproduce something similar on our side and mostly the best we can do is a work-around more deep in the ccs low-level internals.

You can discuss further with your local FAE and also if he requires to submit a new case from nxp.com, please use next steps:

  1) Go to http://www.nxp.com/support/sales-and-support:SUPPORTHOME.

  2) On the bottom of the page under Submit New Issues, click Hardware & Software.

  3) Register with your business email to access NXP technical online support.

  4) A verification email will be sent to your account. Click the link embedded in that email to verify your access.

  5) On the NXP online support page, select Contact Support from the top menu and click “submit a new case” to start the process.

For the hw team will help also adding a link with this conversation.

Thank you,

Marius

[ramasubramanian]

Hi Marius,

Thanks a lot for your help in debugging.  We were able to connect to the board now.

There were couple of issues:

1) Single Ended SYSCLK

2) There were some power supply issues

And we used hardcoded RCW as suggested by you to finally connect to the target.

We are now trying to flash the RCW and U-boot.  We could verify that the images are flashed.  But we dont get to see U-boot started from our custom board.  I will open a new thread for this discussion.

Thanks

Rams

[ramasubramanian]

Hello,

We tried to run the JTAG  diagnostics test on LS2085Ardb(Reference Board), but we get error messages that it could not run low level JTAG diagnostics.

Thanks

Rams

[marius_grigoras]

Hi,

Are you using CW for ARMv8 11.2.0?

Turning back to your errors:

1. TBSCAN_EN_B = 1 - this should be by default 1 and means that the board is set up for DAP bus (ARM compliant). 5BA00477 - this is the ID for DAP.

2. 0A01E01D - this is boundary scan mode and means that TBSCAN_EN_B = 0.

Can you please attached here a picture with the results from JtagConDiag? Just copy/paste.

Have you tried an Inspect operation (this is similar with attach) + TBSCAN_EN_B = 1 ?

Thank you,

Marius

[ramasubramanian]

Hi Marius,

Thanks for the reply.  We were able to successfully run the JTAG diagnostics test on the LS2085A RDB from the Codewarrior GUI.  All tests passed.

When we ran the same on our custom board, it fails in "Connect to target" test.

Do you see a problem here??

Thanks

Rams