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.

TMS320F28388D: NMI and Missing Clock Detect and Boot ROM

Part Number: TMS320F28388D

Hi,

I'm reading the TRM about the Missing Clock Detection logic and the associated NMI mechanism. Could you help me with these few questions?

  • In the example  sysctl_ex1_missing_clock_detection in driverlib it is explained that INTOSC1 can be used after a MCD as OSCCLK to restart the PLL and generate SYSCLK at 200MHz. Does it mean INTOSC1 can be used for 200MHz and it is only INTOSC2 that is limited to 194MHz (see datasheet)?
  • In order to know if a Missing Clock Detect has occurred is it better to check the MCDR[MCDSTS] flag or the NMIFLG[CLOCKFAIL] flag?
  • As far as I can understand the boot ROM clears the NMIFLG[CLOCKFAIL] flag and updates the "CPU1 Boot ROM Status" so does it mean that it's pointless to read NMIFLG in my application?
  • The CLOCKFAIL signal is shown entering the Trip Zone submodule of the ePWM peripherals on the TZ5 input. Can someone confirm that it can then be configured like any other trip source during ePWM initialization, so that we can decide whether the PWM outputs should be driven high or low upon a CLOCKFAIL event?

Kind Regards,

Pierre

  • Hi,

    Please see the response below -

    In the example  sysctl_ex1_missing_clock_detection in driverlib it is explained that INTOSC1 can be used after a MCD as OSCCLK to restart the PLL and generate SYSCLK at 200MHz. Does it mean INTOSC1 can be used for 200MHz and it is only INTOSC2 that is limited to 194MHz (see datasheet)?

    INTOSC1 and INTOSC2 spec are same. Will check this and get back to you.

    In order to know if a Missing Clock Detect has occurred is it better to check the MCDR[MCDSTS] flag or the NMIFLG[CLOCKFAIL] flag?

    Good to check both.

    As far as I can understand the boot ROM clears the NMIFLG[CLOCKFAIL] flag and updates the "CPU1 Boot ROM Status" so does it mean that it's pointless to read NMIFLG in my application?

    BOOTROM only clears it if it happens at startup (at reset which runs the bootrom code). If it happens during application run time then it need to be handled by application NMI handler. As mentioned in last point, it is good to check both status.

    The CLOCKFAIL signal is shown entering the Trip Zone submodule of the ePWM peripherals on the TZ5 input. Can someone confirm that it can then be configured like any other trip source during ePWM initialization, so that we can decide whether the PWM outputs should be driven high or low upon a CLOCKFAIL event?

    Yes, it can be configured to trip the PWM output.

    Regards,

    Vivek Singh

  • Vivek Singh said:
    As far as I can understand the boot ROM clears the NMIFLG[CLOCKFAIL] flag and updates the "CPU1 Boot ROM Status" so does it mean that it's pointless to read NMIFLG in my application?

    Thanks Vivek,

    Just to make sure I understand the mechanism: if the CLOCKFAIL is triggered during application run time then I can read NMIFLG[CLOCKFAIL] in my NMI interrupt handler, but if I don't implement a handler then the NMIWD will reset the CPU and then the Boot ROM will clear NMIFLG[CLOCKFAIL] thus preventing my application from reading it during its next run?

    Does the Boot ROM also clear MCDR[MCDSTS]?

    Regards,

    Pierre

  • Hello Vivek,

    I hope you can answer my last 2 questions soon, as I want to be certain I'm not missing any clocking anomaly when I start the board bring-up.

    A 3rd question has also come up more recently regarding a new set of registers which weren't present on previous devices: the SYS_STATUS_REGS. I would like to know why they have been introduced and what their intended usage is.

    Among other things I am puzzled by the SYS_PLL_SLIP flag. Is it an alias, or maybe a replacement of SYSPLLSTS[SLIPS] ? Given that the latter is now documented as "NOT_SUPPORTED" and "RESERVED" which was not the case on previous devices I'm not sure what to make of this.

    Kind regards,

    Pierre

  • I'll get back to you by end of the day today.

    Vivek Singh

  • Hi,

    Just to make sure I understand the mechanism: if the CLOCKFAIL is triggered during application run time then I can read NMIFLG[CLOCKFAIL] in my NMI interrupt handler, but if I don't implement a handler then the NMIWD will reset the CPU and then the Boot ROM will clear NMIFLG[CLOCKFAIL] thus preventing my application from reading it during its next run?

    If CLOCKFAIL is triggered during application run then yes, you can read the flag in NMI handler. If there is no handler hence a reset is issued then this reset itself will clear the flag. After reset if CLOCKFAIL condition is still there (clock is not recovered) then CLOCKFAIL flag will get set again and BOOTROM will clear it.

    Does the Boot ROM also clear MCDR[MCDSTS]?

    No, it does not clear this status.

    A 3rd question has also come up more recently regarding a new set of registers which weren't present on previous devices: the SYS_STATUS_REGS. I would like to know why they have been introduced and what their intended usage is.

    This register structure is new on this device and it has registers which flags the system level error. E.g. error/reset status on CM subsystem which is new on this device. Also on this device different errors are combined into one interrupt hence there is status register for all the error.

    Among other things I am puzzled by the SYS_PLL_SLIP flag. Is it an alias, or maybe a replacement of SYSPLLSTS[SLIPS] ? Given that the latter is now documented as "NOT_SUPPORTED" and "RESERVED" which was not the case on previous devices I'm not sure what to make of this.

    We do not recommend using these interrupt. As mentioned in the definition of SYSPLLSTS[SLIPS], user should use DCC for PLL SLIP.

    Regards,

    Vivek Singh

  • Hi Vivek,

    Before I mark this topic as resolved I would like to know if you managed to get more information regarding my very first question about the max frequencies of INTOSC1 and INTOSC2?

    Kind Regards,

    Pierre

  • Hi,

    In the example  sysctl_ex1_missing_clock_detection in driverlib it is explained that INTOSC1 can be used after a MCD as OSCCLK to restart the PLL and generate SYSCLK at 200MHz. Does it mean INTOSC1 can be used for 200MHz and it is only INTOSC2 that is limited to 194MHz (see datasheet)?

    As I mentioned, spec for INTOSC1 and INTOSC2 is same ( also given in "Table 5-17. INTOSC Characteristics" in device manual). The 194MHz restriction is because of 3% drift in oscillator frq which is mentioned in datasheet. This basically means when you lock PLL for 200MHz, the min frq can be 194MHz.

    Hope this is clear.

    Regards,

    Vivek Singh