• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 244 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LAUNCHXL-F28379D: CCS20 How to Debug lab_cla_launchpad Tutorial Project

Bendik Mann
Prodigy 15 points
Part Number: LAUNCHXL-F28379D
Other Parts Discussed in Thread: C2000WARE, SYSCONFIG, TMS320F28379D, TMS320F28377D

Tool/software:

I am using CCS 20.1 and using the 'Project Wizard' I choose the 'lab_cla_launchpad' project. I then went into .syscfg and changed the device to the F29379D which is the device I have. Finally, I commented out the

__mdebugstop()
 in lab_cla_tasks.cla. After saving, I went into the 'Run' tab and pressed 'Debug Project'. 

Without connecting to the CPU1_CLA1, cla1Isr1 does trigger, however it does not seem to be processing 'real' data. As in, I have a signal generator setup on pin 10 of the launchpad (which I believe is ADCA0) and I do not see a change in filter_in or filter_out. 

Connecting to CPU1_CLA1 immediately halts the CLA and resuming causes it to immediately halt again. However, I do not see where (if anywhere) the debugger is pausing.

I have found one loosely related forum post from before about a work around in CCS8, but the instructions do not seem to align with what is possible in CCS20. I am hoping for a solution where I the __mdebugstop() instruction allows me to step through code on the CLA in this tutorial project. 

  • 0
    TI__Mastermind 20642 points

    Hi Bendik,

    Please take a look at the debugging section in the CLA software guide on how you can go about debugging on the CLA

    https://software-dl.ti.com/C2000/docs/cla_software_dev_guide/debugging.html?highlight=debug# 

    Take note that connecting to the CPU1_CLA1 core and loading symbols will allow you to step through code running on the CLA. An __mdebugstop() intrinsic is a CLA breakpoint. It will place the instruction MDEBUGSTOP at that position in assembly. If not connected to the CLA core (i.e. single step disabled), the intrinsic behaves as a MNOP (no operation)

    Regards,

    Ozino

  • 0 in reply to Ozino Odharo
    Prodigy 15 points

    Hi Ozino,

    Unfortunately, the documentation given seems to be for CCS that is Eclipse based. CCS 20 is the VS Code based IDE and so the documentation does not line up with what I am seeing. Looking deeper I found a Load Symbols option in the 'Run' -> 'Load' -> 'Load Symbols'. In that dialog I choose the .out file generated for the project (cla_lp_f2837xd.out) and now have a different, but likely related issue:

    Loading that file seems to have 'transposed' C28xx_CPU1 instructions onto the CPU1_CLA1. So, the debugger now shows starting in 'F2837xD_CodeStartBranch.asm' at line 81 which is at the start of the code_start block, unfortunately, attempting to use 'Step Into' or 'Step Over' results in this error being raised in the 'Debug Output' Console:

    CPU1_CLA1: Can't Single Step Target Program: (Error -2060 @ 0x0) Requested operation cannot be done while device is running. Halt the device, and retry the operation. (Emulation package 20.1.0.3429)

    Halting CLA1 and retrying does not resolve this error. 

  • 0 in reply to Bendik Mann
    TI__Mastermind 20642 points

    Hi Bendik,

    The instructions described in the above document should still apply in CCS20. For starters, can you import one of the CLA examples provided in C2000Ware and confirm that you are able to load the symbols onto the CLA core and observe the program halt at the __mdebugstop() function.

    This is the expected behaviour when trying to debug the cla. At this point, one should be able to single step the C code running on the CLA and observe the state of the variables.

    Regards,

    Ozino

  • 0 in reply to Ozino Odharo
    Prodigy 15 points

    Hi Ozino, 

    Everything I have shared so far has been done on the 'lab_cla_launchpad' example (perhaps also known as CLA Deep Dive?). To be thorough, I recreated the project again with the Project Wizard and redid the steps you suggested. 

    1. Uncomment line 92, '__mdebugstop();'
    2. Launch a debug session by 'Run' -> 'Debug Project
    3. Choose C28xx_CPU1 to load program into
    4. Right Click CPU1_CLA1 in the 'Debug' Sidebar choose 'Connect Target'
    5. Left Click on CPU1_CLA1 
    6. Open Command Palette and choose 'CCS: Load Symbols'
    7. Locals now appear and watches are now populated
    8. It is now possible to single step through instructions.

    As you may notice, the project is 'working'. Unfortunately, I also found why I was unable to debug in the first project. If you instead open 'lab_cla_launchpad.syscfg' and set the microprocessor as 'F28379D' and then follow the instructions above you will begin your debug session in '

    F2837xD_CodeStartBranch.asm81:0' and be unable to single step or begin debugging at the __mdebugstop(); 
    I am unsure why this is the case. The provided syscfg seems to configure the project correctly. Is it possible the bundled syscfg is out of date with the latest version of CCS?

  • 0 in reply to Bendik Mann
    TI__Mastermind 20642 points

    Hi Bendik,

    Glad to see that you are able to get the out-of-box CLA examples working. It seems as if the issue arises when switching devices within sysconfig. What is the initial device prior to your attempts to switch to F28379D? Is it another F2837xD part number? If so, you should be able to use the same project on the F28379D example.

    Please note you should be able to use the example as a starting point for your development. 

    Can you confirm if your project made with the project wizard is similar in setup and configuration as the CLA example? Please note there have been reported issues using the Project Wizard. If you want a blank template, I would recommend importing one of the empty projects in C2000Ware and using that as a starting point.

    The syscfg software examples should be compatible with the latest CCS. Please attach a screenshot of the error message if you observe otherwise.

    Regards,

    Ozino

  • 0 in reply to Ozino Odharo
    Prodigy 15 points

    Hi Ozino,

    First off, I tried importing the project from the 'File'->'Import Project(s)' dialog. I navigated to 'C2000Ware_5_04_00_00\training\device\f2837xd\advance_topics\lab_cla' and imported the launchpad example.

    Next, I went through the same steps that worked for me last time. This did work, so at the very least there is no difference between importing and using Project Wizard before using the System Configurator.

    Next, I opened up the System Configurator. The System Configurator defaults to suggesting using TMS320F28377D. The configurator seems to suggest the sysconfig file uses a nonstandard device name, but it seems like it was configured originally on the TMS320F28379D.

    Sysconfig Popup with error 'board was defined using a non-standard device name.'

    I choose TMS320F28379D for the Device and perform the steps mentioned earlier again. The first time I encounter this issue:

    CPU1_CLA1: GEL: Encountered a problem loading file: C:\Users\BMann\AppData\Local\Temp\ti_cloud_storage\lab_cla_launchpad.syscfg Could not determine target type of file
