• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 82 subscribers
  • Views 185 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28035: CLOCKFAIL with "slow" quartz crystal

Stefan W
Intellectual 280 points
Part Number: TMS320F28035

Hi,

I am getting a CLOCKFAIL reset caused by an external quartz crystal with a long startup phase.

We use the TMS320F28035 in several applications with a default bootloader. To be platform independent the bootloader is always using the INTOSC1 und turning of XTALOSC. In the firmware we start and switch to the XTALOSC. Till now this has not been a problem. But now we have a new application with a new quartz crystal with a rather long startup phase of about 5ms. The controller seems to trigger a reset after about 1.2ms.

Based on the datasheet I would expect another timeout of at least 6.5ms:

  • As soon as we switch to XTALOSC PLLCR is set to 0 (I can confirm that when debugging).
    • So the systemclock should be sourced from INTOSC1 and bypass the PLL.
  • In our application PLLSTS's DIVSEL is set to 2, but in the worst case it is 3 (no divider).  
    • So the NMI-module should be clocked with 10MHz.
  • The NMI Watchdog Period is per default 65535.
    • So the timeout should be about 6.55ms.

Here the code we are using in the bootloader to stay on INTOSC1:

SysCtrlRegister.CLKCTL.Items.INTOSC1OFF   = 0;  
SysCtrlRegister.CLKCTL.Items.OSCCLKSRCSEL = 0;  
SysCtrlRegister.CLKCTL.Items.XCLKINOFF    = 1;  
SysCtrlRegister.CLKCTL.Items.XTALOSCOFF   = 1; 
SysCtrlRegister.CLKCTL.Items.INTOSC2OFF   = 1;

And here the code to switch to XTALOSC in the firmware:

SysCtrlRegister.CLKCTL.Items.XTALOSCOFF = 0; 
SysCtrlRegister.CLKCTL.Items.XCLKINOFF = 1; 
SysCtrlRegister.CLKCTL.Items.OSCCLKSRC2SEL = 0; 
SysCtrlRegister.CLKCTL.Items.OSCCLKSRCSEL = 1; 
SysCtrlRegister.CLKCTL.Items.INTOSC2OFF = 1; 
SysCtrlRegister.CLKCTL.Items.INTOSC1OFF = 1;

So what is happening here? Are my assumptions and calculations correct?

A timeout of about 1.2ms would be the result of the full 60MHz clock on the NMI. Is the PLL not bypassed in this scenario?

How could I suppress the CLOCKFAIL reset or wait for the XTALOSC before switching the OSCCLKSRCSEL?

Thanks and best regards,

Stefan

  • 0
    TI__Guru* 77410 points

    Stefan,

    While the Watchdog module it clocked off INTOSC1 as you mention and would have the associated delay, I beleive that what we are seeing in your scenario is a missing clock detect, which is using the native VCOClock of the PLL when it doesn't detect a clock at all happening well before the WD timeout as you mention.

    When you are turning on the external X-tal I would insert a manual delay after that instruction equal to the expected start up time, before enabling this as the system clock.  This shoud prevent the above from occuring.

    I think secondarily, as you mentioned, if this duration exceeds the Watchdog count, then you'll need to write to the associated WD clear registers during this wait.

    I would also recommend leaving the INTOSC1 enabled, even if you are switching to an external clock, both due to the above certainty of keeping the WD on a known good clock, as well as having a backup in case the X-tal goes missing so that the device can recover in a known manner vs a hard reset.  

    Let me know if you have further questions.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Intellectual 280 points

    Hi Matthew,

    thank you for your reply. I see that I misunderstood the concept of the CLOCKFAIL. I thought that the NMI Watchdog causes the CLOCKFAIL. I did not realize that the NMI watchdog is cascaded behind the real CLOCKFAIL logic and is not even active in my case.