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.

CODECOMPOSER: Debugging multiple devices simultaneously

Part Number: CODECOMPOSER
Other Parts Discussed in Thread: LP-MSPM0C1104, LP-MSPM0G3507

Tool/software:

Hello, 

in order to develop an inter processor communication, we would like to debug two different connected targets (LP-MSPM0G3507 and LP-MSPM0C1104) simultaneously, including flashing different firmware.

We're able to start the configured debug session, flashing both targets and running them, but we have issues when it comes to observing expressions in the "Watch"-view:

1. It is not possible to watch and update the expressions of both targets simultaneously. 

2. By selecting the target-corresponding thread it is possible to watch the belonging expressions, but this is only possible when the second configured target is halted. When both or at least the second configured target is running, the watch view cannot switch to the expressions belonging to the second target. 

We would really appreciate a fix especially regarding the second described issue, since halting the target leads to communication timeouts and triggers diagnosis to signal an error. 

Best Regards

Timon Büttner

  • Hello,

    You didn't mention which version of CCS you are using but I will assume you are using CCS 20.x and have a "multi-probe" debug configuration.

    1. It is not possible to watch and update the expressions of both targets simultaneously. 

    Note that it is possible to "pin" individual expressions in the Watch view to a specific debug context (core):

    Once pinned to a debug context, you will be able to see the variable value ion context of the core it is pinned to  regarding of which debug context is active.

    2. By selecting the target-corresponding thread it is possible to watch the belonging expressions, but this is only possible when the second configured target is halted. When both or at least the second configured target is running, the watch view cannot switch to the expressions belonging to the second target. 

    This is an interesting one. If I unpin expressions, I believe I can reproduce a similar behavior. In my environment, it is the second core with the issue. The first and third are actually fine. I'll need to investigate this behavior more. I would pin the variables to a core in the meantime.

    Thanks

    ki

  • Hello Ki, 

    You didn't mention which version of CCS you are using but I will assume you are using CCS 20.x and have a "multi-probe" debug configuration.

    I'm sorry i missed more detailed information regarding the CCS version and debug configuration. However you are right, I'm using the latest release ( CCS v20.3.0) and a "Multi probe configuration".

    Note that it is possible to "pin" individual expressions in the Watch view to a specific debug context (core):

    I wasn't aware of this functionality, though as you mentioned, it fixes the issue. With pinned expressions the values are updated while both cores are running, no matter which one is selected. 

    One thing I just tried and didn't work is updating the graph view of one expression when the core it corresponds to is not selected. But I don't need this currently so I'm absolutely fine with the solution. 

    Thank you very much!

    Timon 

  • I wasn't aware of this functionality, though as you mentioned, it fixes the issue.

    Thank for confirming this. Yes this feature is a bit hidden since this is the only view where you can pin individual items in the same view to different contexts. 

    We plan on making this default in a future release (maybe 20.4.0) - where when you add a variable to the Watch view, it will auto-pin to the current context. The user can unpin if desired but it makes sense to auto-pin by default.

  • This is an interesting one. If I unpin expressions, I believe I can reproduce a similar behavior. In my environment, it is the second core with the issue. The first and third are actually fine. I'll need to investigate this behavior more

    This is a clear bug. I filed a ticket for it. Tracking link: https://sir.ext.ti.com/jira/browse/EXT_EP-12938

    Thanks

    ki