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.

CLOCKTREETOOL: AM65x SYSCLK0_GATE misinterpreted

Part Number: CLOCKTREETOOL

Dear TI team,

I believe the clock tree tool (I tested 1.0.0.8 and 1.0.0.9) misinterprets the CTRLMMR_WKUP_MAIN_SYSCLK_CTRL.SYSCLK0_GATE bit.

The documentation for this bit says "When set, gates off SYSCLK0 (CLK1) output of the MAIN PLL Controller". I take that to mean that the output clock is enabled when the bit is cleared, and the clock gets disabled by setting this bit.

The clock tree tool appears to use an inverse interpretation, i.e. it assumes that the clock is enabeld only when this bit is set. See the following two screenshots:

On the first screenshot the SYSLK0_GATE bit is 0, and the CTT assumes that the output from PLLCTR0 is disabled. On the second screenshot the bit is set, and the CTT displays the resulting frequencies.

Can you confirm that the gate bit means "disabled when set", or am I missing something?

I believe CTT operation is mostly (completely?) driven by the XMLFiles, but I couldn't find an example of a "negated" switch. Is the CTT_Model_definition.xsd or some other documentation for the XML models available somewhere?

Regards,

Dominic

  • I seems the situation about CTT for AM65x is a lot worse than just that single switch being misinterpreted.

    The next thing I looked at was the clocks the PCIE0 module, and the Switch_MAIN_SYSCLK0_19 was being displayed as "OPEN", too, even though the PCIe module was definitely enabled when I recorded the registers.

    It turned out that there are several issues with the CTT:

    - The CTT evaluates PSC0_MDCTL19.NEXT instead of PSC0_MDSTAT19.STATE. That's only a minor issue, because in general the actual module state is most likely the last setting requested via MDCTL<x>.NEXT, but as far as I understand the PSC that's not necessarily true, especially if enabling a module failed.

    - The address used by the CTT for PSC0_MDCTL19 is 0x2950a4c, but the actual address from the TRM is 0x00400a4c. I was able to manually fix that in AM65x.xml and the tool is now using the correct address.

    - The CTT-AM65x_SR1.0-REG_DUMP.gel uses the same (wrong) addresses.

    - I was actually using am65xx-ctt.dss from https://git.ti.com/cgit/sitara-dss-files/am65xx-dss-files/, since that script is able to read the registers without a processor core. Our application is running on the A53 with only the necessary address ranges mapped in the MMU, so the GEL file from CTT that relies on the currently connected processor core fails for us. That script is completely missing the PSC0 register ranges.

    With my manual fixes the clock tree tool is now correctly showing PCIE0_FICLK (at least I hope that current display is correct), but it is a horrible situation that I can't rely on the clock tree tool display to be correct for something as complex as the AM65x's clock tree.

  • Dominic, 

    I traced back to the design docs and confirmed the TRM is accurate. So you are right. Did you notice this bit being changed in the GEL file? Chip would not function if the bit is set. 

    I will leave this thread open till I filed your reported issues to our bug tracking. Thanks as usual for pointing to these issues. 

    jian

  • Hello Jian,

    thanks for your confirmation.

    No, the script merely reads the registers and outputs them to the debugger console, it doesn't modify any bits.

    From what I can tell the issue is that the XML file that describes the AM65x doesn't specify that this bit acts as a "disable", at least it is defined the same way as other bits that "enable" with a "1".

    Regards,

    Dominic