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.

RM48L952: DCC Configuration and Testing

Part Number: RM48L952
Other Parts Discussed in Thread: HALCOGEN

Hello,

I am struggling to create a test case to generate DCC errors or the RM48L952. It is our OE designed PCB and we use a 20MHz clock. We would like, but do not have to, detect drift in the OSCIN relative to another clock such that we can safely act upon a % excurision from nominal in a safe manner. The approach we are taking is to replace the OSCIN with a signal generator and change the input frequency up and down in an effort to trip the system with the appropriate ESM error logged. We never get DCC to trip, we always end up down at ~2.2MHz and an LPO trip. The ESM logic, nError activity and everything else we have in place makes sense and appears to work but we have not been able to create a test that will deliver DCC trips. I attach an example of our HALcogen configuration, where we look to check PLL against OSCIN. Can anyone point me to the flaws in our approach?

2816.CTLI-240_DCC_Config.pdf

Thanks

Jamie

  • Hello Jamie,

    Your configuration looks ok to me. Did you try the sample code in HALCoGen?

    7652.example_dccMeasureFreq.c

  • Hi Jamie,

    There is an issue with your approach here: the oscillator is also the input clock for the PLL, so that the PLL output will always scale with the OSCIN frequency. This essentially nullifies the test. The internal LPO clock sources (HF LPO preferably) are independent clock sources and are better candidates for use as reference clocks for the DCC measurements.

    The large tolerance on the LPO clock frequencies are primarily due to process tolerance. These frequencies are hence trimmed during testing (by TI) to be as close to their nominal values (10MHz for HF LPO) as possible, and not higher. So if you are actually using the LPO trim routine during start-up, you can configure the DCC assuming an HF LPO frequency of 10MHz as the reference clock and the OSCIN as the clock to be monitored.

    Let me know how it goes.

    Regards,
    Sunil
  • Hello Sunil,

    Originally I was looking at OSCIN relative to HF_LPO and we got the same results, no ESM trip until we were down at 2.2MHz and LPO kicked in.

    Where you say

    Sunil Oak said:
    So if you are actually using the LPO trim routine during start-up, you can configure the DCC assuming an HF LPO frequency of 10MHz as the reference clock and the OSCIN as the clock to be monitored.

    I do not intentionally run the LPO trim routine, all I have is the HALcogen generated code and default values of HF and LF trim at 100. Could this be a reason why we never had success testing DCC with OSCIN relative to HF_LPO?

  • Hi Jamie,

    Given that you are seeing an OSC FAIL indication at 2.2MHz, the HF LPO in your case seems to be running around 8.8MHz. Do you have the DCC configuration you used when you tried to detect OSCIN drift using the HF LPO as the reference clock?

    I will setup a test for this tomorrow and ensure that I do see an error flag from the DCC before the OSC FAIL detection gets triggered.

    Regards,
    Sunil
  • hello Sunil,

    I recreated our builds with OSCIN and HF_LPO selected. The HALcogen project is attached. I had tried two builds with the deviation set to 10% then 20%. In each case we do not get any activity on the nError pin or a DCC ESM fault until the LPO kicks in at 2.2MHz.

    3618.OS_HAL_PGE.zip

  • Hello Sunil, did you have a chance to check out my HAL package? If we cannot resolve the DCC configuration problem I will have to exclude it from my delivery.
  • Hi Jamie,

    I plan to test it tonight or tomorrow morning, and will let you know as soon as I am done. Also, here's a good app note for reference: www.ti.com/.../spna211.pdf

    Regards,
    Sunil
  • Hello Jamie,

    I did a test on RM42 launchpad. The OSCIN is clock source 0, and PLL is the clock source 1. The valid number is 158 (HALCoGen), bt I changed the valid to 15 (smaller window). Run the test, and I got error, and ESM interrupt (channel 30, of ESM group 1).