Other Parts Discussed in Thread: UNIFLASH
Tool/software: Code Composer Studio
In setting up the scenario the specified controller is used on a custom board. The debugger is a Blackhawk USB-560M (cTI 20-pin header). Utilizing CCS v6.1 with TivaWare 2.1.4.178. A CCS project has been set-up to initially set-up the SSI peripheral to test communication to another device. The target configuration was left defaulted without any modifications. Upon connecting to the CORTEX_M4 through the debugger it was seen to be able to break at main(). Upon stepping through two functions the console reached a point shortly after attempting to step through or perhaps during the second function the Error -1170 Unable to access the DAP was seen. The following code segment shows the two instructions step through at the top of main()
ROM_FPULazyStackingEnable(); // Step through function 1 ROM_SysCtlClockSet(SYSCTL_XTAL_16MHZ | SYSCTL_OSC_MAIN | SYSCTL_USE_PLL | SYSCTL_SYSDIV_2_5); // Step through function 2
Upon resetting the board through a power cycle and attempting to the CORTEX_M4 the Error -1170 continually appears before even being able to load a program. After launching the configuration and showing all cores an attempt has been made to connect to the CS_DAP which has been repeatable to successfully connect "(Unconnected)" text is no longer present. Upon attempting to disconnect the CS_DAP and connecting to the CORTEX_M4 the Error -1170 appears again. Once an Error -1170 error has occurred the error is seen again on any attempt to connect to the CS_DAP. Only upon a power cycle will the CS_DAP connection be successful. On occasion, the Error -10363 has been seen on both CS_DAP and CORTEX_M4 connection attempts.
Various TI documentation sources have been examined for possible implementation error on this board:
SPMA075 "Using TM4C12x Devices Over JTAG Interface"
SPRU655I "Emulation and Trace Headers"
Along with the controller datasheet
With the above information the following things have been reexamined:
Trying slower TCK clock speeds of 100KHz, 1.0Mhz
- Running the "Test Connection" for the IR and DR integrity-scan test has returned successful results with no failures. This has been run multiple times and no has error has ever been seen.
- The 20-pin cTI connector header connections have been reexamined to match those specified in SPMA075 along with extra guidelines on TDO and TCK trace length and impedance. The TCK/RTCK are implemented with the 22-ohm series resistance.
- The VDD, VDDA, VDDC voltages have been examined and found with no issue.
- OSC0 was originally unconnected as the internal 16 MHz oscillator is being utilized, but this pin has since been tied to GND.
- The external reset pin is controlled via an FPGA with LVTTL logic levels and has an internal weak pull-up being utilized rather than an external pull-up. Once the FPGA is configured the controller is allowed to be brought out of reset. This has been examined to adhere to the minimum 250 ns active-low timing needed before bring logic level back high
In the end, the Error -1170 has is a reoccurring roadblock. After revising the JTAG hardware and controller pin set-up I cannot find anything else to examine with the hardware itself nor am I sure of other aspects to examine that might have been related to the program due to those two instructions. A suspected idea might be a "locked" controller. However, with the given information I am not certain how that might have occurred. In any case, the SPMA075 document refers to the XDS560 not supporting the unlock feature.
