TMS320F28379D: Undesirable issue with PWM Trip and Frequency when utilizing Missing Clock Detection, MCD

Hello JM,

We have a CLOCKFAIL signal coming out of MCD that can be used to trigger action/trip pwm outputs(set low, high, Hi-Z). I recommend you to refer to the Trip Zone Submodule in EPWM chapter of TRM(Technical Reference MANUAL)

You could clear the trip flag to start normal operation once you have clock setup. There is Ex1 Trip zone in c2000 ware to get started with in epwm examples then you can configure TZ5 which is connected to the system clock fail logic and set appropriate trip actions to it.

Thanks,
Prarthan.

Hi Prarthan thanks for your reply. 

I understand the trip zones quite well having already implemented it for many different purposes. However if you look in the attached photo, the PWM does not trip as expected. If CLOCKFAIL was detected I’d expect that the PWM would trip and stay tripped until it was reset. However there is a period where the PWM frequency is significantly slower than what it is programmed to be, 200kHz. 

The region of confusion is directly to the left and directly to the right of the rising edge of the yellow signal in the scope. It looks like the intermediate 10MHz clock is kicking in and causing some strange behaviour - does this look like normal functionality of the CLOCKFAIL trip? 

I don’t think the CLOCKFAIL trip is as simple as the normal trip zones as the clock frequency is changing. Can you suggest a logical flow of how I could achieve what I am attempting to achieve? It seems that the trip flag for the CLOCKFAIL signal seems to reset itself, rather than needing to be reset manually? 

Best regards,

JMH

Okay So you are already implementing the trip zone for clockfail in the image shown below ? FYI - The trip actions needs to be defined in Trip Zone Control Register (TZCTL) to take appropriate action.
Are you doing CBC or OSHT ?

Are you clearing the FLG before hand because only TZCLR Register can clear trip conditions on the latch like shown in image below. Reset source for these flags are sysrsn (system reset) which is clearly not happening here

Thanks!

I am sure I am using one shot trip zone. I will take another look tomorrow. Could you confirm whether the functionality I have described as desirable in the attached photo, and that the functionality shown in the photo does not look correct? 

I only reset the one shot trip zones when the controller initiates a new pulse, so we seem to agree that there is something else that is causing the erratic behaviour of the trip. 

Best regards, 

JMH

Yes if the trip is not cleared it should stay at the defined behavior in TZCTL reg.  
Can you send me your code I can have a look

JM Holland said:

I only reset the one shot trip zones when the controller initiates a new pulse,

What pulse are you taking about here ?

Thanks!

Hi Prarthan, 

The code I am using for the MCD is the exact same as that in the example folder for it in driverlib. I have not made any changes. 

I have a GPIO that is defined as an ENABLE signal, which either enables or disables the PWM via the trip zones. It was my worry that I was resetting it when it should not have been, but it turns out not the case in my opinion. The trip (fired at the same time as the NMI... seems to work fine). 

I have attached another screenshot below which shows the problem in better detail, I think. 

The NMI launching, and the PWM tripping, occurs on the rising edge of the yellow GPIO signal on the scope. 

There is some undefined behaviour before the NMI is launched and the PWM trips, and the TRM does state this takes around 0.89mS maximum to fire the NMI and trip the PWM. 

But this behaviour is certainly not desirable for a PWM controlled regulator, as for a short amount of time while the trip is occuring and we switch to the internal oscillator, the PWM frequency is substantially decreased. This will probably cause a lot of issues in the converter, but I am not sure if there is much we can do about this. 

Is there a better method, that can be run concurrently with the missing clock detection circuitry, that allows us to check that this fault has occured and to hold the PWM in a low-state throughout until the NMI flags are reset?

As a side note, what is the default clock source in the Launchpad? Do I have to manually set the clock source as the external oscillator for this to work?

It seems that the external oscillator is the default source, because otherwise shorting it wouldn't cause a clock failure, but trying to cover all bases.

Eagerly awaiting your reply,
JMH.

JM Holland said:

The code I am using for the MCD is the exact same as that in the example folder for it in driverlib. I have not made any changes. 

Example1_MCD in c2000ware simulates Missing clock and generates NMI there is no trip zone connection configuration for pwm to trip based on the clockfail signal generated here it needs to be done separately assume you are doing that already

