CCS5 keeps hanging during debug of Tiva LaunchPad

Hello Janos,

Typically these issues arise if the JTAG IO's are reconfigured or if the JTAG Frequency drops below 1/10 of the System Frequency. Can you elaborate on the program code or reproduce the issue during a specific execution. That would be helpful for us to support you.

Regards

Amit

Hi Amit,

thank you for your quick post! This kind of problem is probably nasty to get behind, but as you say "these issues typically arise" there may be even hope for me :-). Being asked for a concrete example, the IDE of course worked perfectly fine today, not showing it's trouble side. But then i got it also in a simple example.

In this example i basically print "Hello World" via 115200baud UART, directly from my target board into an FTDI, and then read out some sensor registers over I2C. The program would then run uselessly in the main-loop, but the IDE hang already when i stepped and held at the line "while(1) {". What i did precisely was:

1. Launch the debug session
2. Single-step to the line "i2c_readRegisterRange(SLAVE_ADDR, 0x00, 15, buf);"
3. Single-step one more line to "while(1) {"
4. Went to my logic analyzer program, analyzed for about 60 seconds
5. Came back to the CCS IDE
6. Tried to quit the debug session, and realized that it was hanging. In this case i was glad to catch an easy error-case, but usually this is when the fun ends.

Here is the code i'm running.

void ConfigureUART(void) {
	SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
	SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);
	GPIOPinConfigure(GPIO_PA0_U0RX);
	GPIOPinConfigure(GPIO_PA1_U0TX);
	GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);
	UARTClockSourceSet(UART0_BASE, UART_CLOCK_PIOSC);
	UARTStdioConfig(0, 115200, 16000000);
}

int main(void) {
	FPULazyStackingEnable();
	SysCtlClockSet(
			SYSCTL_SYSDIV_4 | SYSCTL_USE_PLL | SYSCTL_XTAL_16MHZ
					| SYSCTL_OSC_MAIN);

	ConfigureUART();
	UARTprintf("Hello, world!\n");

	uint8_t buf[16];
	i2c_init(true);
	i2c_readRegisterRange(SLAVE_ADDR, 0x00, 15, buf);

	while (1) {
	}
}

Does this give any more clues? What else can i try to surround the problem?

Thanks for your support!

Cheers

Janos

Hello Janos,

The program is correct and does not fall in the bucket of "usual suspects". In the steps you mentioned, when you single step into while(1), was the CCS still working fine and you were able to read peripheral registers or for that matter SRAM or System Control Address Space?

1. Launch the debug session
2. Single-step to the line "i2c_readRegisterRange(SLAVE_ADDR, 0x00, 15, buf);"
3. Single-step one more line to "while(1) {"
4. Went to my logic analyzer program, analyzed for about 60 seconds
5. Came back to the CCS IDE
6. Tried to quit the debug session, and realized that it was hanging. In this case i was glad to catch an easy error-case, but usually this is when the fun ends.

Also what is the JTAG frequency as per the CCSXML file? By default it should be 1MHz.

It looks to be a CCS Issue and I would suggest a CCS uninstall and re-install to remove this possibility.

Regards

Amit

Hi Amit,

it took me some time to follow such a little promising suggestion as re-installing the CCS. And infact, as expected, it did not help.

To answer your questions:

- Yes, as long as the CCS works fine, i can access everything it allows me to. (I don't know about System Control Address Space, but registers, variables and watch expressions work).

- The JTAG frequency is 1MHz. When checking that, i noticed that i didn't have the TM4C1231H6PM set as the target, but the TM4C123GH6PM. But correcting that also didn't solve it.

May the problem be in my LaunchPad<->Target-Board connection? I am using a solid cable of abut 10cm (4 inch) length. I have connected GND, TCK, TMS, TDO and TDI. Not connected is RESET or the target power supply. My target runs on 3.3V, as does the LaunchPad.

What else can i check before the next steps may be re-installing the operating system and getting a new computer ;-)?

Cheers

Janos

Hi Janos,

Of course re-installing the OS or a new PC is something I will not suggest :-)

I have had seen problems with CCS earlier and re-installing made it go away as have on some E2E threads.

I have run free wire cable between boards of over 6" w/o problems, but then never used it for a long debug which is your case. Connecting Reset may be a good idea but then the DK board does not give out a Reset to the main Tiva either. If you can use the main Processor for further debug and not see any issue then it can be probable that there is some cross talk between the wires for the other 4 lines.

Another thing could be coil a GND wire around the JTAG debug lines, or if possible use shielded wires.

