CCS/TMS320F280049C: CLA - Display variables in debug mode

Hello,

There is a difference in debugging on C28x vs CLA. On C28x, when stepping through the code, it flushes the whole pipeline, where as on CLA it does not flush the pipeline.

please refer to training video

https://training.ti.com/c2000-cla-c-compiler-part-4-debugging-ccsv5?context=1135305-1139285-31986

Hello,

Thanks for your help. I understand that there are differences in debugging C28x vs CLA.

However, I haven't the same behavior than on the video (about 4:40). During my test, the variables are always 0 in the tab "Expressions" during the CLA debug. I don't know why.

Moreover, can you confirm to me if we can read the MsgRAM in debug mode?

Yann

Yann,

Yes, I can confirm that I can read the variable in Cla1DataRam and Cla1ToCpuMsgRAM

Jha,

Do you have some ideas why I could not visualize data when I'm in CLA debugging mode: 

* CCS version?

* Debug probe?

* Debug configuration?

* Others

Thanks

yann

Yann,

Did you make any change in linker command file for cla (28004x_cla_ram_link.cmd) file? 

In the watch window in your setup, the variables are shown something like 0x00009001@Program. This does not look correct. It should be 0x00009001@data.

Please check the generated map file.

To be sure, I started from the last project of the cla_ex3_background_nesting_task. 

Then I added my variables for test as I explained in my first post. I also removed the comment on__mdebugstop(); in Cla1Task1.  Then I compiled it.

Here is the interresing part of the map file. It looks correct.

GLOBAL DATA SYMBOLS: SORTED BY DATA PAGE

address data page name
-------- ---------------- ----
00000400 10 (00000400) __stack

00001480 52 (00001480) u16CmpClaLoop_Cla1ToCpuMsgRAM

00001500 54 (00001500) u16CmpMainLoop_CpuToCla1MsgRAM

00009000 240 (00009000) u16CmpMainLoop_Cla1Data
00009001 240 (00009000) u16CmpClaLoop_Cla1Data

0000a800 2a0 (0000a800) u16CmpMainLoop_global
0000a801 2a0 (0000a800) u16CmpClaLoop_global

0000b378 2cd (0000b340) __TI_enable_exit_profile_output
0000b37a 2cd (0000b340) __TI_cleanup_ptr
0000b37c 2cd (0000b340) __TI_dtors_ptr
0000b37e 2cd (0000b340) _lock

0000b380 2ce (0000b380) _unlock

After flashing, connecting to CLA, loading symbols, running CPU and debugging CLA, I got the same result. I could not visualize variables  on CLA.

Thanks for your help

Yann,

I followed the same sequence as yours.

One extra-step I needed to do is as shown below in cla_ex3_background_nesting_task_cla.cla. I am sure you are doing it too to be able to compile. But just wanted to check with you.

extern uint16_t u16CmpClaLoop_Cla1Data;
extern uint16_t u16CmpClaLoop_Cla1ToCpuMsgRAM;
extern uint16_t u16CmpClaLoop_global;

Another difference is that I am running on Launchpad and ccs 9.2. I think it should behave same way.

Yes I did it

I asking myself if it's not a debug probe problem (configuration,...).

Your debug probe seems to be XDS110, my debug probe is a XDS100v2. Is there some specifics configuration?

Please refer to JTAG connectivity debug in the application note

http://www.ti.com/lit/an/spracf0/spracf0.pdf

Hi Jha,

I made some extras tests without success. I checked my JTAG probe. You could find below the Test connection report. What is your feeling about this report? Some tests have not been done (in bold below)

I also follow the following link https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/677001?Start-guide-for-the-above-TMS320-F280049M-Experimenter-s-Kit-for-C2000-Real-Time-Control-Development-Kits

I really don't know what to do to have JTAG debug working on CLA.

Thanks

[Start: Texas Instruments XDS100v2 USB Debug Probe_0]

Execute the command:

%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -F inform,logfile=yes -S pathlength -S integrity

[Result]

-----[Print the board config pathname(s)]------------------------------------

C:\Users\AL-YB2~1\AppData\Local\TEXASI~1\
CCS\ccs910\0\0\BrdDat\testBoard.dat

-----[Print the reset-command software log-file]-----------------------------

This utility has selected a 100- or 510-class product.
This utility will load the adapter 'jioserdesusb.dll'.
The library build date was 'Jun 3 2019'.
The library build time was '15:24:38'.
The library package version is '8.2.0.00004'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '4' (0x00000004).
The controller has an insertion length of '0' (0x00000000).
This utility will attempt to reset the controller.
This utility has successfully reset the controller.

-----[Print the reset-command hardware log-file]-----------------------------

The scan-path will be reset by toggling the JTAG TRST signal.
The controller is the FTDI FT2232 with USB interface.
The link from controller to target is direct (without cable).
The software is configured for FTDI FT2232 features.
The controller cannot monitor the value on the EMU[0] pin.
The controller cannot monitor the value on the EMU[1] pin.
The controller cannot control the timing on output pins.
The controller cannot control the timing on input pins.
The scan-path link-delay has been set to exactly '0' (0x0000).

-----[The log-file for the JTAG TCLK output generated from the PLL]----------

There is no hardware for programming the JTAG TCLK frequency.

-----[Measure the source and frequency of the final JTAG TCLKR input]--------

There is no hardware for measuring the JTAG TCLK frequency.

-----[Perform the standard path-length test on the JTAG IR and DR]-----------

This path-length test uses blocks of 64 32-bit words.

The test for the JTAG IR instruction path-length succeeded.
The JTAG IR instruction path-length is 6 bits.