JM Holland said:

There is some undefined behaviour before the NMI is launched and the PWM trips, and the TRM does state this takes around 0.89mS maximum to fire the NMI and trip the PWM.

Correct that is the time taken for the MCD to detect and act.

JM Holland said:

As a side note, what is the default clock source in the Launchpad? Do I have to manually set the clock source as the external oscillator for this to work

Yes Examples are all defined in function Device_init() to run on XTAL please refer to the device.h, DEVICE_SETCLOCK_CFG define there you can change the OSCSRC source there if you want.

Hi Prarthan, 

Are you sure? The TRM states that once the NMI is triggered for CPU1, the trip is automatically set and sent to the PWM modules. I already have all the actions defined for this, if that’s what you mean. 

So to confirm, the external Crystal oscillator is NOT enabled by default? What is the default clock source when calling device_init()? Can you not call device_init() and then use SysCtl driverlib function to change to the XTAL? 

I don’t believe I am yet to receive an answer regarding the issue. How can I avoid the frequency of my PWM significantly reducing once the clock is removed? The PWM trips will not be generated until the NMI is fired, meaning that if the clock is removed the PWM carries on as normal if something is not done to avoid it. 

best regards, 

JMH

JM Holland said:

Are you sure? The TRM states that once the NMI is triggered for CPU1, the trip is automatically set and sent to the PWM modules. I already have all the actions defined for this, if that’s what you mean. 

Yes I was not sure if you have pwm trip zone configured to use clockfail signal.

JM Holland said:

So to confirm, the external Crystal oscillator is NOT enabled by default? What is the default clock source when calling device_init()? Can you not call device_init() and then use SysCtl driverlib function to change to the XTAL? 

By default the source is INTOSC2 as shown in OSCCLKSRCSEL bit description below.

Examples are then configured to use XTAL defined in SysCtl_setClock() function, you can refer to device.h and see how DEVICE_SETCLOCK_CFG is defined as shown in image below. It sets the source and PLL settings all at once called by Device_init() function in the example.

JM Holland said:

I don’t believe I am yet to receive an answer regarding the issue. How can I avoid the frequency of my PWM significantly reducing once the clock is removed? The PWM trips will not be generated until the NMI is fired, meaning that if the clock is removed the PWM carries on as normal if something is not done to avoid it. 

The 8192 INTOSC cycles taken by MCD to take trip signal action is limitation there is no workaround to it.

Thanks!

No problem thanks for your help. 

Now that we know that INTOSC2 is the default clock signal, can we assess whether my signals look normal? 

In the case that XTAL is configured as the source, and the XTAL stops working or is shorted or otherwise removed, would you expect this behaviour? Should the green signal not just be zero volts and not oscillate at all? I’m really confused why it is changing frequency.

If this is the expected functionality then it is not suitable for a large number of power converters. For example in isolated converters, this significantly reduced frequency due to the clock transition would saturate the transformer, lead to large current flow, and most likely destroy the switching devices.

Just FYI, the green signal on my scope is a GPIO configured to have SYSCLK on it using the output XBAR and XLCKOUT functions. Yellow is the NMI ISR. Pink is the PWM and blue is my enable signal. Thanks.

INTOSC2 is default source on POR but example sets XTAL in initialization. That's why it detects MCD when you interrupt its normal operation.

Thanks!

Hi Prarthan, 

Can you confirm whether this is the expected behaviour of the PWM during an external clock failure before the NMI ISR causes the PWM to trip? That’s all I’m asking. If it is then we can confirm it is not suitable. I understand that INTOSC2 is the default source and that Launchpad examples switch this to the onboard external oscillator, but my question regarding the behaviour of the PWM once the Crystal is short circuited or otherwise removed, and before the NMI ISR has launched and tripped the PWM, remains unanswered. 

The ISR switches the clock source to INTOSC1, but the TRM states that once a clock failure is detected it automatically switches to INTOSC1. So it is impossible to tell what the expected behaviour is in the short period after a trip occurs and before the NMI ISR trips the PWM. 

Attached is an image of the MCD circuitry with the expected behaviour, occuring when the external crystal is shorted and the external control GPIO is low and tripping the PWM. This is what we intend to do throughout the system under all conditions to ensure it is safe under these faults.

Best regards, 

JMH

