• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 56 subscribers
  • Views 4445 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Memory watch and synchronizing cores

Andrey56137
Intellectual 370 points

I am trying to run a program on several cores, with each core doing a chunk of the work, and sharing some area of memory. I am using CCS 4.2, SYS/BIOS on a EVM C6472 board with JTAG. So one of the things I need is the ability to monitor memory shared between cores. It can be used for as a primitive semaphore, among other things: all cores can wait on some shared variable to be set to a certain value. From the debugger's "Watch" window, you can both read and write to memory (i.e. you can see a variable's value and you can change its value externally, by typing it into a cell).

The problem is that the "Watch" doesn't seem to update in real time (i.e. as the program is running). I have to press the "halt" button in CCS before the values are updated. So, I cannot set my semaphore before the program is paused, which defeats it purpose. Even without the need for synchronization, it would still be beneficial to see the variables being updated as the program runs. Any suggestions on how to do that?

On a related note, when I try to switch between "Watch" windows in different cores, after updating a shared variable, all variables in the other core display an error "Could not read memory at 0x000...: Execution state prevented access".

 

  • 0
    TI__Genius 15145 points

    Hi Andrey,

    While the target is running, the debugger prevents memory (and others) access. When you halt the target, the debugger allows memory access.

    To have the ability to access the target while it is running, you need to change the Realtime Options to halt the target before any debugger access. There are couple ways to do this, and depends on where you set this option, it will be stored differently.

    1. Select Windows | Preferences, and select CCS/Debug/Debugger Options/Generic. You should be able to find 'Halt the target before any debugger access". Setting will be store the setting per workspace.

    2. Select Target | Debug ..., and find the launch configuration in the left tree that matches your target. Than select the Target tab on the right, you should be able to find the same option here. Setting will be store per launch configuration. When a new launch configuration is created, it will pickup the default value from the setting in Windows | Preferences (option 1).

    3. After you have started a debug session, select Tools | Debugger Options | Generic Debugger Options. In the right pane, you should be able to find the same option. Setting will directly affecting the current debug session. To store the setting, you will need to press the "Remember My Setting" at the bottom of the pane. The setting will be store in the launch configuration for this target (option 2).

    With this option set, you can refresh the views without halting the target manually, the debugger will do it for you.

    The error that you see "Could not read memory at ....", I am pretty sure it is due to this option not set.

    Also, you can enable auto refresh in any debug view, this will auto refresh the view in a specified internval. Another option is to set a breakpoint at the location that you want to refresh a view, and change the breakpoint action to refresh the view that you want.

    Hope this help,
    Patrick

  • 0 in reply to Patrick Chuong
    TI__Genius 14530 points

    Andrey, 

    One thing you need to keep in mind that enabling this mode will automatically halt the target to make debug access(i.e. read memory). This means that no interrupts will be processed by that CPU during that time. I am not sure whether that will impact your application or not. 

     

    Martin

     

  • 0 in reply to MartinS
    Intellectual 370 points

    Thanks for your replies.

    I enabled the checkbox for "halt before debugger access". I also set the watch window for "continuous refresh". However, it appears I still need to halt the program before I see the updated values. Right now, the values change to "execution state prevented access" after the program starts running. I guess the auto-refresh tries to read the updated values, but can't because the program is running. I still cannot a set flag before halting the program.

    Is it impossible to implement a sempahore with a shared variable then? The idea is that I have all cores running simultaneously, waiting on a flag. As soon as the flag is set, all cores proceed with the execution. But if I need to halt a core before setting the flag, then resume, I cannot have all cores start executing at once.

    Martin, I am not worried about interrupts for the time being.

     

  • 0 in reply to Andrey56137
    TI__Genius 15145 points

    Hi Andrey,

    If you target supportes realtime, than you don't need to set this option to write to the target. There is a button to enable realtime mode at the main window toolbar.

    Can you also tell me which method you use to change the debugger option?

    Regards,
    Patrick

  • 0 in reply to Patrick Chuong
    Intellectual 370 points

    Which option are you talking about? The option to halt target on debugger access?

    I tried setting the real-time mode as you suggested. I got this error.

    C64XP_1: Trouble Halting Target CPU: Unable to find interruptible boundary.  Not able to complete request because it requires an interruptible boundary to halt.  Please check your application code for interruptibility. 

     

  • 0 in reply to Andrey56137
    Genius 3420 points

    Patrick-

    For the main menu bar button that we tried, the tooltip says "Enable Silicon Real-Time Mode".  Is this the correct one?

    Also, does the EVM C6472 support this mode?  I ask because this EVM has built-in JTAG / emulation circuitry behind a USB port, and my experience with this type of EVM (or DSK) boards is their real-time debug capabilities are limited.  But those were Spectrum Digital boards and this one is not, so maybe I'm off base.

    Thanks.

    -Jeff

  • 0 in reply to Jeff Brower73
    TI__Guru**** 421480 points

    This wiki topic has more resources on real-time mode. There is a demo video on v4 and a presentation for v3. The v3 presentation is also useful for v4 users because it gives some background on how real-time mode works and devices it supports.

    http://processors.wiki.ti.com/index.php/Real-Time_Mode_Debug_with_CCStudio

     

  • 0 in reply to Ki
    Genius 3420 points

    Ki-Soo Lee-

    Thanks for your reply and that info.

    But currently we really need to know answers to the EVM C6472 support question.  If we're chasing something that isn't supported on the EVM C6472, either because of being used in combination with CCS 4 and BIOS 6, or because the simple FTDI USB chip + Actel FPGA circuitry doesn't handle it, then we just need to know.  Thanks again.

    -Jeff

  • 0 in reply to Jeff Brower73
    TI__Guru**** 421480 points

    C6472 is based of C64x+, which I do believe supports real-time mode.

  • 0 in reply to Ki
    TI__Guru* 84110 points

    I confirmed that the EVMC6472 with the on-board emulation does support real-time mode. I was able to enable it on one core and run that core and observe changes in a global variable using either manual refresh or continuous refresh. This is also supported using an external XDS560m emulator.

    If you have a lot of watch variables or a large memory window to update, the updates could be slow if the processor is very heavily loaded.

    Polite real-time mode means that the emulator will use cycles when the memory buses are not being used. Rude real-time means the emulator will try to be polite but will take cycles when it needs to even though it will not halt the processor first. Polite real-time can have a small impact of performance, but rude real-time has a better chance of having an impact; both will depend on the applications that are running at the time and how much memory bandwidth they are using.

  • 0 in reply to RandyP
    Genius 3420 points

    Randy-

    RandyP said:

    I confirmed that the EVMC6472 with the on-board emulation does support real-time mode. I was able to enable it on one core and run that core and observe changes in a global variable using either manual refresh or continuous refresh. This is also supported using an external XDS560m emulator.

    Thanks very much for this info, it sounds promising.  Can I ask, did you try with CCS4?    We're using CCS 4.2 and BIOS 6.

    Today we're making some changes to our source code generator/parser that will more closely emulate OpenMP on the C6472, but by tomorrow we should be able to try real-time debug again.

    -Jeff

     

  • 0 in reply to Jeff Brower73
    TI__Guru* 84110 points

    Jeff,

    I am using CCSv4.2.0.10012 and BIOS 5. I have not had the courage to move to BIOS 6 yet, I am just trying to get good at CCSv4 first.

    CCSv4.2.0.09000 or later and BIOS 5.41.07 or later has improved support for looking at LOG_printf's, so that is important for me. I think BIOS 6 has much better support for that kind of thing, but maybe you can fill me in on that part.

    Real-time mode will be independent of BIOS, though.I do not know how well things work when doing multi-processing with real-time mode. I was having a series of issues with importing a set of projects while trying to get to the point where I could test out real-time. So I did not have all the cores running and try to pull data off each of them under those circumstances. I have no reason to expect it not to work, but I only believe and try to only state what I have seen without these long caveats.

    Let us know what your experience is with it, please.

    Regards,
    RandyP

  • 0 in reply to Patrick Chuong
    Prodigy 10 points
    Worked a treat for me! Appears the target needs to be halted just before the variable is read, and enabling this option automates the task for you. Thanks!