Hi!
I'm using a Piccolo control card, and the new one I got has also the XTAL mounted. I have several question about the use of XTAL.
1. It provides a more reliable clock signal than INTOSC1? It's in general better to use the XTAL if available?
2. I'm using the NMIINT to set some outputs before RESET in case of a CLOCKFAIL condition. When I use INTOSC1 as clock source, I use OSCOFF to simulate a missing clock. This is working as I expect. For the case in which I use XTAL as clock source, I don't understand how things should work. I simulate the missing clock by writing:
NmiIntruptRegs.NMIFLGFRC.bit.CLOCKFAIL = 1;
I get the interrupt, and I know the clock source is automatically switched to INTOSC1. I don't see any change in the registers ( I don't know if I look where I should... Sysctrl, NMIINT). I was thinking to let the system run with INTOSC1 as clock source ( is this a good practice or I should better let the system reset?) and only if INTOSC1 fails too, to let the system reset. So after the fail of XTAL, I try to simulate a failure on INTOSC1 using OSCOFF, but I get an error in the debugger, and I need to switch off the supply of the board to take the system out of the state it remained in.
Thank you,
Monica
Hi Monica,
Crystals typically provide a more stable clock without much drift or jitter. The internal oscillator's frequency drifts substantially with temperature which is why it must be trimmed periodically during operation to keep its frequency within spec. For applications which use an asynchronous communications peripheral, a crystal is typically required (UART, CAN, USB, etc.).
I wouldn't force the clock fail that way when using the crystal. Try just turning the crystal oscillator off by writing to the CLKCTL register (bit XTALOSCOFF). Try that and see if it behaves as you'd expect.
Regards,
Trey
Trey German
C2000 Applications
Hi Trey!
I've tried what you've told me in different ways. Still I don't understand it 100%.
1. INTOSC1 is configured to be OFF ( I use XtalOscSel() - F2806x_SysCtrl.c)
After the RESET, the execution gets in initPLL() -> asm(" ESTOP0"); This is strange because initPLL is called after XtalOscSel(); in InitSysCtrl(). I shouldn't have a valid clock after this point? And before InitSysCtrl() I check MCLKSTS and clear it. According to the flags I have both CLOCKFAIL and MCLKSTS were set before the RESET and the NMIWD caused the RESET. I don't understand why the RESET occurs after aprox. 62ms. The SYSCLKOUT is 80MHz, so it should be after 0.8ms. Or if the clock is switched automatically to INTOSC1 (still I don't understand what should happen - this happens also if INTOSC1 is OFF, is it switched ON in this automatic procedure?) SYSCLKOUT would be 40MHz and NMIWD reset should occur in 16ms.
2. INTOSC1 is configured to be ON ( in XtalOscSel() I changed SysCtrlRegs.CLKCTL.bit.INTOSC1OFF = 0; )
The RESET is caused by the Watchdog after 26ms, not by NMIWD. If the OSCCLK would be XTALCLK, the RESET should occur in aprox 6.4ms and if the clock source is changed to INTOSC1 in 13ms.
Hi again!
I've stopped the RESET, by clearing CLOCKFAIL and NMIINT bits in the NMIWD ISR. I've observed that SysCtrlRegs.CLKCTL.bit.XTALOSCOFF = 0; has no effect. I mean, the bit is changed in the register, but this doesn't restart the clock. After the first NMIINT was triggered, MCLKSTS is set ( that's why I don't get another NMIINT, the detection logic is disabled), so I suppose when INTOSC1 is configured OFF, in case of CLOCKFAIL, the missing clock detection sees this as a clockfail of INTOSC1, and the system is running now at limp frequency ( around 1MHz for my settings if I compute it right). Then the NMIWD reset after aprox 65ms makes sense.
If SysCtrlRegs.CLKCTL.bit.XTALOSCOFF = 0 doesn't restart the XTAL, then clearing MCLKCLR after RESET and only after this setting the clock source XtalOscSel(); cannot work.
if (SysCtrlRegs.PLLSTS.bit.MCLKSTS != 0) { flag_LIMP=1; EALLOW; SysCtrlRegs.CLKCTL.bit.XTALOSCOFF = 0; // Turn on XTALOSC SysCtrlRegs.PLLSTS.bit.MCLKCLR = 1; // Re-enable missing clock logic. EDIS; }
XtalOscSel(); // at this point MCLKSTS =1 already I suppose, so the next checking in intiPLL() gives the error message in the debugger.
if (SysCtrlRegs.PLLSTS.bit.MCLKSTS != 0) { EALLOW; SysCtrlRegs.PLLSTS.bit.MCLKCLR = 1; EDIS; // SystemShutdown(); function. asm(" ESTOP0"); // Uncomment for debugging purposes }
This will always happen if I test it in this way, right? So after XtalOscSel(); I should clear again MCLKSTS. But is this a good practice? If the clock from the crystal is lost, should I try to restart the system, is it possible to get again the clock signal? As I understand it, the reset gives a short OFF-ON to the supply line, could this restart the crystal? Or something went terribly wrong and it's safer to stop the system without any attempt to bring it back to normal operation? I ask this because I see that // SystemShutdown(); left in the file. Sounds like a critical failure from which recovery is impossible.
I've done the same test I did for the case INTOSC1 was the clock source. SysCtrlRegs.PLLSTS.bit.OSCOFF = 1. This doesn't stop the oscillator, right?
After reset, I clear OSCOFF.
if (SysCtrlRegs.PLLSTS.bit.MCLKSTS != 0) { flag_LIMP=1; EALLOW; SysCtrlRegs.PLLSTS.bit.OSCOFF = 0; // otherwise, a new missing clock is detected (reset doesn't change it) SysCtrlRegs.PLLSTS.bit.MCLKCLR = 1; // Re-enable missing clock logic. EDIS; }
For INTOSC1 this was working (reset caused by NMIWD and no error in debugger, code was executed from the beginning).
With XTAL is not working, and I don't understand why? The reset was also caused by NMIWD, but after that, the execution reaches again initPLL() -> asm(" ESTOP0"); like there is still a missing clock detected.
Thanks again,
Monica,
PLLSTS.OSCOFF just gates the clock from entering the PLL. The reference manual says to use this for testing missing clock detection. The oscillator should still be running in this case.
May I ask what you are ultimately trying to accomplish? I might be able to recommend a way to do what you want.
I wanna use XTAL as clock source, use NMIINT to put the outputs in a defined state in case of CLOCKFAIL and write something in the RAM to know that CLOCKFAIL caused the reset. After reset, I want to see the system running again, without having to start it myself because of the error in the debugger. If the CLOCKFAIL condition will still be there after reset, the system should be kept in reset. This is what I’m trying to test.
Ok, that makes much more sense now that I know what you're trying to accomplish.
Here is how I would do this:
Setup XTAL as clock source (setup the OSCSRCSEL bits in CLKCTL)
Set the NMIRESETSEL bit in CLKCTL to enable the NMI watchdog, this will give you time to service the NMI interrupt before reset
The system should start automatically after the NMI reset, but behavior may be funny if the debugger is connected while this is happening. If the clock fail condition is there on startup again, execution should will once again enter NMIINT where you can make sure the pins are in a good state before reset occurs again.
I've done all this, the problems appear exactly where you think too.... after reset, the behaviour is funny... I guess is because by the time I set XTAL as clock source again, the MCLKSTS bit is already set again. I don't know if I'm right, I don't know how to check this, I can only assume...
Hi Monica
I remember you have another thread on similar subject, were able to find a closure to your questions? http://e2e.ti.com/support/microcontrollers/tms320c2000_32-bit_real-time_mcus/f/171/t/172402.aspx
Below I'm trying to answer each of your questions.
Monica ZologI wanna use XTAL as clock source, use NMIINT to put the outputs in a defined state in case of CLOCKFAIL and write something in the RAM to know that CLOCKFAIL caused the reset.
> by default on reset/power-up NMI generation for CLOCKFAIL is disabled. User should enable this in their applicaiton code - be sure to enable PIE when you enable this NMI, otherwise any NMI generated when PIE is disabled will make the CPU fetch the vector from default ROM vector table.
> Also Make sure you are setting both CLKCTL.NMIRESETSEL and NMICFG.CLOCKFAIL bits to enable NMI generation on clock fail.
> Install proper NMI handlers and enable PIE before you enable CLOCK FAIL NMI
> When NMI is enabled a CLOCKFAIL causes NMI, it doesn;t cause the system reset. But if NMI is enabled and NMI is not serviced in time it will cause system to reset throgh NMIWD
Monica ZologAfter reset, I want to see the system running again, without having to start it myself because of the error in the debugger. If the CLOCKFAIL condition will still be there after reset, the system should be kept in reset. This is what I’m trying to test.
After reset (I think you mean after a reset becuase NMI is unserviced?):
> if CPU is running on secondary oscillator (OSC2 or external XTAL or XCLKIN) and if there is a missing clock then system will automatically switch to INTOSC1 and MCLKSTS is automatically cleared and Missing clock logic is re-enabled. If NMI is enabled then CPU will receive an NMI here. PLL will be automatically by passed here and user should re-lock the PLL if needed.
> if CPU is runnin on INTOSC1 (default clock on powerup) and if there is a missing clock then
> if NMI is enabled, MCLKSTS is set and NMI is generated and CPU is now running on LIMP clock and missing clock logic is disabled.
> if NMI is disabled, MCLKSTS is set and CPU is reset by missing clock reset and missing clock logic is disabled and CPU is runnin on LIMP mode.
Things to remember when testing missing clock logic:
> if you are testing INTOSC1 FAIL condition, then it is better to use OSCOFF bit instead of INTOSC1OFF, because INTOSC1OFF bit once set reset by only an XRSn and you might loose debugger connection when playing with this bit. So it is better to use OSCOFF bit for this case.
> if you are testing OSCCLK2 (INTOSC2 or external XTAL or SCLKIN) fail condition then you can use respective *OFF bits in the CLKCTL register.
Please let us know if above makes the missing clock logic a bit more clear to understand. I've put an NMI handler in my code to do exactly what you are trying to do so you can be sure that it will work.
Best Regards
santosh
Regarding the other thread, I didn't work anymore with INTOSC2, as I got a new control card that has the crystal mounted, so I will use XTAL as clock source. Trey explained me why it's better.
I guess I wasn't clear in my post. I've done all this and it's working (the interrupt is executed and then the system gets the reset). What is not working as I was expecting is exactly what you've mentioned in the last lines of your post. I lose the debugger connection. And not just this, the execution is stopped too.
I have XTAL set as clock source and INTOSC1 is disabled. I simulate a clockfail in 2 ways: OSCOFF and XTALOSCOFF. Both give the same results.
NMIINT is triggered, I do what I gotta do in the interrupt, and let the system reset. The reset occurs after about 60ms. According to my calculation, the system is not running with INTOSC1. If INTOSC1 would be the clock, the reset should occur in1.6ms. INTOSC1*16/4=40MHZ; 65535/40MHz = 1.6ms. Please correct me if I got it wrong. So my question was: if INTOSC1 is disabled, the system sees this as an INTOSC1 clockfail and goes to limp mode? Or the automatic switching of the clock source to INTOSC1 includes also enabling INTOSC1? Because according to the flags I have in my code, MCLKSTS was set after reset. This means INTOSC1 gave the clockfail condition, right?
After reset, I lose the debugger connection. If I hit Rude retry, I can see that NMIWD caused the reset. The execution stopped in InitPll() at
if (SysCtrlRegs.PLLSTS.bit.MCLKSTS != 0) { EALLOW; // OSCCLKSRC1 failure detected. PLL running in limp mode. // Re-enable missing clock logic. SysCtrlRegs.PLLSTS.bit.MCLKCLR = 1; EDIS; // Replace this line with a call to an appropriate // SystemShutdown(); function.-------->>>>>>>> asm(" ESTOP0"); // Uncomment for debugging purposes }
Another question: Why MCLKSTS is set at this point?
In main, first thing I do is to check if MCLKSTS was set, if yes: OSCOFF = 0; MCLKCLR = 1. I check also if NMIWD caused the reset and if yes: OSCOFF = 0,CLOCKFAIL = 1; NMIINT = 1. After this I set XTAL as clock source. Then I call initPLL(). And here the execution stops because MCLKSTS=1.
After reset, INTOSC1 is the default clock source, right? So after OSCOFF = 0; MCLKCLR = 1, there should be a valid clock, but somewhere between this point and initPLL, MCLKSTS is set again.
If you have the patience for this I can send the code.
Thanks,
Thanks for the information. From your explanation above, looks like you are seeing the debugger connection problems because you are switching off the default Oscillator.
Monica Zolog have XTAL set as clock source and INTOSC1 is disabled
When you switch off the default INTOSC1,
> if your CPU is running on secondary clock source (external XTAL, XCLKIN or INTOSC2) and if this secondary clock source goes missing, CPU will automatically switch to INTOSC1 and clears the missing clock status. But now since INTOSC1 is also missing (switched off) - the missing clock logic will detect another missing clock condition and now switch the CPU to work on LIMP mode clock and set the MCLKSTS. if you have NMI enabled then NMI will be triggerred otherwise CPU will be reset. Now after this reset INTOSC1 is still off and device is still trying to run on LIMP clock and MCLKSTS is set.
in the above conidtion if you have debugger connected it is likely that you will loose debugger connection because device is now on very slow (LIMP) clock.
Monica Zolog So my question was: if INTOSC1 is disabled, the system sees this as an INTOSC1 clockfail and goes to limp mode? Or the automatic switching of the clock source to INTOSC1 includes also enabling INTOSC1? Because according to the flags I have in my code, MCLKSTS was set after reset. This means INTOSC1 gave the clockfail condition, right?
So my question was: if INTOSC1 is disabled, the system sees this as an INTOSC1 clockfail and goes to limp mode? Or the automatic switching of the clock source to INTOSC1 includes also enabling INTOSC1? Because according to the flags I have in my code, MCLKSTS was set after reset. This means INTOSC1 gave the clockfail condition, right?
INTOSC1 will not be automatically enabled after it is disabled by software unless there is an XRSn or Power On reset. When CPU tries to switch back to INTOSC1 and if INTOSC1 is missing at this state then device will fall back to limp mode clock and MCLKSTS will be set.
Monica Zolog Another question: Why MCLKSTS is set at this point?
is it clear from above why MCLKSTS is still set? it is because INTOSC1 is missing and device is on LIMP clock.
Monica Zolog In main, first thing I do is to check if MCLKSTS was set, if yes: OSCOFF = 0; MCLKCLR = 1. I check also if NMIWD caused the reset and if yes: OSCOFF = 0,CLOCKFAIL = 1; NMIINT = 1. After this I set XTAL as clock source. Then I call initPLL(). And here the execution stops because MCLKSTS=1.
I'm not sure what you are trying to do, but above doesn't look right. If MCLKSTS is set when you are at main, then INTOSC1 (default clock) is missing. you should switch the CPU to secondary clock source and only then clear the missing clock status. If you clear the missing clock status before switching the clock source then CPU will detect another missing clock condition.
Monica ZologAfter reset, INTOSC1 is the default clock source, right? So after OSCOFF = 0; MCLKCLR = 1, there should be a valid clock, but somewhere between this point and initPLL, MCLKSTS is set again
yes, after reset INTOSC1 is the clock source. When INTOSC1 is the main source and you do OSCOFF that means that INTOSC1 is missing so device will go to LIMP mode clock and MCLKSTS is set. As mentioend above switch the clock source to secondary clock first and then do the OSCOFF if you want to see that device automatically switch back to INTOSC1. Keep INTOSC1 live here - you don;t have to turn it off when you want to simulate secondary clock source missing condition.
hope above helps. Let us know if anything is not clear in above.
Best regards
Santosh
Thanks Santosh!
This clarified everything: INTOSC1 will not be automatically enabled after it is disabled by software unless there is an XRSn or Power On reset.
To test this I was doing what you said: set the CPU to secondary clock source and only then clear the missing clock status, to avoid losing the connection every time. I wasn't sure is the right thing to do, coz I wasn't understanding when INTOSC1 is the default clock source. Now everything is clear.
I have some problems about PWM in dsp can you halp me
Post the problems first, then we'll see.
I want to generate 40khz pwm signal for a converter and want make a feed back to control duty cycle
I have TMS-2000 -28335 series DSP
thanks