Prarthan, is there a way to enable and disable the MCD check circuits that we could implement? As mentioned previously, our PWM will automatically trip when our GPIO control signal is zero, as it is routed to TZ1 using XINT1. This automatically trips the PWM when it is low.

My idea was to only enable the MCD when the GPIO is low, and this works perfectly if the short occurs when the GPIO is indeed low.

However, if the crystal is shorted or missing when the GPIO is high, the behavior outlined above occurs. The GPIO will stay high until the clock has switched to the internal oscillator or the short is removed from the external crystal. 

If we could run the GPIO from an internal clock, it could change state despite the external crystal oscillator being shorted. We could then enable the MCD in the XINT1 ISR and switch the rest of the functionality to the internal clock, INTOSC1/2. Is there anything along these lines, or anything else that you can think of, that would allow us to avoid the PWM frequency being significantly reduced during a clock failure? 

Best regards,

JMH

Hello JM,

Please expect delay in response due to MLK holiday.

The 8192 INTOSC1 cycles is for circuit to determine loss of OSCCLK (which can be INTOSC2 or XTAL/X1). As soon as it detects loss of OSCCLK, NMI is generated and you can configure PWM actions in ISR.

JM Holland said:

Can you confirm whether this is the expected behaviour of the PWM during an external clock failure before the NMI ISR causes the PWM to trip?

There should be no change in pwm frequency before CLOCKFAIL is generated.
All the actions (NMI generation, PWM trip, Switch to INTOSC1) are taken at same time after loss has been detected by MCD circuit but the detection can be delayed by 0.8192 msec. 
The delay of 0.8192 ms (8192 INTOSC1 cycles) comes from the 13 bit counter that's counting up (2^13 =8192) for more details encouraged to refer to TRM.

So how do you explain the clock frequency changing, and the PWM frequency also changing, in the period between the short circuit occurring and the NMI being triggered? 

If the PWM works off of the external crystal, and this is shorted, how do you expect there is no change to the clock frequency and thus the PWM frequency?

The TRM itself states that the MCD switches to the internal clock, which before configuration, will be 10MHz. Not until the clock frequency has been set to 200MHz in the NMI ISR will normal operation occur. 

Can you at least explain or give an explanation of what you believe may be occurring during the MCD from the information I have provided? 

So while the MCD is detected (which might be 8192 cycles or 0.8192 msec delayed) the clock will still be supplied from original source (XTAL in your case).
And as soon as its detected it switches the clock source to INTOSC1 since its glitch free switch.

I don't expect the pwm frequency to change before NMI is fired, I will get back to you once I have replicated the same in lab. The digram below also states the same, Switch circuit that switches clock from output of SYSPLL to INTOSC1 depending on CLOCKFAIL signal so unless CLOCKFAIL is not asserted there is no switch.

Okay, so there is clearly something wrong since the clock frequency output on XCLKOUT, which is SYSCLK, is clearly changing during the fault. This would indicate that the comment "So while the MCD is detected (which might be 8192 cycles or 0.8192 msec delayed) the clock will still be supplied from original source (XTAL in your case).
And as soon as its detected it switches the clock source to INTOSC1 since its glitch free switch." 

Would not be true, unless there is something seriously wrong with the circuit.

Let me know if you manage to reconstruct the problem.

Thanks for your help, 

JMH

Hi Prarthan, sitll no update from yourself regarding the recreation of this problem - can you give it a go when you catch a minute as I am still fighting this issue.

Best regards,
JMH

Hello JM,

The GPIO toggle that is in the NMI ISR is delayed it doesn't guarantee that clockfail was generated at that time.
CLOCKFAIL is generated way before the GPIO toggle happens in NMI ISR.

When you are using CLOCKFAIL signal in epwm trip-zone submodule it generates trip immediately on CLOCKFAIL generation.
What is the time difference between pwm frequency changing and TRIP action happening on the PWM. Let me know if you have that from the test ?

Thanks,
Prarthan

Hello JM,

Following upon the above question:
Do you have the time interval measured between when pwm frequency changes to when PWM trip happens ?

Prarthan Bhatt said:

When you are using CLOCKFAIL signal in epwm trip-zone submodule it generates trip immediately on CLOCKFAIL generation.
What is the time difference between pwm frequency changing and TRIP action happening on the PWM. Let me know if you have that from the test