• State TI Thinks Resolved
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 27 views
  • Users 0 members are here
Support feedback
Options
Options
Related

F29H850TU: Multicore debug with AI

Jozef Sedivy
Intellectual 350 points

Part Number: F29H850TU

Hi, 
I am using AI assisted development and came across the problem  with muticore debug. It seems your MCP does not provide relevant functions. 

This is hint I got from the AI agent:

  • Accordion summary...

    What doesn't work:

    • connectTarget takes no parameter to specify which core to connect. In this multi-core session (CPU1, CPU2, CPU3, Cortex_M4_0 all visible via listCores), calling it only ever reports "already connected" — referring to whichever core was implicitly connected by the original launch (CPU1). There's no way to direct it at a different core from the list.

    • loadProgram and loadSymbols do accept an optional coreId parameter. I passed coreId: 2 (CPU3's index) to both, and both failed:

      • loadProgram → "Target must be connected before calling the function" / "Could not load file"
      • loadSymbols → "Could not load file"

      So the coreId parameter on these two tools doesn't actually succeed in targeting/connecting a different core — the session stays locked to whatever was connected at launch.

    Could you please confirm wheather this is correct or could you provide your guidance on how to debug code for core2 and 3 without loading code for core1? 

    Jozef
  • 0
    TI__Mastermind 39703 points

    Hi Jozef,

    You cannot debug CPU2/CPU3 "without loading code for CPU1," because:

    • The combined CPU1 .out image contains the programs for CPU1, CPU2, and CPU3. You load it onto CPU1 only, and you do not load CPU2/CPU3 programs separately 1.
    • CPU2 and CPU3 are held in reset until CPU1 configures and releases them. Only after CPU1 runs can you connect to those targets 2.

    So, the failing loadProgram(coreId: 2) call is attempting an operation that is wrong for this architecture regardless of whether the MCP tool works.

    Correct sequence

    Step Action
    1 Launch a project-less debug session from the target .ccxml (recommended over the CCS Debug button, which mishandles multicore build dependencies — build the combined project first) 3
    2 Connect CPU1 and load only the CPU1 .out 4
    3 FLASH build: set BANKMODE2 via CPU1 Flash Settings, disconnect, then issue XRSn (board reset button or Scripts > CPU Reset Handling > Device_Reset_XRSn) — otherwise the BANKMODE register reads a false value 1. RAM build: erase flash before loading 4
    4 Run CPU1 so it configures and releases CPU2/CPU3 from reset 2
    5 Connect to CPU2/CPU3. Do not load their programs. For RAM configuration, restart CPU2/CPU3 and load symbols only (needed for source-level debug). For the FLASH BANKMODE2 case, CPU3 begins executing when released from reset 1 2

    Mapping this to your agent

    Reframe the instruction: the only load operation is CPU1 + combined image. For CPU2/CPU3, the agent needs connect (after CPU1 runs) and at most loadSymbols — never loadProgram. If connectTarget genuinely cannot be directed at a non-launch core, that is a hard blocker for step 5 via MCP, and the fallback is the CCS GUI Debug view, where each core appears as a separately selectable target in the project-less session.

    If CPU1 drops into NMI or a persistent fault state after startup, check the interrupt exit path and confirm the ISR uses the correct INT or RTINT attribute; linker command file changes can also cause this 1.

    1. E2E: F29H850TU Multicore debugging
    2. F29H85x Technical Reference Manual (SPRUJ79C), p. 1138
    3. E2E: F29H850TU Multicore project example with working JTAG debug
    4. F29H85x SDK: CCS Multicore Debug

    Best Regards,

    Zackary Fleenor