TMS320F28377D: Missing Clock Detection - test

Hello TI experts. Any information on this?

Hi,

There is no change required between 379d and 377d devices for MCD.

What is your CLKSRCCTL1.OSCCLRSRCSEL setting? XTAL I am assuming. Are you using MCD example form C2000Ware ?

Could you check your MCDCR settings between two devices.

Thanks

Hi Prarthan,

Prarthan Bhatt said:

What is your CLKSRCCTL1.OSCCLRSRCSEL setting? XTAL I am assuming. Are you using MCD example form C2000Ware ?

Yes, XTAL.

Yes, referring to the example code from C2000Ware - sdl_ex_mcd_test.c

Prarthan Bhatt said:

Could you check your MCDCR settings between two devices.

I am using the same MCDCR settings for both devices. Using XTAL as clocks for both. However, XTAL configuration is different for both the 379d and 377d devices.

Hi,

I don't think XTAL frequency matters, can you confirm if the PLL gets locked before triggering MCD ?

What is the PLLSYSCLK ? What are your PLL configurations ?

Thanks

Hi Prarthan,

I can confirm that the PLL gets locked before triggering a MCD on both 77d and 79d devices.

f28379d launchpad:


f28377d:




PLLSYSCLK and Configurations:

f28379d launchpad:



f28377d:

Clock configurations look okay..

Can you share the screenshot of the MCDCR register in 77D MCU

I will have to check if I can find 77D locally to replicate on my end.

Thanks,

Prarthan.

Hi Prarthan,

PFA the screenshots:

1) Just after loading the firmware


2) After running the MCD test on 77d controller and waiting for NMI ISR to be executed:


Kindly let me know if you can replicate it on your end. Thank you!

Hi,

Chinmay Anand Deshpande said:

1) Just after loading the firmware

Here I see that the OSCCLKSRC is set to 0x3 INTOSC1. At this point did you configure the PLL already ?

It should be like below after initial PLL config : 

Chinmay Anand Deshpande said:

f28377d:

In previous reply image also I see the OSCLKSRC is 0x3. Do you know why it is different ?

I don't have the 77d mcu with me so I can try at my end. I would suggest you closely look at the PLL and MCDCR settings and compare them to debug the root cause.

If you have the oscclksrc as INTOSC1 then MCD cant trip hope thats clear after reading the manual

Thanks.

Hi Prarthan,

The above screenshot with CLKSRCCTL1 = 0x03 was taken just after resetting and restarting the debugger (The CLK switched to INTOSC1 after restart). The continuous refresh was set to off and hence the screenshot did not display the correct value of CLKSRC configured.

I can confirm that the CLKSRC has been configured as XTAL.




With 77d device:

1) Just after loading the firmware:

By default, the CLKSRC is INTOSC1



2) Just after Device_init() function is executed (Configures OSCCLK as XTAL):


3) After running the MCD test block and the control gets stuck waiting for NMI ISR to be serviced:







With 79d launchpad device:

1) Just after loading the firmware:

By default, the CLKSRC is INTOSC1


2) Just after Device_init() function is executed (Configures OSCCLK as XTAL):



3) Just after the missing clock is simulated:



4) Just after the MCD test is executed:







I am able to see the expected behavior with the 79d device but not with the 77d device as described above. 
Let me know if I am doing something wrong.

Hi Prarthan,

Also, a notable point is that the Missing Clock Detection works correctly with OSCCLKSRC configured as INTOSC2 for both the 77d and 79 devices. I am able to see the CLOCKFAIL = 1, NMIINT = 1, MCLKSTS = 1 with OSCCLKSRC = INTOSC2. So, looks like there is something wrong only with XTAL for 77d.

Hi,

Could you bring out the SYSCLK on the GPIO using the XCLKOUT feature. And monitor the clock after locking the PLL for both devices ?

One strange thing I see is the PLL SLIP status is showing as set (1) for 77D.

Chinmay Anand Deshpande said:

After running the MCD test block and the control gets stuck waiting for NMI ISR to be serviced:

SLIP status is set if the PLL reference clock goes too high or too slow while PLL is locked.

Thanks.

Hi Prarthan,

Device: F28377d

SYSCLK on GPIO:

frequency = 200Mhz (divide by 8 used for measurement)



XTAL on GPIO:

frequency = 10Mhz (divide by 8 used for measurement)

Should this have been 20Mhz for XTAL on 77d device?



XTAL from Oscillator source:

frequency = 20Mhz

Chinmay Anand Deshpande said:

XTAL on GPIO:

frequency = 10Mhz (divide by 8 used for measurement)

Should this have been 20Mhz for XTAL on 77d device?

That should not be a problem, XTAL can be from 10Mhz to 20Mhz

Is this only on one unit or you see it across multiple units and what if you used other XTAL instead does it work ?

Thanks.

Hi Prarthan,

I was able to reproduce the issue on another system with 77d controller. 

I used INTOSC2 instead of XTAL on the two 77d devices I have. The MCD test works fine on both. The issue is seen specifically when external oscillator is used instead of internal oscillator (INTOSC2) on 77d device.

Hi,

Is it possible that tolerance of the 10Mhz is too high, meaning the variation is too high at 10 Mhz for it to fail ? This looks like XTAL issue, to confirm we would need to try same XTAL on 77d as 79d control card/ launchpad, if that's possible ? 

Thanks