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

Original question:

CC1314R10: Are there any limitations to using ARM DWT_CYCCNT for implementing delays or measuring cycle counts in source...

CC1314R10: DWT_CYCCNT only seems to function during a debugger session

rperezti
Genius 12670 points
Part Number: CC1314R10
Other Parts Discussed in Thread: CC1312R7

This is a follow-up to this thread: https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1254569/cc1314r10-are-there-any-limitations-to-using-arm-dwt_cyccnt-for-implementing-delays-or-measuring-cycle-counts-in-source-code

Below lines of code for providing delay are working ok on CC1312 with and without live debugging with jlink debugger connected to the board.

 

  /* Enable DWT */

   HWREG( CPU_DCB_BASE + CPU_DCB_O_DEMCR) |= CPU_DCB_DEMCR_TRCENA;

   /* Enable CPU cycle counter */

   HWREG( CPU_DWT_BASE + CPU_DWT_O_CTRL) |= CPU_DWT_CTRL_CYCCNTENA;

   /* Reset CPU cycle counter */

   HWREG( CPU_DWT_BASE + CPU_DWT_O_CYCCNT) = 0;

//Wait for delay

   while(HWREG( CPU_DWT_BASE + CPU_DWT_O_CYCCNT) < delay);

 

But for CC1314,

  • These lines are working ok when live debugging with jlink debugger.
  • Stuck at while(HWREG( CPU_DWT_BASE + CPU_DWT_O_CYCCNT) < delay);   when debugger not connected.

Seems like cycle count is not incrementing.

 

`               After doing further analysis I understood from ARM documentation form M33 that there is DWT access register DWT_LAR which need to be configured. So, I implemented below statement before accessing DWT.

#define CPU_DWT_O_LAR                                             0x00000FB0

HWREG(CPU_DWT_BASE + CPU_DWT_O_LAR) = 0xC5ACCE55;

 

But even after implementing this, code stuck at while loop without debugger connected to board.  Although with jlink live debugging, it is still working ok.

 

I also noticed that DWT access enable register is not implemented in sdk header file hw_cpu_dwt.h. But is available in IAR IDE registers view as below.

 

So, please let me know how to implement DWT cycle count access on CC1314?

  • 0
    TI__Guru* 81261 points

    Hi Ruben,

    What is the context for the code snippet they posted? Did they take any precaution against reading/writing, e.g. SWI and HWI disable? 

    When they say "code stuck at while loop without debugger connected ", can you ask them to be a bit more specific? Is it possible to attach a debugger to the target after this happens and thus discover where in the code the device is stuck? (I'm guessing it's hard fault/CPU exception?)

    Cheers,

    Marie

  • 0 in reply to Marie H
    TI__Genius 12670 points

    This is an isolated test, with nothing else running. The cycle counter seems to be clock gated or stopped when the CC1314 is not in a JTAG debug session. The exact same test is carried out on CC1312R7 and the cycle counter continues to operate on that IC even when not in a debug session. Please check if there is some configuration bit on CC1314 to change this behavior. For example,  other IPs have register bits and logic (Free/Soft) for changing the peripheral behavior during debug. With that festure a timer could be configured to stop counting when the CPU stops at a breakpoint. The behavior described in this post is similar, but opposite to this.    

  • 0 in reply to rperezti
    TI__Guru* 81261 points

    Hi Ruben,

    If you post the specific addresses and values you use I can check them for you.

    Could it be that a power domain that you need for this is not powered when you run without the debugger attached? (The debugger will keep certain power domains on). This is the only reason I could think of why it should work with the debugger attached and not when it's not attached. In addition there are some power domain changes between CC1312 and CC1314.

    Cheers,

    Marie H

  • 0 in reply to Marie H
    TI__Genius 12670 points

    Thank you Marie. The addresses can be found in the files at this path in the SDK: C:\ti\simplelink_cc13xx_cc26xx_sdk_7_10_00_98\source\ti\devices\cc13x4_cc26x4\inc

    For example, CPU_DWT_BASE is defined in hw_memmap.h and CPU_DWT_O_CTRL and CPU_DWT_CTRL_CYCCNTENA are defined in hw_cpu_dwt.h.

    Yes, I understand your theory about power domain differences between CC1312 and 1314 being a possible cause of the different behavior observed. Can you please try to confirm this or determine if there is a way to achieve the same behavior on CC1314?

  • 0 in reply to rperezti
    TI__Guru* 81261 points

    Hi Ruben,

    I can reproduce what the customer is seeing. Using their code example, the program runs fine when I have a debugger attached but when I disconnect the debugging session and restart the device, something is hanging. (I have a blinking LED in my version and it stops blinking.)

    My next step is to try and debug what's going on with the help of the RND team.

    Cheers,

    Marie

  • 0 in reply to Marie H
    TI__Genius 12670 points

    Marie thank you for the update. Please keep me posted on your findings.

  • 0 in reply to rperezti
    TI__Guru* 81261 points

    Hi Ruben,

    I'm currently investigating whether the CPU_DCB.DAUTHCTRL registers are correctly set. At least, SPIDENSEL and INTSPIDEN needs to be set to 1 (and this should automatically happen when the corresponding CCFG registers are set. Which they are by default in our SDK examples.)

    Unfortunately the DAUTHCTRL can not be read by the debugger.

    I will write some test code to write out the values over uart and update you tomorrow.

    Cheers,

    Marie H

  • +1 in reply to Marie H
    TI__Guru* 81261 points

    Hi Ruben,

    We found it's not possible starting DWT without the debugger attached.

    Cheers,

    Marie H