• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 3 answers
  • Subscribers 100 subscribers
  • Views 616 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.

[FAQ] AM6422: How to Switch Back to External Clock After Clock Loss Detection

Pratibha Singh
Prodigy 130 points
Part Number: AM6422
Other Parts Discussed in Thread: AM6442

Tool/software:

Hi,

I am using the AM6442 Processor Evaluation Kit. We’ve been testing the Clock Loss Detection feature of the AM64x.

We provided a 25 MHz external clock to the processor, which we can manually enable and disable.

To test the clock loss scenario, we disabled the external clock and observed that the processor correctly detected the loss and switched to the internal 12.5 MHz RC oscillator.

Before disabling the clock, we modified the following register:

One more observation we had capture, we monitored the OBSCLK0 output using an oscilloscope. We mapped the OBSCLK0 pin to output MCU_HFOSC0_CLKOUT:

  • When the 25 MHz external clock is active, we observe 25 MHz on the oscilloscope.
  • After the fallback, the output changes to 12.5 MHz.
  • However, when the external 25 MHz clock is re-enabled, the oscilloscope again shows 25 MHz, but the processor continues to run on the internal 12.5 MHz clock.

Now, we want to confirm the behavior during external clock recovery.

Specifically, if the external 25 MHz clock is re-enabled, we expect the AM64x to detect the clock's return and switch back from the internal RC oscillator to the external 25 MHz clock.

Could you please confirm if this behavior is supported? If so, is any additional configuration required to enable switching back to the external clock?

Regards,

Pratibha

  • 0
    TI__Expert 3175 points

    Hi Pratibha,

    In the event of  MCU_HFOSC0_CLK clock loss, an external system intervention is required.  You should use the device MCU_SAFETY_ERRORn output pin to signal this condition to an external chip (the PMIC or another) which on the other hand initiates some recovery action in your system. Re-enabling the MCU_HFOSC0_CLK clock manually may not be sufficient. For more details, please refer to the section  Oscillator Clock Loss Detection of the AM6442 TRM.

    As a first resolution step could you please try performing a warm reset using the corresponding pushbutton on the EVM.

    Kind Regards,

    Anastas Yordanov

  • 0 in reply to Anastas Yordanov
    TI__Guru**** 199709 points

    Hello Anastas Yordanov,

    Thank you for adding the comments.

    Based on our discussion, i reviewed the reset architecture.  The observations are in line with your comments above.

    Regarding the OBSCLK0 or MCU_OBSCLK0 - there are configuration options to directly connect the 25M MCU_HFOSC0_CLKOUT to the observation clocks.

    Since an external oscillator clock is applied to Xi, the same clock is being reflected on the observation clock.

    Regards.

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 199709 points

    Hi Pratibha,

    Did you have a chance to power cycle the board and see the behavior with the oscillator disabled.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    Prodigy 130 points

    Hi Sreenivasa,

    Kallikuppa Sreenivasa said:
    Did you have a chance to power cycle the board and see the behavior with the oscillator disabled.

    We tried the power cycle of AM64x and observe 2 cases:
    1. Ocsilator Disabled: AM64x doesn't boot up.
    2. Ocsilator Enabled: AM64x runs on 25MHz clock.

    We modified the config to enable clock loss detection as mentioned in above post. Then we did the warm reset of AM64x and observe the following scenarios: 
    1. Ocsilator Disabled. Clock losss detected and after watchdog reset / warm rest AM64x runs on 12.5 MHz.
    2. Ocsilator Enabled: AM64x continued running on 12.5MHz not switched to 25MHz.

    We monitored MCU_SAFETY_ERRORn pin, during clock loss detection pin status changed from HIGH->LOW. However, there is no transition detected when 25MHz clock avaialble again.

     So, our main concern is how to detect the 25MHz clock recovered?

    Regards,

    Pratibha

  • 0 in reply to Pratibha Singh
    TI__Guru**** 199709 points

    Hello Pratibha, 

    Thank you.

    Pratibha Singh said:
    So, our main concern is how to detect the 25MHz clock recovered?

    I am not sure if there is away to detect the clock has recovered.

    In case the clock is not functional, as described in the initial message, the MCU_SAFETY_ERRORn pin is expected to be used to be informed of an error  and an external recovery mechanism is expected to be implemented. (performing a power supply cycling).

    During power cycle if the clock is not available, the processor does not start the boot-sequence.

    This is likely the actual use case. The case you have been testing is unlikely since the oscillator needs a mechanism to make it recover and that being the power cycle.

    Regards,

    Sreenivasa 

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Mastermind 21180 points

    Hello Pratibha, 

    Pratibha Singh said:
    Specifically, if the external 25 MHz clock is re-enabled, we expect the AM64x to detect the clock's return and switch back from the internal RC oscillator to the external 25 MHz clock.

    It's already everything covered above in the thread.  I just wanted to add that clock-loss-detection's  main goal is to allow the device to continue to function, although with limited capabilities, after an event that is critical for the system.

    quote from the TRM: "HFOSC0 clock loss is a catastrophic failure since this clock is the most critical system clock."

    Since a system designed to depend on external quartz clock will not be fully functional on a 12-MHz RC clock, it will need actions from outside. That's why the device clock would not be switched back to 25 MHz clock source automatically in HW.

    The software can spend the time during clock loss for:

    1.  Alarming the user via a machine-to-human interface like display, LED, or remote message. Note that many serial interfaces are sensible to the low accuracy of their clock source such as the 12 MHz R-C (no crystal) and the communication may not happen.

    2. Software may want to write an error log to a scratch pad or external flash memory

    3. PMIC may be configured, for example, it can try a full system power cycle to see if the system recovers.

    Eventually a human intervention such as checking the external crystal / external 25-MHz clock source, supply rails, etc. may be needed.

    Regards,

    Stan

  • 0 in reply to Stanislav Stilyanov
    TI__Guru**** 199709 points

    Hello Pratibha, 

    I added the inputs from out reset expert:

    The expectation is that the fault is routed to the ESM, and some external circuit would generate a power cycle or cold reset so the system can recover.  I think this is the only way the clock loss detection circuit would reset the detection.  Also, MCU_PORz is the only way CLKLOSS_SWITCH_EN bit gets reset.  So a warm reset will not help here, and that is why they observe the 12MHz_RC still clocking the processor after a warm reset

     

    The RC clock backup is not available immediately after PORz because of the default value of CLKLOSS_SWITCH_EN.  There is some setup that needs to happen anyway, in that the error needs to be routed to the ESM to trigger the ERROR signal, so that an external can do something about it (power cycle the device, for example).  When all that is setup, the RC clock will clock the device after a fault, but it is only intended to keep the ESM alive to generate the appropriate ERROR signal.  It is not expected that the device will operate fully.

     

    On a cold reset, if the 25MHz is not available, the device will not boot.  Even if the clock loss detection circuitry works at that point, the CLKLOSS_SWITCH_EN defaults to 0 as mentioned previously, so the mux will never switch to the RC clock.  Even if it would be able to switch, the ROM does not support booting with that input frequency.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    Prodigy 130 points

    Hi Sreenivass,

    Thank you for your support and inputs on the queries.

    Regards,
    Pratibha

  • 0 in reply to Pratibha Singh
    TI__Guru**** 199709 points

    Hello Pratibha, 

    Thank you. Will close the thread.

    Regards,

    Sreenivasa