Encountered a problem loading file: C:\Users\BMann\AppData\Local\Temp\ti_cloud_storage\lab_cla_launchpad.syscfg
Could not determine target type of file

    Out of curiosity, I simply tried loading symbols again. That... seems to have just fixed it. This fix persists through a project clean and through sessions. 

    I tried reducing FIR_LEN to 15 and compiling again. Again, this... seems to work fine.

    I tried adding some additional instructions and again I am able to step through the CLA.

    Finally, for the ultimate overachiever reward, I created another project from the Project Wizard. I opened system configurator set device to the TMS320F28379D. Performed the steps mentioned to start debugging... and it just works.

    I am not quite sure which step here made this process work. Was it loading the symbols twice? Was it using the 'Import Projects' instead of Project Explorer? In either case here are the steps that seemed to have resolved it for me.

    1. Import CLA project using the 'FIle'->'Import Project(s)' Dialog
    2. In System Configurator set device name to  TMS320F28379D
    3. Uncomment the __mdebug line in the .cla file.
    4. Start Debug of the Project on Core1
    5. Resume Core1
    6. Connect to CLA1
    7. Using the palette menu execute the 'CCS: Load Symbols' command
    8. Try to resume CLA1, If this works you may stop here.
    9. Otherwise, using the palette menu execute the 'CCS: Load Symbols' command again
    10. You should now be able to debug on CLA1 with step instructions and debug points (using _mdebug...)