SLAZ283AA October 2012 – May 2021 MSP430F5435
UCS Module
Functional
MODOSC can stop if deactivation time is short
If modules like the FLASH controller (default setting and not configurable) or the ADC12 (configurable) use the MODOSC as clock source and perform a de-activation followed by activation, the MODOSC can become stopped.
This can lead to a non-responsive device that can be released with a PUC (e.g. triggered by WDT) or any higher prioritized reset source.
The FLASH controller is waiting on its clock to perform a programming operation.
The FLASH controller example is as follows:
If two bytes were programmed after each other at dedicated frequencies with a dedicated instruction set, such as the following FLASH write routine:
MOV.W #FWKEY,&FCTL3 ; Unlock the flash
MOV.W #FWKEY + WRT,&FCTL1 ; Enable single byte write
MOVA &fpointer, R14 ; Configure flash destination pointer
MOVA #buffer, R13 ; configure source buffer
MOV.B @R13+, 0(R14) ; R14 pointing to flash address and CPU operates above 12.5 MHz
ADDA #0x01, R14\n
MOV.B @R13+, 0(R14)
MOV.W #FWKEY,&FCTL1 ; Clear Write
MOV.W #FWKEY + LOCK,&FCTL1 ; Lock the flash
Then, in this case, the device might be un-responsive due to MODOSC might stop and the FLASH controller is waiting on its clock to perform a programming operation. In this case, the device draws higher current because flash charge pump is enabled as the FLASH controller is in a programming loop.
In general, action needs to be taken to prevent MODOSC from a deactivation followed by an activation within 4 MODOSC clock cycles. This will ensure the MODOSC is properly disabled before being re-enabled.
For the FLASH use case above, this can be achieved by polling the BUSY flag located inside FCTL3 after each byte or word during programming.
In addition, no ADC12 sampling should be triggered within 4 MODOSC cycles after flash programming is finished. This can be achieved by disabling the ADC12 trigger during flash programming.