Regards

Amit

Amit,

i am so glad about what i finally discovered now:

I experienced the same faulty behaviour as described above, by only debugging the TIVA LaunchPad EK-TM4C123GXL itself. Nothing else, no additional wires, no thing connected to it. Just the single LaunchPad connected to the PC, and as soon as the i entered the main-method in the debugger, and did the first "Step over" (F6), it hang and i got this in the Console output:

CORTEX_M4_0: GEL Output: 
Memory Map Initialization Complete
CORTEX_M4_0: Trouble Reading Memory Block at 0x6e8 on Page 0 of Length 0x16: Timed out while waiting for target powerup/polling a hardware resource.
CORTEX_M4_0: Trouble Reading Register SP: Timed out while waiting for target powerup/polling a hardware resource.
CORTEX_M4_0: Error: Timed out while waiting for target powerup/polling a hardware resource.
CORTEX_M4_0: Failed to remove the debug state from the target before disconnecting.  There may still be breakpoint op-codes embedded in program memory.  It is recommended that you reset the emulator before you connect and reload your program before you continue debugging

This certainly tells me that something is really wrong with the Code Composer Studio, or the LaunchPad! It cannot have only to do do with the connection and maybe wiring of my target, which would have anyway highly surprise me because i have done that before plenty. But i seriously cannot believe that i would be the only/first one to see it on the LaunchPad. So what can it be?

Again, the only way to get the hanging Code Composer out of it's hanging state is to reset the LaunchPad. I do this (by now) by switching the Switch on the LaunchPad to "Device", and then back to "Debug".

May this be a ICDI firmware problem on the LaunchPad? Are there updates which i may have missed?

Or is it may be a USB problem, perhaps a Windows driver problem? Or is it maybe problematic that i'm connecting the LaunchPad through a USB hub? I have to do that, it is cable-wise the only way to connect it for me.

The code i discovered the error with this time (and it really happens every other attempt, normally!), is the one you know from my post "Unlock of NMI/JTAG pins: Unspecified behaviour?" (thanks again for your help there!):

#include <stdint.h>
#include <stdbool.h>
#include "inc/hw_memmap.h"
#include "inc/hw_types.h"
#include "inc/hw_gpio.h"
#include "driverlib/gpio.h"
#include "driverlib/sysctl.h"

#include "tivaware_util.h"

int main(void) {
	SysCtlClockSet (SYSCTL_SYSDIV_4 | SYSCTL_USE_PLL | SYSCTL_XTAL_16MHZ | SYSCTL_OSC_MAIN);

	SysCtlPeripheralEnable (SYSCTL_PERIPH_GPIOD);		// Enable PORT-D peripheral
	GPIOPinUnlockGPIO(GPIO_PORTD_BASE, GPIO_PIN_7);		// Unlock the PD7 GPIO
	GPIOPinTypeGPIOOutput(GPIO_PORTD_BASE, GPIO_PIN_7);	// Configure PD7 as output

	while (1) {
		// Some toggling
		GPIOPinWrite(GPIO_PORTD_BASE, GPIO_PIN_7, GPIO_PIN_7);
		GPIOPinWrite(GPIO_PORTD_BASE, GPIO_PIN_7, 0);
	}
}

This behaviour of the CCS is really getting frustrating, and i need a solution there soon...

I still hope there is help!

Thanks
Janos

Hello Janos,

Could you change the SysCtlClockSet to use the PIOSC instead of MAIN OSCILLAOTOR?

Regards

Amit

Hi Amit,

i could test the LaunchPad and my application only occasionally with the PIOSC source, because the frequency is too low for my needs. But occasionally, i did initialize the CPU with

SysCtlClockSet(SYSCTL_SYSDIV_4 | SYSCTL_USE_OSC | SYSCTL_XTAL_16MHZ | SYSCTL_OSC_MAIN);

I am not completely sure, but i think i haven't seen any problems then. (It's really difficult to tell, because the error behaviour is of these kinds which don't show if you want to see them). Anyway, it looks ok like that.

What could this mean? Is there someting wrong with the 16MHz crystals? Remember, i also have the IDE hanging when i'm debugging the LaunchPad only.

One more thing to what you wrote above:

Amit Ashara said:

Typically these issues arise if the JTAG IO's are reconfigured or if the JTAG Frequency drops below 1/10 of the System Frequency

Is this maybe worth considering another look? Isn't 1 MHz already below the PIOSC source of at heighest 16 MHz, and way below my target frequency of 50 MHz and 80 MHz?

