Dear All,
We have designed t2080 based custom board.
Processor is PORESET.
Trying to connect CW10.5 code warrior TAP to t2080.
If we run command source IDcode.tcl getting following response:
Getting T2080 Device id.
Then also run findcc cwtaps, delete all, config cc cwtap, ccs::config_chain t2080, ccs::reset_to_debug
Why T2080: Core not responding ?
Please let us know what could be issue?
We are using hard coded RCW as described in the T2080 reference manual section 4.6.4.1.1 Hard Coded RCW Options.
cfg_rcw_src[0:8] Encoding 0_1001_111x SYSCLK 133 MHz DDRCLK 66.7 MHz.
Thanks,
Vidya
Dear Yiping and Vidya,
I am also facing exactly same issue on custom board based on T1024.
Then I tried on T1024RDB (reference design board). I am getting same error. I cannot connect CW-TAP to target. Reported error:
Error launching Test_Connect1-core00_SRAM_T1024_Connect
CCSProtocolPlugin : Failed to reset the target
[CCS last error: T1020: Core not responding ]
Dear Vidya....
I have Reference Design Board plus recently manufactured custom board. I am facing this issue on both - rdb and on my custom board.... I have many dobuts:
Doubt-1: In RDB, When i load RCW from SPI flash (nand flash and nor flash is blank), i notice that RCW in register DCFG_CCR_RCWSR1 is different from the data in binary file. Why it is different, it should be same as that in binary file or in .txt file which override RCW
Doubt-2: In RDB, If i write NAND flash with u-boot image (spi and nor flash blank), u-boot do not run at all. What can be the reason.
Thanks in advance. You can also reply me on abhishekinmbm@gmail.com
Dear vidya,
I updated CodeWarrior and first issue was solved. My ultimate aim is to test discrete DDR3 interface on custom board. For this, I am first trying to run DDR-validation tool on T1024RDB. After that i will configure as per my custom board configuration. While testing with T1024, I have below issues unresolved:
1) If i program bootloader in NAND flash (SPI and NOR empty), RDB does not boot. There is no output on serial console. Swtich setting (cfg_rcw_src) is correct as per SPI interface. Right now I am proceeding with SPI flash.
2) DDR-V tool runs only after i load uboot. if i write only RCW (64 bye binary file with preamble and CRC) in SPI flash, DDR-V fails on RDB. What can be the reason?
Note that I tried to run tcl script to initialize DDR memory controller before running DDR-V tool so that DDR controller registers are initialised.
Once DDR-V tool is passed on RDB, then I will be able to test DDR3 interface on my custom board using DDR-V tool and 64 byte RCW binary file. Is my approach correct ?
I tried putting question on other thread but i am not able to understand all the issues.
You can also reply me on abhishekinmbm@gmail.com
Thanks & Regards,
Abhishek.
1). Please confirm whether board is T1024 is RDB or custom design board (Below block diagram does not contain NAND flash) ? If you are using custom board then please set NAND timing first in tcl file and verify the read/write by using CW.
2). DDR-V do not need u-boot for discrete DDR3 validation, keep your DDR-V setting and skew values are correct as per your discrete component and hardware design respectively, if your hardware configurations are correct, there is no reason DDR-V will fail.
hiii.....
RIght now I am trying everything on RDB. Custom board testing will be 2nd step in future.
Kindly note below:
1) On RDB, I have erased and programmed uboot into NAND flash using Flash programmer. I erased SPI and NOR flash. Now I cannot booth from NAND flash even though switch settings are correct.
2) On RDB, DDR-V is not working if I write only RCW (preamble + 64Byte RCW + CRC) in SPI Flash.
Regards,
Abhishek
1). Have you verified NAND flash after writing u-boot by using CW, does it return written value from NAND flash, try to read the appropriate u-boot location for verification ?
2). RDB contains SODIMM, So set the DDR-V tool parameter for SODIMM, there is no other cause DDR-V tool does not work.
Dear Yiping,
Hello Vidya,
Please check whether your JTAG interface hardware design is similar as the following
HRESET exclusive to COP/JTAG header: problems arise when the core is reset and the debugger doesn’t know about it
Usually the debugger will report the processor can not be put into STOP mode
Thanks,
Yiping