An unexpected clock monitor reset can occur when:

I. The POSTDIV register is set to $00 or $01

II. The external oscillator gets enabled by writing the CPMUOSC register

while the PLL is locked (LOCK=1) based on the internal reference clock

(IRC1M)



Following general CPMU configuration sequence is assumed:

1. Configure PLL according to application needs (access CPMUSYNR,

CPMUREFDIV)

2. Configure CPMUPOSTDIV

3. Enable the external oscillator by writing the CPMUOSC register.

4. Wait for PLL lock



The issue could be annoying during debugging as above CPMU configuration

sequence is working in application (seamlessly executed by CPU) but

breaks due to clock monitor reset if Single Stepping done via debugger.



The issue might occur if the CPMU configuration sequence can be

interrupted (especially between Step 1. and 2. or 2. and 3.)and PLL

reaches locked state (LOCK=1).

 

In case a PLL lock occurs between Step 1.to 3. (see assumed general CPMU

setup sequence in the errata description):

a) Use a POSTDIV value higher than $01 at Step 2.

b) After PLL has locked (Step 4.) any value can be written to the

POSTDIV register without causing a reset.

Above workaround is recommended to avoid issues during debugging with

instruction Single Step or if the CPMU setup sequence can be interrupted.  

Configured for Infrared Receive mode, the SCI may incorrectly set the 

RXEDGIF bit if there are consecutive '00' data bits. There are two 

cases:    



Case 1: due to re-sync of the RXD input, the received edge may be 

delayed by one bus cycle. If an edge (bit = '0') is detected near 

an SCI clock edge, the next edge (bit = '0') may be detected one 

SCI clock later than expected due to re-sync logic. 



Case 2: if external baud is slower than SCI receiver, the next edge 

may be detected later than expected.



This glitch can be detected by the RXEDGIF circuit, but it does not 

impact the final data result because the SCI receive and data recovery 

logic takes samples at RT8, RT9, and RT10.

 



 

Case 1 and case 2 may occurs at same time. To avoid those unexpected 

RXEDGIF at IR mode, the external baud should be kept a little bit 

faster than receiver baud by:

                 P > (1/16)/(SBR)

                        or

                 (P)(SBR)(16)> 1



Where SBR is baud of receiver, P is external baud faster ratio. 

For example:

1.- When SBR = 16, P = 0.4%, this means the external baud should be at 

least 0.4% faster than receiver.

2.- When SBR = 4, P = 1.6%, this means the external baud should be at 

least 1.6% faster than receiver.

 

Case 1 will cover case 2, i.e. case 1 is the worst case. If case1 is 

solved, case 2 is also solved. 

If an active edge (falling if RXPOL=0, rising if RXPOL=1) on the RXD

input occurs shortly after the execution of the STOP instruction the

RXEDGIF is not asserted and the CPU is not woken up. The time window in

during which the edge is missed starts about 10 bus cycles after the

STOP instruction and is 2-3 bus cycles wide. 

(1) If more than one edge with a minimum distance of 4 bus cycles occur,

the 2nd edge will wake up the CPU. This is the case for instance in a

LIN bus system. "The Wake Up Signal consists of a dominant pulse minimum

250 microseconds and maximum 5 milliseconds in length, and it may be

sent by any LIN node."

(2) Use the API to enforce a periodic wake up and check the level of the

RXD input.

(3) Reduce the likelihood of occurrence by increasing the bus frequency.