• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 56 subscribers
  • Views 838 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.

Debugging multi-core program issue(C6678 with h264 video encoder)...

zhao sun
Expert 1170 points


Hi,

I have encountered some issues when I debug the multi-core program on c6678 evm.

The program I use is the standalone h264 video encoder demo program provided by TI.

I have modified the parameters to run it on 2 cores of C6678 evm. When I run the program

without any breakpoint, It can work correctly. But when I set breakpoint in somewhere of the

program (say: I set a break point quickly after H264VEN_mcore_sync function seperately).

I find that the code disassembled by each core are different even they are in MSMC and have

the same address.

(say: in core0 side: 0x0C07DA94 dissembly code: 026269AA MVK.S2

in core1 side: 0x0C07DA94 dissembly code: 1001E002 SWBP 0)

And after I resume them again, the program run error. So it confused me very much because:

1. The code is in MSMC memory and I have set the atrribute of that Region to RX. But why it is be changed?

2. I can observe the value of that address in code cache in CCS. But how I can got the real value of that address.(I know that I can got it by invalidate cache in the program, But I do not know exactly where the code will be changed)

3. I have changed the position of breakpoint to somewhere else. And always get the some result.

Will someone please help me with this issue? Thanks a lot!

B.R.

Sunzhao

  • 0
    TI__Mastermind 30825 points

    Sunzhao,

    It sounds like you may have code that's modifying the MSMC memory space. 

    I'd first suggest doing the following.

    1.) Load code but don't run.

    2.) look at the space that seems to get changed (one core seeing it as one value and the other as another valued) and record the value (this assumes the same space is getting changed during every run through.) 

    3.) Repeat the steps that result in the 'failure' halt and look at the address.  Which core shows it as different?  This is the core that 'modified' that space.  But the L1D is a Write-back cache (not write-through) which means that the data will reside in the L1D until a Writeback or Writeback-Invalidate occurs.  Which means what's actually in MSMC hasn't changed yet.  If it does change but the other core has already cached it, it won't see the update as the coherency must be maintained by the SW wrt to the MSMC and External memoryies.

    4.) Now that you know which core is modifing it figure out why as it shouldn't be modified.  Do you have Stack overflows, are there things that you didn't take into consideration when splitting this to multiple cores such as share a buffer address that you shouldn't be sharing.

    Also, CCS has the ability to look show what's in what cache space in the memory window to show you what resides in the various caches versus what's at the actual address.

    Best Regards,

    Chad

  • 0
    TI__Expert 4335 points

    Hi Sunzhao,

    The behavior you observed can happen when setting breakpoints for a multi-core application. Instead of regular breakpoints, please try hardware breakpoints.

    Thanks,

    Hongmei

  • 0 in reply to Hongmei Gou
    Expert 1170 points

    Thanks Chad & Hongmei for your reply,

          After I set hardware breakpoint, the code resist in the MSMC will not be changed. But can you

    do explanation about that? I know softeware breakping is implemented as an opcode replacement,

    But I think it should not cause the different running result.

    B.R.

    Sunzhao

  • 0 in reply to zhao sun
    TI__Mastermind 30825 points

    SW Breakpoint should not be replacing an executable code.  Not sure why such results would be seen unless for some reason there is really something like a stack overflow occuring.  You might not observe the issue as long as code remained resident in L1P cache and/or the L1D accesses of it never got written back to MSMC.  I still suspect this to be the underling issue.

    Best Regards,
    Chad

  • 0 in reply to Chad Courtney
    TI__Mastermind 39560 points

    Would it help to set a hardware breakpoint a few steps before the point of interest and check the dis- assembly and cache etc on particular corepac.

    Then set the SWBP and look at what changed?

    Regards,

    Kishore.