• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 202 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:

TMS320F28386S: CM CPUTIMER delays issue

TMS320F28386S: SysConfig 1.24.0 error with setting CM clock

OLEG KOBRIN
Prodigy 155 points
Part Number: TMS320F28386S
Other Parts Discussed in Thread: SYSCONFIG, C2000WARE

Tool/software:

Good evening!

I found an issue in SysConfig.

When I configure the clock tree for the TMS230F2838x device and set AUXPLL to 250MHz and derive the CM clock from it with /2 divider, this divider is ignored.

The code in device.c is alwais

//
// Set up CMCLK to use AUXPLL as the clock source and set the
// clock divider to 1.
//
SysCtl_setCMClk(SYSCTL_CMCLKOUT_DIV_1,SYSCTL_SOURCE_AUXPLL);

regardless of the divider setting in SysConfig.

I see the problem is the clock source for CM is AUXPLLRAWCLK, not AUXPLLCLK, which is divided.

  • +1
    TI__Genius 10145 points

    Hello,

    I can confirm that you've caught a bug.

    The SysCtl_setCMClk() function call has been hard-coded to always divide by 1 and use the AUXPLL clock source regardless of the Clock Tree tool's configurations. I will have this resolved in the next SysConfig release in August.  

    Best,

    Matt

  • 0 in reply to Matt Kukucka
    Prodigy 155 points

    Thank you, I see, so I made the AUX PLL RAW CLK to 125MHz, and AUX PLL CLK to the same value, and no dividers.

    I wonder if next SysConfig will support CM core too)

  • 0 in reply to OLEG KOBRIN
    TI__Genius 10145 points

    Hello,

    Unfortunately, there are no plans to support CM projects in multi-core SysConfig. I'm glad you were able to still get the clock source working nonetheless.

    Best,

    Matt

  • 0 in reply to Matt Kukucka
    Prodigy 155 points

    This is second disappointing news from TI.

    First one was about ceasing support for classical CCS (12.x). We cannot use CCS 20, as all our workflow is based on Eclipse, and ccs 20 is based on significantly castrated version of Eclipse (Theya, I suppose), which we cannot use.

  • +1 in reply to OLEG KOBRIN
    TI__Genius 10145 points

    If you face any issues on CCS Eclipse, we will continue to support on E2E. We will also plan to maintain backwards compatibility with v12. 

    Best,

    Matt

  • 0 in reply to Matt Kukucka
    Prodigy 155 points

    In fact, there is one important issue in CCS 12, concerning debugging C2000. It was discussed in this topic, and last message there was exactly about 

    Since CCS Eclipse (and the graph view it comes with) is no longer supported, it is unlikely that this issue will be fixed.

    Is it possible to fix it anyhow? 

  • 0 in reply to OLEG KOBRIN
    TI__Genius 10145 points

    Hi,

    I don't believe there are any workarounds that I can provide. The best recommendation I have is to use an older, stable version of CCS with a working graph view.

    Matt Kukucka said:
    We will also plan to maintain backwards compatibility with v12. 

    To clarify: when I say this, I mean that future C2000Ware SDK versions should work on CCS Eclipse, but won't be as thoroughly tested as CCS v20. I apologize again for the inconvenience. 

    Best,

    Matt

  • +1 in reply to Matt Kukucka
    Prodigy 155 points

    I see. Unfortunately, latest CCS version without graph problems on C2000 was v9,

    Anyway, I use a workaround, opening the graph view for some integer, and then entering needed info in the graph properties dialog. It is not very convinient, but works. Happily, if I do not close the graph views, I can continue using them.