Hi Kriszti, I believe I may have reproduced your issue of the device always going to the oscillator fault ISR when you are doing CS_initFLLSettle. I don't have all of your code, but based on the test case I created on the MSP-EXP430FR4133 Launchpad the issue is that you have the oscillator fault interrupt enabled when you are calling CS_initFLLSettle at runtime and are changing the target frequency: as the routine runs it necessarily will have some faults as it adjusts the settings to tune in to the new frequency - this is why the code for CS_initFLL has a portion of it that waits for the FLL to lock and flags to clear before returning. Because you have the interrupt enabled, the device gets partway through CS_initFLL and then when the frequency bits are cleared in preparation for the new setting, it jumps to the oscillator fault ISR. Because you were not done setting up the clock to the new setting, the execution gets stuck in the oscillator fault ISR forever and your execution never returns to finish setting up the clock which would cause the fault to clear. I will file an enhancement request on driverlib that it would be good for CS_initFLL to save off the interrupt state and disable the DCOFFG while doing the new setting and restore it at the end of the function. For your present situation, I'd recommend calling SFR_disableInterrupt(SFR_OSCILLATOR_FAULT_INTERRUPT) before your run-time calls to CS_initFLLSettle and then re-enable the interrupt after CS_initFLLSettle. When I do this, the code is able to work correctly. I hope that this helps you get past your issue - then you should be able to run tests to evaluate if your frequency change is saving you power or not (because it adds execution cycles, depending on how long your actual UART transfer is it may not be worth it from a power perspective - but it depends on your application). Regards, Katie
↧