TMS320F28388S: Multi Core Debugging With CCS 12.8.1

Hi Ed ,
Please expect a delay in response.
Regards,
Lakshya

Hi Ed , 
Can you please share the ccxml and gel file which you used for CCS 10.4.2

Hi Lakshya,

                Our GEL files have not changed since we stopped using 10.4.2.  The system would not let me upload the ccxml, so I zipped the two files together.  The GEL file is what we are using on the CM core, with the memory initialization removed to protect us.  But the symptom does not change with the removal.  I also attached the ccxml for the project I am trying to attach with.  As you can see, there is nothing in the GEL script.  Maybe that’s the issue?

Another data point:  If I attach just the CM core project to a running system, I can see the CM’s GEL file executing and the CM core is running in the neighborhood of 0x00001816 in the TI Bootloader.  When I attach to both the C1 and CM cores, I do not see the CM’s GEL file executing, and the CM core is stuck at 0x00000000.

Thank you,

Ed

5488.Files.zip

Hi Ed,
As mentioned by you , you are using this almost empty gel script for CM core.
Are you using default gel script for core 1 project?

I will try to replicate this using some C2000 SDK multi core example and will get back to you.

Hi Ed,

Are you using flash configuration for both the cores?

Yes we are!

BTW, I may not be able to reply for a couple of weeks, so don't expect anything quickly.  Once I get back, I will be able to respond.

Thank you,

Ed

Hi Ed ,

I am using F28338D and CCS 20.3.1 . 

I am using project led_ex1_c28x_cm_blinky_cm and C:\Users\a1251238\Projects\E2E\multicore_f2838\led_ex1_c28x_cm_blinky_cpu1 from SDK .

In the target configuration, i am using the empty GEL script shared by you for both CPU1 and CM core.

‘Halt the target on a connect' option in unchecked

I am able to connect well, can you try testing on the above example, if you are facing this issue? 

Ed Sanders said:

I am successfully connecting to Core 1, but the connection to the CM core is causing that core to be reset and be stuck at address 0.

Here you are talking about CM core or CPU1 ?

Note - We have stopped support for CCs version 10.4.2   .

Regards,

Lakshya

Hi Lakshva,

                We are using the F28388S (I don’t know if F28338D was a typo), and CCS 12.8.1.  We had been using CCS 10.4.2 for years, and it worked well for us.  But because of the discontinuance of support for that version, we moved to 12.8.1, and now we are trying to get it to work the same way as 10.4.2.  One of the features we use a lot is the ability to attach to a running system without disturbing it.

Thank you,

Ed

Hi Lakshya,

                If you like, I can answer the first question in a private conversation.

                When we first started this project, until our HW arrived, I used a 388 eval board which uses a 388D.  I was able to debug both cores without any issues.  I don’t recall if I connected unobtrusively, but I think I may have because I prefer to debug that way.  So, there may be a difference between the 388D and the 388S from CCS’s point of view.

                But we think we have found a workaround for this issue.  If we delete the GEL files in the Target Configs, and delete the project in the Debug Configuration, it will attach without disturbing the system.  We can then manually connect and load the appropriate symbols.

                In the Target Configuration, when we delete the GEL file we normally use, it is ultimately replaced with “..\targetConfigs”.  Is that simply referring back to the project’s targetConfigs folder?  It has no GEL script, and so presumably, the connecting process does nothing?

Thank you, 

Ed

Hi Ed, 
Currently I have 388D only, I checked with CCS20.3.1 and it was working fine.
There should not be amu difference in nature of CCS with respect to 388D and 388S from debugging point of view.
I will test 12.8.1 with 388D, if it didn't work like 388S like you described, then we can conclude there may not be any difference between 388D and 388S and its probably some bug in 12.8.1 version.
I will let you know the updates.
Regards,
Lakshya   

Thank you for staying on it...

Regards,

Ed

Hi Ed, 
I used CCS 12.8.1 , and executed same experiment to check the resetting of CPU1 core when we connect to CM core during debug session.
It didn't reset the CPU1 core.
I am using your GEL scripts which you shared  , for both CPU1 and CM core in target config.
I did this experiment on 388D.
 

I used the multicore blink example from the C2000 SDK, which involves the CPU1 and CM cores.

To check whether the CPU1 core resets, I did the following:

In the CPU1 example, I added an empty while loop just before the LED blink loop. Because of this, the corresponding LED does not blink unless the loop condition is explicitly changed during the debug session.

When both projects are flashed, only the LED corresponding to the CM core project blinks. The CPU1 core LED does not blink because it is stuck in the empty loop.

After starting a project-less debug session and connecting to the CPU1 core, I loaded the symbols and changed the loop condition so that the program enters the LED blink while loop. After doing this, both LEDs start blinking.

Next, when I connect to the CM core and load the symbols, I still observe both LEDs blinking. This indicates that CPU1 did not reset.

There should not be any difference in behavior between the 388D and 388S devices regarding this. However, I will still check internally to confirm if there is any device-specific difference that could lead to this behavior.

It would also be helpful if you could share a sample project where you observe the CPU1 core getting reset when connecting to the CM core.

Have you tried new versions of CCS , do you also observe same issue there ?

Hi Lakshya,

Sorry for the tardy response.  I couldn't get into the website until now.

We tried CCS theia, but ultimately decided to use CCS 12.8.1, so I don't have any data for you from that version.

Sorry,

Ed

Hi Ed ,
By data I meant any multi-core example which can showcase this phenomenon of resetting because I tried reproducing this on theia as well as 12.8.1 .
In both. my core didn't reset. The example project is agnostic of CCS version.

Ed Sanders said:

The GEL file is what we are using on the CM core, with the memory initialization removed to protect us. 

I assume you have a custom GEL file outside the CCS directory that you have been using as your start GEL file. This GEL only defines StartUp() to set up the memory map and that is it? Does your GEL include any other GEL files?

Ed Sanders said:

In the Target Configuration, when we delete the GEL file we normally use, it is ultimately replaced with “..\targetConfigs”.  Is that simply referring back to the project’s targetConfigs folder? 

It is a default placeholder when there is no GEL file. It doesn't really make sense and I believe we cleaned that up in CCS 20. 

Note that the relative path root for GEL files in the ccxml file is some location inside the CCS install directory. I think it is <CCS INSTALL DIR>\ccs\ccs_base\common\targetdb. Or it might be some folder inside "DebugServer". I'm not sure exactly which one but it is not the project folder root.

OK.  Thank you Ki.

Ed

That is correct.  Right now, by design, it contains nothing so that it doesn't interfere with anything.