The test for the JTAG DR bypass path-length succeeded.
The JTAG DR bypass path-length is 1 bits.

-----[Perform the Integrity scan-test on the JTAG IR]------------------------

This test will use blocks of 64 32-bit words.
This test will be applied just once.

Do a test using 0xFFFFFFFF.
Scan tests: 1, skipped: 0, failed: 0
Do a test using 0x00000000.
Scan tests: 2, skipped: 0, failed: 0
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 0
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 0
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 0
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 0
All of the values were scanned correctly.

The JTAG IR Integrity scan-test has succeeded.

-----[Perform the Integrity scan-test on the JTAG DR]------------------------

This test will use blocks of 64 32-bit words.
This test will be applied just once.

Do a test using 0xFFFFFFFF.
Scan tests: 1, skipped: 0, failed: 0
Do a test using 0x00000000.
Scan tests: 2, skipped: 0, failed: 0
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 0
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 0
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 0
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 0
All of the values were scanned correctly.

The JTAG DR Integrity scan-test has succeeded.

[End: Texas Instruments XDS100v2 USB Debug Probe_0]

Hi Yann,

These prints are normal.

Today I tried the same experiment on Launchpad-F28379D, as it has xds100v2. With that emulator, I am seeing the same behavior as yours. At this moment, I am not sure if it is JTAG issue or CCS display issue or CLA access to MsgRam. I am consulting to CLA expert. I will update you tomorrow.

Yann,

It loos like there is a core security issue. Please refer to 

https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/699278?TMS320F28377D-CLA1-couldn-t-read-write-to-assigned-LS-memory-#pi320995=2

In my code, I did following change in linker command file:

Cla1Prog         : > RAMLS0,           PAGE = 1

Also for memory configuration, 

MemCfg_setLSRAMMasterSel(MEMCFG_SECT_LS0, MEMCFG_LSRAMMASTER_CPU_CLA1);
MemCfg_setLSRAMMasterSel(MEMCFG_SECT_LS1, MEMCFG_LSRAMMASTER_CPU_CLA1);
MemCfg_setLSRAMMasterSel(MEMCFG_SECT_LS2, MEMCFG_LSRAMMASTER_CPU_CLA1);
MemCfg_setCLAMemType(MEMCFG_SECT_LS0, MEMCFG_CLA_MEM_PROGRAM);
MemCfg_setCLAMemType(MEMCFG_SECT_LS1, MEMCFG_CLA_MEM_DATA);
MemCfg_setCLAMemType(MEMCFG_SECT_LS2, MEMCFG_CLA_MEM_DATA);

With these changes, it works as expected. 

Hi Jha,

I'm not sure to understand what is the problem and what is the workaround. LSRAM0 is already set as MEMCFG_CLA_MEM_PROGRAM in my software example. The only difference is the page number but according to me it's only an information inside the linker. I made another test by setting CLA program in LS4 and CLA ram in LS5/LS6 but I got the same problem. By problem, I mean:

* I was not able to display in Expressions tab all the variables when using the CLA debug. They are still at 0.

* I was not able to display variables set in MSGRAM. I got the following message: Memory map prevented reading 0x01500@Program / Memory map prevented reading 0x01480@Program

Here is my full project in attachment. Thanks for helping

cla_ex3_background_nesting_task.7z

Yann,

Can you try CLA C compiler

// Project Properties -> C2000 Linker -> Advanced Options -> Command File
// Preprocessing -> --define

Add "CLA_C" and rebuild the project.

Hi Jha,

I assume the linker preprocessor command is for the linker. There is not "CLA_C" in my linker file so it will not have any effect.

To be sure, I tested. I still get the problems.

As you told me on 30 Jan 12:24AM, can you confirm to me that you get the problem (no display in CLA and/or no display MSGRAM) on the  Launchpad-F28379D with xds100v2 debug probe? How did you solve this?

Did you get an answer of the CLA expert? 

Did you try with my project?

Do you think that if I re-install CCS it could solve the problem? I would prefer to not doing this action but ...

Yann,

cla_ex4_debug_variable.7z

Yes, I am able to run your project with changes in linker file. Here is the modified project. Can you try that?

Yann,

I tested it again on my setup. I am using on Launchpad F28379D with XDS100v2, using CCS 9.2. Please try attached project. This has linker command file exactly like yours and the code files also. So there must be something else wrong on your setup.

2678.cla_ex4_debug_variable.7z

Which version of CCS you are using?

Also, I will recommend you to do through the debug steps mentioned in the e2e link I posted earlier.

Hi Jha,

Sorry for the delay, I was not available last days. I haven't Launchpad F28379D so I can't easily try your code.

I already tried the debug steps as you mentioned in earlier post. I also send you log files of the debug probe test. It seems OK.

I'm using CCS 9.1.0.00010.

As you told me on 30 Jan 12:24AM, can you confirm to me that you get the problem (no display in CLA and/or no display MSGRAM) on the  Launchpad-F28379D with xds100v2 debug probe? How did you solve this?

Best regards,

Yann

Yann,

At that time, I had wrong linker command file in my project.  

Cla1Prog  section in my linker command file was not in RAMLS0. It looks like that is not the case in your setup.

Please go through the link below. It goes through various debug steps you can try to narrow the issue.

https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/699278?TMS320F28377D-CLA1-couldn-t-read-write-to-assigned-LS-memory-#pi320995=2

Hi Jha,

At this moment, I don't know how to solve this issue. As a consequence, I will not use debug mode with CLA and/or will not use MsgRAM memory. I will see later if I have some times to spend to solve this.

Thanks for your help,

Yann