• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 54 subscribers
  • Views 1448 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.

CCS 6.1.1 "execution status prevented access" error prevents continuous refresh of global variables for Cortex-A8

Chester Gillon
Guru 92251 points
Other Parts Discussed in Thread: AM3352

Using the following:

- CCS 6.1.1.00022
- TI Emulators 6.0.14.5 com.ti.emulation.pack.linux.feature.group
- Blackhawk USB560-M Emulator, 20-pin JTAG Cable
- The Cortex-A8 core in an AM3352

While the program is running, with the Cortex-A8 is selected in the Debug view, attempting a continuous refresh in the Expressions View or Memory View results in CCS displaying "execution status prevented access".

If the CS_DAP_Debug_SS is unhidden, and the CS_DAP_Debug_SS is selected in the Debug view then the Expressions View and Memory View are able perform a continuous refresh while the program is running. However, by default the DAP doesn't have any symbols loaded or any memory mapped register definitions (as a work-around a GEL file could be used on the DAP to load symbols).

The CCS Real-time Debug training suggests that CCS should be able to use the DAP to automatically access memory while a Cortex-A is running in the same way as Cortex-M, albeit that the DAP access will always use the physical memory address on the Cortex-A.

Is the observed behavior a bug or a limitation in CCS 6.1.1?

  • 0
    TI__Guru**** 171309 points
    Chester,

    I also had the impression this was enabled by default, but perhaps not for Cortex A cores (I know that Cortex M cores have this working OK).

    I will double-check if there is anything that prevents this to be supported in the bigger brethren.

    Regards,
    Rafael
  • 0 in reply to desouza
    TI__Guru**** 171309 points

    Chester,

    Thanks for reporting this. I filed today the bug number SDSCM00052450 to track this implementation. Please check its status in the link SDOWP in my signature below.

    The DAP access is useful but has other implications if the core has MMU or cache enabled, therefore there are intentions to implement a warning mechanism to account for this scenario. The main reason this was not implemented before is mostly due to the typical use of Cortex A cores - in general embedded Linux.

    I apologize for the inconvenience,

    Rafael

  • 0 in reply to desouza
    Guru 92251 points

    desouza said:
    The DAP access is useful but has other implications if the core has MMU or cache enabled, therefore there are intentions to implement a warning mechanism to account for this scenario.

    Thanks for raising the bug, and the explanation about the implications.

    I have been using Starterware or TI-RTOS applications on the Cortex-A8, and for those the MMU is configured to provide a one-to-one mapping for virtual to physical addresses. i.e. the MMU won't be an issue for DAP accesses.

    However, your comment made me realize on the Cortex-A8 having the cache enabled is an issue for when the DAP is used to access cacheable regions. e.g. when using the Memory Browser to look at a DDR3 region which was cacheable the CPU view and DAP views can show different contents, in the case where data in cache hasn't been written to DDR3.

    Not sure if the Snoop Control Unit (SCU) on multi-core Cortex-A9 devices will have an implication for DAP access when the cache is enabled. Will try and determine if the Cortex-A9 SCU will gives the DAP a cache-coherent view.

  • 0 in reply to Chester Gillon
    Guru 92251 points

    Chester Gillon said:
    Not sure if the Snoop Control Unit (SCU) on multi-core Cortex-A9 devices will have an implication for DAP access when the cache is enabled. Will try and determine if the Cortex-A9 SCU will gives the DAP a cache-coherent view.

    With a SYS/BIOS 6.41.04.54 program running on a Cortex-A9 core on a OMAP4430 with the MMU and cache enabled, neither the CS_DAP_PC nor CS_DAP_DebugSS give an automatic cache-coherent view. i.e. the CS_DAP_PC and CS_DAP_DebugSS can show "stale" data compared to the CPU view.

    The test involved filling a 2Mbyte array, and comparing the contents of the CPU view .vs. CS_DAP_PC and CS_DAP_DebugSS views of the array.

    [The ARM Advanced Features reports that Snoop Control was enabled]