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
Solved! Go to 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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