Part Number: MSP430F6779A
Other Parts Discussed in Thread: CC2564
My customer has encountered a recent issue with the interaction between the MSP430F6779A and the CC2564 bluetooth module associated with coming out of LPM3 mode. On the errata, there are a couple workarounds described (use another clock or implement a delay) but we wanted to see if there were any other possible workarounds as well that may not have been mentioned because neither will work for their implementation. Also, was/is there a fix planned for this possibly in a subsequent revision of the die?
Link to the errata document: http://www.ti.com/lit/er/slaz597k/slaz597k.pdf
The specific item that we’re looking at is PMM12:
PMM12 PMM Module
Function SMCLK comes up fast on exit from LPM3 and LPM4
Description The DCO exceeds the programmed frequency of operation on exit from LPM3 and LPM4
for up to 6 us. When SMCLK is sourced by the DCO, it is not masked on exit from LPM3
or LPM4. Therefore, SMCLK exceeds the programmed frequency of operation on exit
from LPM3 and LPM4 for up to 6 us. The increased frequency has the potential to
change the expected timing behavior of peripherals that select SMCLK as the clock
source.
Workaround - Use XT2 as the SMCLK oscillator source instead of the DCO. (This cannot work since it doesn’t look like this MSP430F6779A supports XT2, no pins assigned)
or
- Do not disable the clock request bit for SMCLKREQEN in the Unified Clock System
Control 8 Register (UCSCTL8). This means that all modules that depend on SMCLK to
operate successfully should be halted or disabled before entering LPM3 or LPM4. If the
increased frequency prevents the proper function of an affected module, wait 32, 48, 80,
or 100 cycles for core voltage levels 0, 1, 2, or 3, respectively, before re-enabling the
module [for example, __delay_cycles(100)]. This cannot work, because when the scheduler has no tasks to run, it goes into LPM3 mode and an interrupt wakes up the processor. We are also communicating with CC2564 module at 115200 baud over UART. Each bit is about 8.6 micro seconds. Waiting for 100 delay cycles at MCLK=16 MHz is about 6.25 micro-secs. Considering interrupt latency, we are concerned that we may miss bytes/interrupts.
They considered using ACLK as source for UART baud rate generator, but ACLK can support only 32768 Hz and this may not be sufficient to generate 115200 baud.
Thanks,
Brian
