HAL_UCS changes with respect to oscillator fault checking

Can someone tell me why there was a change made in the oscillator start routines?

I did not find anything in the release notes. This change was made prior to level 1_80_xx_xx of the MSP430ware - maybe someone with a previous level can tell me when the transition was made, and why it was made.

It seems pretty drastic - from attempting to clear all 4 oscillator flags to clearing just the oscillator flag associated with the fault.

Another thing I have seen - if you artificially generate a XT1 fault by "shorting" the crystal, you will not clear that fault without attempting to clear the OFIFG flag.

HI Todd,

Not certain why it was done but my reading of the situation is that the problem with the first version is that the actual check is made on the global fault flag (SFRIFG1 & OFIFG)

If you want to Start XT2 when there is a problem with XT1 the loop will clear the flags for all of the oscillators, but if there remains a problem with XT1, then  XT1LFOFFG will get set again and will then set OFIFG, hence when OFIFG is rechecked you will stay in the while loop, even though you may not care about the XT1 fault.

I vaguely recall, that I had a problem of this type and had to change the functionality of the oscillator start routines in much the way this code has been changed.

To me the revised code makes more sense, If you want to Start XT2 you now check only the XT2 fault flag in the while loop, but clear the global flag once the XT2 fault has gone away.

Roy

Like Roy, I guess the change was made because the old version assumed that you only ever use one crystal. It did an endless loop for all fault bits to clear, even if you were just switching one crystal on and the other is still switched off but causes a fault. Same for the DCO, which may still generate a fault and prevent OFIFG from being clear.
The new version is just waiting during fault of the currently configured crystal. OFIFG will be successfully cleared on the last one, and won’t lock the while during the previous calls.

The problems are not with clearing multiple flags - the problems were with not knowing what the user will do with the other crystal after or has done before calling one of these functions.

Jens-Michael:

Do you know when this change was made? It looks like it was done prior to the release of MSP430ware_1_80_01_03 - but I do not have any copies of the MSP430ware prior to "1_80"

There are several earlier posts that show the OFIFG flag was being checked in 2011, 2012.

This may have some bearing on some of the RTC problems that I have been seeing, and I need to get a date and revision that the change was made.

I agree entirely with the logic that you and Roy have stated. Now, I need to know when that change was made.

Unfortunately, I can’t say. I don’t have a history of previous versions stored on my system (I only have this for datasheets and users guides). It’s a pity that older revisions of documents and software are simply replaced and the old one is gone. For the datasheets, there is at least a change history that points out which chapters were changed (to re-read them). This isn’t enough to see the exact change made, but much better than nothing.

Hi Todd,

I have an version 1_20_00_16 still knocking around on my system. The example code for the board in F5xx_F6xx_Core_Lib has the OFIFG check. However the code in the main driverlib ucs.c uses the individual oscillator flags in the while loop, so it would appear that the example code that uses Code_lib has been out of sync with the general driverlib for quite a long time.

Roy

Thanks, Roy and Jens

Jens, from what you have stated regarding DCO fault, it does not really sound like it is a fault at all, just a condition of the DCO. I have seen two things with the original code:

1. An occasional XT1 fault, that definitely causes ACLK to revert to REFO. When that happens and is not detected, the REFO-driven ACLK will cause my RTC to "slip," with the time differences being up to 45 minutes if allowed to run over several days.

2. Watchdog timeouts when trying to clear an XT2 fault. (XT2 is started when USB has been reconnected; XT2 is stopped when USB is disconnected and unit is running on battery power.) Watchdog timeout happens more often, but is caused by the inability to clear DCO fault.

By changing the clearing of XT2 fault with code that looks only at the XT2 fault bit (rather than OFIFG), the watchdog timeouts have pretty much gone away.

By adding a checking routine for XT1 faults, and clearing those faults with code that looks only at XT1 fault bit (rather than OFIFG), the ACLK appears to be tied mainly to XT1, and the RTC slips have gone away (so far). I am in the middle of long-term testing on several units, and the interim results are looking favorable.

well, the DCO fault is not a fault in the sense of no oscillation. The DCO cannot fail to oscillate (or else the MSP is bricked). However, having the DCO on lowest or highest tap indicates that it is not capable of running with the desired frequency as the FLL wants. So it is rather an FLL fault. It needs to be handled anyway, either by disabling the FLL and setting the DCO to a different tap (and maybe a different RSEL range) or changing the RSEL range so that the FLL can properly lock, or maybe by just waiting until the FLL has adjusted the DCO away from its borders.

Todd Anderson78572 said:

and I need to get a date and revision that the change was made.

I agree entirely with the logic that you and Roy have stated. Now, I need to know when that change was made.

I don't see how that matters. It is what it is now and you are using it to compile into your code, no?

If you upgraded from a previous version (that you compiled code with sometime in the past) then just get the code out of your source control repository and see what it was at that time.

When it changed in the interim seems irrelevant to me, so I don't understand why you ask.

Brian:

I work in a medical environment, and it matters. (I agree with what you have stated, but I need to know when it changed and why it changed.)

Does someone from TI know the answer?

Todd Anderson78572 said:

I work in a medical environment, and it matters.

Fair enough, I suppose.

But then I would argue that you should be getting your answer in writing from your TI FAE and not through an online forum. Then you have the legal paper trail.

Thanks, I will look into that!