I have also found http://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/t/263469.aspx, may this be related to my problem?

Cheers

Janos

Hello Janos,

I think trying the PIOSC instead of the MOSC as the clock source would help eliminate a flaky crystal. Other than 1MHz should be good if the System Clock is used as 16MHz or above.

Regards

Amit

Hi Amit,

Amit Ashara said:

I think trying the PIOSC instead of the MOSC as the clock source would help eliminate a flaky crystal.

Ah i think i understood the clock settings complete wrong. Should it be something like this?

SysCtlClockSet(SYSCTL_SYSDIV_4 | SYSCTL_USE_PLL | SYSCTL_XTAL_16MHZ | SYSCTL_OSC_INT);

I will try this for a while, and i'm sure i will see results quickly.

Amit Ashara said:

Other than 1MHz should be good if the System Clock is used as 16MHz or above.

Do you know of any frequencies that would be worth trying out?

Cheers

Janos

Hello Janos

That is correct for using the PIOSC as the clock source. Generally PIOSC and above is good for 1MHz JTAG Clock

Regards

Amit

Hi Amit,

it is very difficult to tell, but i _think_ since i have used the PIOSC i didn't see the Debug session hanging no more. If that was the case, what would it mean? That both the crystals, mine and the one on the LaunchPad, appear "flaky"?

Amit Ashara said:

That is correct for using the PIOSC as the clock source. Generally PIOSC and above is good for 1MHz JTAG Clock

Regarding this, i still don't understand the relation between the JTAG, the crystal, and the system frequency. What does "PIOSC and above" mean? In order to track the problem in the direction of JTAG frequencies, could you _name_ a JTAG frequency that i should try out, assuming i have that 16MHz crystal and aim at operation frequency of 80MHz?

I recently discovered a CCS setting, which i'd like to ask you if you can verify if it is correct: It is the crystal frequency in

Project-settings->Debug->Tiva Flash Settings->Flash Settings->Crystal Frequency: (MHz)

It is set to "8" (8MHz). Is this correct?

On another note, i have now surprisingly managed to bring my on-board FTDI JTAG debugger into play, and so far it is looking pretty good. It is a copy of some older Stellaris launchpad or development board design from TI. It will take me some hundreds debug cycles, after which i can tell if the hanging CCS Debug session situation shows up. If it doesn't, there must be a problem with the LaunchPad ICDI. Let's see, i will keep you updated here.

Thanks for your support again, i really appreciate you guys running this community!

Cheers,

Janos

Hello Janos,

Crystal in two different boards (LaunchPad and your custom board) being flaky is a remote possibility. Can you check the DataSheet's electrical section for the part on TI website to see if the crystal meets the requirements for the custom board.

The JTAG frequency has to be 1/10 of the System Frequency. So if System Frequency is 16MHz PIOSC then it can be a max of 1.6MHz

Again do check the electrical section of the data sheet for the maximum JTAG TCK that has been characterized. The TCK cannot be always 1/10 of System Frequency and this parameter is the MAX bound on this frequency of JTAG.

The CCS setting allows an automatic TCK limit of 1/10 of System Freq (in this case 800KHz).

Regards

Amit

Janos said:

it is very difficult to tell, but i _think_ since i have used the PIOSC i didn't see the Debug session hanging no more. If that was the case, what would it mean? That both the crystals, mine and the one on the LaunchPad, appear "flaky"?

Hi Amit,

this has been a while, but i wanted to give brief feedback.

I have been using my custom FTDI programmer (the one from the Stellaris reference design) for quite a while, and quite intensive, and haven't had hardly any problems with it.

Now i'm back doing some evaluation with the LaunchPad (EK-TM4C123GXL), with the clock settings from above that we had put our hopes in (SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_OSC_INT | SYSCTL_XTAL_16MHZ)), but the CCS keeps crashing every other time. I have nothing more connected to the LaunchPad than the logic analyzer probes.

For me this concludes that there is something essentially wrong with the LaunchPads ICDI interface, or the Windows driver for it. I'm very anstonished that this has never been a issue here really, and it's hard to see how other people would get around it, without noticing it. But I don't see how the trouble could come from my setup. I basically have the reference environment here with Windows 7, CCS 5 and the LaunchPad. So if i'm not missing some important LaunchPad firmware update, i'd have to say that the ICDI only works sometimes.

Cheers

Janos

Hello Janos,

I am also facing the same problem. Can you provide details for  the ICDI driver you are using and  FTDI programmer. I also want to develop my own programmer for TIVA 123 and 129.

Thanks,

Dhanush