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

how does CCS update a memory window?

Brad Caldwell
Genius 12595 points

Hi,

We are working on debugging a DDR timing issue. We can open up a CCS memory window (CCSv5.3) on the Arm of a DM8148 device. The window is set to the default 32-bit HEX words. We make the window large to show lots of values and then repeatedly refresh the window and now and then we see a value change, nothing is running at that point and the CPU is halted. We then run a simple piece of code that runs in a loop and reads the same region of DDR repeatdly and looks for read failures, we perform 32-bitr reads. We initialize the DDR first with a known ramp sequence. The problem is, we don't see any failures when running code but we do when refreshing a memory window with the CPU halted.

My question is, when we refresh a memory window that's showing 32-bit HEX values, what exeactly does CCS do to read the memory? Is it performing individual 32-bit reads one after another? If so, is there a long delay between reads? Is it trying to burst multiple words somehow like you might get with a DMA? Maybe it's using load double-words? We're trying to determine how our read loop differs from the CCS memory window update.

 

Thanks

 

  • 0
    TI__Intellectual 2265 points

    Hi Brad,

    The memory browser reads data in bulk; depending on the size of window and then formats it on the host. We have seen issues in the past when the "continuous refresh" option is selected due to internal caching issues with the memory browsers. This could also be an issue with MMU? or the emulation driver. It would be best if you can come up with a step-by-step test case to reproduce; then we can definitively determine what is going on. Also, there were some major changes made to the internals of the memory window for 5.4. It would nice if you can try out the pre-beta builds of that data and see if you see any differences.

    Thanks,
    Mandeep 

  • 0 in reply to Mandeep Deol
    TI__Genius 12595 points

    Thanks Mandeep. We definietly have a DDR timing issue with our board, we've verified it using other tests. I'm not trying to solve that here nor looking for a fix to the memory window becuase I know we have a DDR issue. What I'm really looking for if possible is a description of how the emulator reads memory to fill the memory winidow? You said it reads data in bulk. What does that mean? How are memory accesses performed to the DDR? Single word accesses, double word accesses, larger sizes with bursting somehow?

     

    Thanks

  • 0 in reply to Brad Caldwell
    TI__Intellectual 2265 points

    Brad,

    Sorry I don't know the specifics of how the reads are performed. Probably need to reach out to someone on that emulation team for that.

    Mandeep

  • 0 in reply to Mandeep Deol
    TI__Genius 12595 points

    Mandeep, no problem, thanks for jumping in.

  • 0 in reply to Brad Caldwell
    TI__Intellectual 2515 points

    The DM8148 is a C674x device, floating point GEM core with ICEMaker debug logic.  

    My question is, when we refresh a memory window that's showing 32-bit HEX values, what exeactly does CCS do to read the memory?

    Memory is accessed directly by the debug logic for this core.  For a block of memory, there will be initial JTAG scans to setup the memory read, then a series of scans to retrieve the data, 32-bits per JTAG scan.  For a large enough memory window, CCS may divide the request up into two or more blocks.  In addition to the time spent executing the JTAG scans, there may be latency depending on the emulator and how it's connected to the PC host.

    Is it performing individual 32-bit reads one after another?

    Essentially, yes.  32-bits per JTAG scan from the emulator.

    If so, is there a long delay between reads? 

    Depends on the JTAG TCLK setting, type of emulator, and how the emulator is connected to the host.  But in terms of the CPU's core speed, yea, it's going to be fairly long between reads.