TMS320F280049C: CLK2 - Clock integrity check

Marc,

For the configuration of the DCC are you doing this via the drivers or using SysConfig? 

If you are not using SysConfig, would you be able to try and use it https://dev.ti.com/sysconfig to configure the DCC?  We have a setting to auto-gen the DCC counter seeds based on your requirements that I would like to make sure are expected(you can look at the board.c file that get generated and compare to what you have)

Can you also comment on your XTAL vs the one on the EVM in terms of frequency?

Best,

Matthew

Hello Matthew, 

We are using the config provided by sysCtrl during startup. I've tried with different DCC configs with same results. 

Our XTAL goes at 16MHz, with used config sysclk goes at 100MHz. With EV If I'm not wrong this is 20MHz and 125MHz. 

I don't understand issue relation with DCC. When applying a delay with sysCtl_delay, I assume this delay is performed based on sysclk, so I wouldn't expect any drift when checking timer2 counts if this timer is based on XTAL or sysclk (perhaps using INTOSC1/2 I would expect some drift). 

My point is, if delay is applied based on sysclk and timer2 is also based on sysclk, why would there be a 2% offset, and in which way DCC would change that?

Thanks,

Marc Ferrer

Marc,

We are forwarding the thread to DCC expert. Please expect response by Monday.

Thanks & Regards,

Santosh

Hello Marc,

The SysCtl_delay() function simply decrements the passed number of SYSCLK cycles to zero and returns to the caller. The evaluation board will also have SYSCLK at 100MHz as this is the maximum spec for this device. There are two factors I can think of that could impact your situation:

1. There may be a few extra cycles added due to the function call/context switch

2. There could be one or more CPU interrupts happening during the delay function, which would interrupt it and cause the timer to be longer.

Can you ensure that you don't have any hardware interrupts that could be affecting your time measurement?

Alternatively, a good way to measure the time delay between two events would be to use the ECAP peripheral. The ECAP can take inputs from a variety of sources including the input and output X-BARs, and can also be triggered via software.

Also, the CPU timer peripheral can be used to generate an event or interrupt at a fixed time offset. This would provide a more reliable alternative to SysCtl_delay() as CPU Timer operation is not impacted by CPU interrupts.

Hope this information helps.

Best regards,
Ibukun

Hello Ibukun,

This test is part of CLK2 safety mechanism. It consists on checking clock integrity with CPU timer, that's why we apply a known delay with SYSCLK to check timer value is the expected. 

CPU timer test using SYSCLK test is working for Ev board but not for our unit (same code). I have checked config registers and seem tho be exactly the same.

Regarding "few extra cycles added", since it is 1-2% extra, I wouldn't discard this option but can't understand why Ev board is not showing same delay.

In regards to "CPU interrupts happening during the delay function", I am performing the test with all interrupts disabled with "DINT".

Another hint is that when I change manually IMULT or FMULT on ClkCfgReg, Timer result is the same as default IMULT and FMULT (as expected since it is using SYSCLK) but on our unit counter result changes depending on IMULT FMULT though clkCfgReg is the same. Is this making some sense ?

Many Thanks,

Marc Ferrer

Hello Marc,

Yes, I understand. You said your test was based on example code. Which example are you referring to specifically? I don't see any "clock integrity check" example in C2000ware, only an MCD test. I'd like to understand what your code is doing specifically in order to diagnose this problem, and try to run the example on my end as well.

One thing I would suggest at this point is to use the DCC on both your EVM and PCB to measure the SYSCLK frequency after the PLL has been configured. This would confirm (assuming you're using an accurate crystal as DCCCLKSRC0) that the SYSCLK frequency is indeed what you expect it to be. The DCC can also be configured to run continuously to check the SYSCLK frequency and report an error if it drifts outside a pre-set tolerance. For example, using a 16MHz reference crystal and 100MHz SYSCLK target to measure, you would configure DCC as follows:

DCCCNTSEED0 = 22478
DCCVALIDSEED0 = 45
DCCCNTSEED1 = 1048575 (max value)

For continuous monitoring with max 1% frequency error tolerance:

DCCCNTSEED0 = 22253
DCCVALIDSEED0 = 495
DCCCNTSEED1 = 140625

I have attached a DCC calculator worksheet for your convenience. You could also perform these measurements/checks with INTOSC to confirm your results and determine for sure if there is some drift in SYSCLK that is happening, or if there is some other cause to your observations.

DCC_calculator_v1.0.xlsx

Thanks,
Ibukun