TMS320F28388D: Unable to attach to running ControlCard using XDS110 and Code Composer Studio 10.1

Hi Nik,

Did you connect the XDS110 probe connector to the target before powering up the control card or after powering up control card? If it was after powering up the control card, can you try attaching the probe connector first and then powering up the control card?

Thanks,

Ashwini

Hi Ashwini,

I physically connected the probe to the target before powering up the target. I assume that since I did it the way you suggested already, I shouldn't try it the other way? To be honest, I would be scared to do it in the opposite order!

Thank you for the suggestion.

Regards,

Nik

Hi Nik,

You did the right thing, and yes please do not try the other way around. I will investigate how to connect to a running target without resetting it and let you know what I find.

Thanks,

Ashwini

Hi,

In CCS Gel file we have reset function call inside OnTargetConnect() function. You need to comment out that function call to avoid reset on target connect. You can find the Gel file in "<CCS_INTALL_FOLDER>\ccs\ccs_base\emulation\gel"

Regards,

Vivek Singh

Hi Vivek,

Thanks for the response.

Previously, I had changed my target configuration to remove the use of GEL files. I was hoping that by removing the GEL files, the debugger would perturb the system less.

Now, following your suggestion, I've restored the GEL files, and started to customize the cpu1 gel file. I did as you suggested and removed the call to GEL_Reset() in OnTargetConnect(). That didn't seem to help, the CPU1 was still reset.

So I added some debug output to the GEL file. I can see that the OnReset() function is called after OnTargetConnect() finishes.

C28xx_CPU1: GEL Output:
 OnTargetConnect() finished
C28xx_CPU1: GEL Output:
 OnReset()

Does this imply that CCS chose to perform a reset even though the debug configuration has those boxes unchecked?

Looking at the GEL file, I realize that I have not been paying attention to "Realtime Mode". Should I have Realtime Mode selected prior to connecting? Or Polite Real Time mode?

Regards,

Nik

Nik,

Could you try by removing the flash programming DLL (FlashC2000F021.dll) at below path in your CCS installation folder?

\ccs\ccs_base\DebugServer\bin

Let me know if that helps.  It also issues a reset on target connect and hence suggested to remove this.

Note:  Please save the DLL so that you can place it back in the CCS folder to be able to program flash when needed.

Thanks and regards,

Vamsi

Thanks Nik. I did not know that you have already removed the Gel. Since you mentioned about Gel file removal step not working, I think we had an issue with driver which was forcing the reset on this device. We have recently fixed that issue but it's not yet released. Let me check with our CCS team on when this will be released and I'll get back to you.

Regards,

Vivek Singh

Hi Vamsi and Vivek,

I went ahead and tried Vamsi's suggestion of moving the driver.

The result is that after connecting to the running system, the Console output looks like:

C28xx_CPU1: GEL Output:
 OnFileLoaded()
C28xx_CPU1: GEL Output:
 OnTargetConnect()
C28xx_CPU1: GEL Output:
 OnTargetConnect() - NOT IN realtime mode
C28xx_CPU1: GEL Output:
Memory Map Initialization Complete
C28xx_CPU1: GEL Output:
 Suppressing call to GEL_Reset()
C28xx_CPU1: GEL Output:
 OnTargetConnect() finished
C28xx_CPU1: Error initializing flash programming: Failed to load C:\ti\ccs1010\ccs\ccs_base\DebugServer\bin\FlashC2000F021.dll: The specified module could not be found.
 

So that makes sense, if I understand correctly what you've told me. The fact that the Flash driver DLL is missing means that the target does not get reset.

But, what happens next isn't good yet. The debugger still says that "A Reset Occurred On The Target".

Then when I click the pause button, the processor is not executing my code. (My code is in Flash, so it should be 0x8xxxx.) It's actually executing in the bootloader (which makes sense, if a reset occurred, right?):

So I think I have other things to fix up. Maybe I need to discard my mods to the GEL file and start over, I might have broken something with my hacks.

Aha, instead I went back to just removing the GEL files from the target configuration. Seems like it works now! After I connect, CPU1 is still running. If I click pause, the debugger shows the core is running my code. I can single step, and resume, and pause again.

So, by following this process, attaching to a running target works for me:

• build my code with watchdogs disabled (I have been doing this all along, so this was never part of the trouble, just putting this here for anyone else who reads this later)
• create an alternate Target Configuration, which has the GEL file configuration deleted for CPU1, CPU2 and CM
• move the Flash DLL so that the debugger can't find it
• create a Debug Configuration that uses the alternate target configuration, and set that Debug Configuration up so it doesn't reset when it connects, etc. as described in the first post in this thread

Next steps for me include making sure that I can debug CPU2 and CM this way as well.

And on your side, please do let me know what the status of the fix for the Flash driver DLL is.

Thanks very much for your help, Vivek, Ashwini and Vamsi.

Regards,

Nik

Hi Nik,

Glad you got the sequence to work. I was able to do the same as well on my end.

I believe the fix has been included in CCS 10.3. I will give this a try and confirm to you by Monday.

Thanks,
Ashwini