• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 100 subscribers
  • Views 790 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 does not show all timers

Tim Cooper1
Intellectual 980 points

Part Number: 66AK2H12

Tool/software: Code Composer Studio

Working with TI-RTOS, CCSv8, on ARM 0.

Using TI's timer libraries, which, under the hood, call timer64 functions.

Timers are allocated starting with timer 0x20 (as seen in the TI getNextAvailableTimerId structure).  Allocating and setting up timer 0x20, according to the emulator, changes the registers of the timer at 0x022f_0080.  This seems to be correct; this is actually physical timer 16.

Then timer 0x21 is allocated, and the other half of timer 16 is allocated and set up.

Then timer 0x22 is allocated;  this corresponds to the timer at 0x022f_0100 (timer 17) according to the data sheet.  However, CCS memory browser shows no ID value at this address (it is 0x4472020c for the other timers), no fixed prescaler of 0x00060000, etc.  The software goes through the motions of setting up the timer but nothing shows up in the memory browser.  Furthermore, we do not receive interrupts from these timers.

We can, of course, move the timers, but we need several and are running with 3rd party software which is not so easily adjusted.

I can't tell if CCSv8 is correctly showing the values (I notice it gobbles up memory over time, and the core register window disappears, and it gradually gets slower);  this however feels like a processor problem.  What would make timers 17, 18, and 19 inaccessible?

Thanks,

Tim

More:  this appears to be related to whether or not the GEL file is used, and whether or not it goes through Set_Tetris_Pll, and whether or not it switches on all the ARM cores.  I can find no documentation regarding why this would affect visibility into some timers. Does this make sense?  Is there a reference document for this?

Thanks,

Tim

  • 0
    Intellectual 980 points
    OK, the PDCTL and PTCMD regs for the other 3 cores must first be set to place the processors in powered up/held in reset state. I've not found any information regarding why this is coupled to the accessibility of the last 4 timers. Closing this question.
  • 0 in reply to Tim Cooper1
    TI__Guru 65405 points
    Hi Tim,

    Thank you for sharing the solution.

    Regards,
    Tsvetolin Shulev
  • 0 in reply to Cvetolin Shulev-XID
    Intellectual 980 points

    Csvetolin,

    Thanks.  However, this appears only to be a partial fix.  For some reason, timer 19 at 0x022f_0200 is still not visible.  The peripheral ID (0x4472020c) reads as zeros, as do all other registers.

    Can you please forward this to an appropriate engineer?  I am curious as to why enabling the other ARM cores resulted in accessibility to the other timers.

    Regards,

    Tim

  • 0 in reply to Tim Cooper1
    Intellectual 980 points
    Further experiments show that each of timers 16, 17, 18, 19 is associated with ARM cores 0,1,2,3. As each ARM core is moved into on/reset asserted state, the corresponding timer becomes visible to the emulator pod and to other processors. The startup code I have enabled cores 0,1,2 but not 3.

    This is easily reproduced: connect to ARM0 with a CCS and look for timers 16-19. Timer 16 will be there (since connecting to arm0 places it in a powered-up state), but not timers 17-19. If one uses a GEL file that starts up the other cores (as occurs in the Tetris set ARM PLL function of the ARM gel file), CCS will show all timers after the GEL file completes initialization. However, a GEL file is not an application program, and is not usable by an application program.

    The association between timers and ARM cores is is odd because the timers aren't otherwise associated with cores (any ARM core can get to any timer), and I've found nothing in the documentation that indicates you need to turn on (but hold in reset) unused ARM cores. Have I overlooked some footnote in some document? This is certainly an odd feature.

    Furthermore, the TI timer utilities appear to start allocating timers starting with timer 19 and working backwards. The TI timer utilities don't know/care that the timers aren't really there, nor are there access errors for setting up a timer that is not visible. Instead, some needed time function simply never occurs.