When using the Background Debugger to debug 

code which contains STOP instructions, the 

host debugger can lose clock sync with the

target device. If the ACK protocol is enabled,

a target command which is expecting to send

and ACK pulse, can conflict with a host issued

SYNC command attempting to re-establish clock

sync between the host and target. 

The ACK protocol can be disabled when debugging

source code which contains STOP instructions.

The host SYNC command may then be used to re-establish

clock sync between the host and target after 

a STOP instruction. 

The BSR instruction is recognized as a change of flow instruction and

thus causes the trace buffer to be loaded with its destination address.

Since the BSR instruction always branches to the relative address

specified in the instruction, the information stored in the trace buffer

at a BSR is not useful. Thus code making regular use of the BSR

instruction will result in considerable redundancy in trace buffer

contents. 

 

The severity of this bug is directly related to the frequency of BSR 

instruction use. Thus to reduce the impact of this bug, use of the BSR

instruction should be avoided wherever possible.



 

Write accesses to the registers can cause erroneous trigger action when 

using full mode (address AND data) triggers.



A AND B Trigger Mode

Writing to the registers using the A AND B trigger mode may not trigger 

the start of FIFO capture even though a valid successful compare should 

have occurred. Rarely, the same bug will cause an erroneous successful 

trigger even though an address and data match has not occurred.



A AND NOT B Trigger Mode

Writing to the registers using the A AND NOT B trigger mode may cause 

an erroneous successful trigger even though an address and data match 

has not occurred. Rarely, the same bug will prevent a trigger from 

being generated, even though a valid successful compare should have 

occurred. Reads of registers and reads and writes to non-register space 

are not affected by this erratum. 

No workaround exists



 

Several cycles are required after enabling a forced trigger before it

takes effect. 



This is expected behavior but not clearly noted in the user guide. Thus

it is classed as customer information (as opposed to errata). 

Take into account that extra cycles are required when using forced

breakpoints. 

If a write to ATDCTL5 happens at exactly the bus cycle when an ongoing

conversion sequence ends, the SCF, CCF and (if ASCIE=1)

ASCIF flags remain set and are NOT cleared by a write to ATDCTL5. 

1. Make sure the device is protected from interrupts (temporarily

disable interrupts with the I mask bit).

2. Write to ATDCTL5 twice. 

This Erratum applies only to systems where PLL is used to divide down

the osc_clock by a ratio between 2 and 3.



If



1) pll_clock (PLLON=1) is running

and

2) 2 < osc_clock/pll_clock < 3

and

3) full stop mode is entered (STOP instruction with PSTP Bit =0) 



there is a small possibility that when entering full stop mode the chip 

reacts as follows:

1) if self clock mode is disabled (SCME=0)  monitor reset is asserted.

   The system does NOT enter stop mode.

or

2) if self clode mode and SCM interrupt are enabled (SCME=1 and SCMIE=1)

   a self clock mode interrupt is generated. The SCMIF flag is set.

   The system does NOT enter stop mode.

or

3) if  SCME=1 and SCMIE=0 the system will enter full stop mode. 

   But after wakeup self clock mode is entered without doing the 

   specified clock quality check. The SCMIF flag is set. 

1) Avoid osc_clock/pll_clock ratios between 2 and 3.

or

2) if you really require osc_clock/pll_clock ratio between 2 and 3

do the following before going into stop.

a) deselect PLL (PLLSEL=0)

b) turn off PLL (PLLON=0)

c) enter stop

d) exiting stop: turn on PLL again (PLLON=1) 

If the FCLKDIV flash clock divider register has been loaded, and the

flash is not executing a command (flash CCIF command complete flag is

set), the execution of a STOP instruction will erroneously set the

ACCERR access error bit in the FSTAT flash status register. 

The ACCERR bit in the FSTAT register must be cleared after the execution

of a STOP instruction if the FCLKDIV register has been loaded. 

A write to the flash protection register that is immediately followed by

a flash array write will not set the PVIOL protection violation flag.



Example: 

 MOVB #$FB FPROT     //protect lower portion of flash page $3E 

 STD #$55AA #$8080   //write to protected address (PVIOL flag expected,

but does not occur) 

Perform a legal write of a register immediately after writing to the

FPROT register, before writing to the flash array.



Example: 

MOVB #$FB FPROT    //protect lower portion of flash page $3E 

MOVB #$30 FSTAT    //clear error flags (legal write to register) 

STD #$55AA #$8080  //write to protected address (PVIOL flag sets to show

protection violation) 

The setting of the CCF15-0 flags in ATDSTAT2/1 registers

is not independent of the clearing. 

A clear on CCFx (e.g. Bit AFFC=1 and read of ATDDRx)

which occurs in exactly the same bus cycle as the setting of any other

flag CCFy (x,y = 0,1,..,15; x!=y) masks the setting of CCFy.

CCFy will not set in this special case although the corresponding

conversion has completed and the result (ATDDRy) is valid. 

None.

Starting a new conversion by writing to the ATDCTL5 register should

clear all CCF flags in the ATDSTAT2/1 registers.

This does not always work if the write to ATDCTL5 register

occurs near the end of an ongoing conversion.

Although all CCF flags are cleared one CCF flag might be

set again within the 1st ATD clock period of the new conversion.

 

If the unexpected setting of one CCF flag can not be

accepted by the application one of the following

workarounds can be taken:

1) o Abort conversion (e.g. by write to ATDCTL3)

   o pause for 2 ATD clock periods

   o Start new conversion

2) o ignore first conversion sequence and clear CCF flags 

Breakpoints are temporarily disabled while the MCU is executing BDM

firmware code when operating in active BDM mode. It logically follows

that debug module triggers are disabled in the same manner. While tagged

triggers are disabled, forced triggers are not and therefore may cause

the debug module to trigger erroneously.



In most circumstances this will only be a problem in outside range

trigger mode. In order to see an erroneous trigger in another trigger

mode, a forced trigger must be configured in the BDM firmware address

range ($FF00-$FF80) and an exact address bus match must occur. This

memory area would typically contain interrupts, vectors or program code,

and would therefore be a very unlikely location for the configuration of

a forced trigger address.  

Outside range trigger mode should not be used when configuring forced

triggers if the trigger range contains the memory area where the BDM

firmware code resides ($FF00-$FF80) and the user intends to operate the

MCU in active BDM mode.



 

When the PMF is set to single time base mode (MTG = 0) reload 

interrupts from generators B and C can not be cleared by simply 

clearing the reload flag in the PMFFQCA register. 



In signle time base mode (MTG=0) there is no way to clear reload 

interrupts B and C.  These interrupts will always be pending when using 

reload interrupts in signle time base mode only.

 

Please reference Engineering Bulletin EB636 for a complete explanation

of the workaround. 

The problem concerns the DBG-CPU interface in DBG mode whilst tagging if

an interrupt occurs at the moment that a tag is attached to an opcode

being loaded into the instruction queue. 



If the DBG module is configured with BDM=DBGBRK=1, BEGIN=0 an event

causing a flag to be set should cause a break to BDM. The symptom is

that the flag gets set but the part does not enter active BDM mode. The

CPU executes the interrupt service routine instead and returns to the

correct position in the program flow but the breakpoint to BDM is

missed. 



The problem does not occur if the DBG module is configured for operation

in BKP mode (BKABEN=1). This is because even if the flag bit is set,

BKABEN bit is not cleared. Thus on returning from the interrupt service

routine the tag is re-applied when the PC is fetched after the interrupt

service routine. Thus the part enters BDM after the interrupt service

routine. 



In BKP mode with TRGSEL=0 no flags are set when a taghit occurs. 

In BKP mode with TRGSEL=1 the flag is also set erroneously, on entering

the interrupt service routine. However the user would typically not

notice the flag being set early unless the service routine were 

exceptionally long, because of the large time needed to read out the

DBGSR (flag bits) over the BKGD pin. In the meantime the part would

typically have entered active BDM anyway when the tag is re-applied.



Furthermore this does not occur on the older BKP module which does not

feature flags to indicate tag hits.  

None.

Upon leaving BDM active mode, the CPU return address is stored

temporarily for a few cycles in the BDM shift register. If a BDM command

transmission is detected during this time, the return address will be

manipulated in the BDM shift register. This situation is likely to occur

when a CPU BGND instruction is executed in user code during debugging

under the following conditions:



(i) The BDM module is not enabled AND

(ii) BDM commands are sent from the host



If this situation occurs, the CPU will execute BDM firmware and will

check the status of the ENBDM bit in the BDMSTS register. If the BDM is

disabled, the ENBDM bit will be clear, and hence the BDM firmware will

be exited and the shift register manipulation described above will occur. 

Avoid using the BGND instruction when the ENBDM bit in the BDMSTS

register is cleared. 

If the ECLK is used as an external bus control signal (ESTR=1) the first

external access is lost after switching from a single chip mode with

enabled ECLK output to an expanded mode. The ECLK is erroneously held in

the high phase thus the first external bus access does not generate a

rising ECLK edge for the external logic to latch the address. The ECLK

stretches low after the lost access resulting in all following external

accesses to be valid. 

Enter expanded mode with ECLK output disabled (NECLK=1). Enable the ECLK

after switching the mode before executing the first external access. 

With the SPI configured as a slave, clearing the SPE bit (to disable 

the SPI) together with clearing the CPHA bit while the SS pin is low 

causes the transmit shift register to be locked for the next 

transmission following the SPI being re-enabled as a slave with SS 

still being low. 



This means new transmit data is not accepted for the first 

transmission after re-enabling the SPI (indicated by SPTEF staying low 

after storing transmit data into SPIDR), but for the next following 

transmission.



 

When disabling the slave SPI, CPHA should not be cleared at the same time. 

Starting a conversion with a write to ATDxCTL5 or on an external trigger

event, and aborting immediately afterwards with a write to ATDxCTL0,

ATDCTL1, ATDxCTL2 or ATDxCTL3 can fail to stop the conversion process. 

Only write to ATDxCTL4 to abort an ongoing conversion sequence.



Use the recommended start and abort procedures from the Block Guide.

Section : Initialization/Application Information 

Subsection: Setting up and starting an A/D conversion 

Subsection: Aborting an A/D conversion 

It is possible that after the device enters Stop or Pseudo-Stop mode it

may reset rather than wake up normally upon reception of the wake-up

signal. 



CONDITIONS:

This will only happen provided ALL of the following conditions are met: 

    1) Device is powered by the on-chip voltage regulator.

    2) Device enters stop or pseudo-stop mode by execution of STOP

instruction by the CPU (providing the S-bit in CCR is cleared) 

NOTE: The part enters stop mode either after 12 oscillator clock cycles

with the PLL disengaged or 3 PLL clock cycles and 8 oscillator clock

cycles with the PLL engaged after the STOP command is executed. 

    3) The wake-up signal is activated within a specific very short

window (typically 11ns long, not longer than 20ns). The position of the

window varies between different devices, however it never starts sooner

than 1.6µs and never ends later than 4.7µs after the stop mode entry. 

This really narrow width of the susceptible window (20ns maximum) makes

the erratum unlikely to ever show in the applications life. 



The incorrect behavior will never occur if ANY of the wake-up conditions

are met at the time when the stop mode entry is attempted (an enabled

interrupt is pending). 



EFFECT:

If this incorrect behavior occurs, the device will Reset and indicate a

Low Voltage Reset (LVR) as the reset source. 

The device will operate normally after the reset. 

None.



--



Asynchronous Low Voltage Resets are possible in any microcontroller

application (due to power supply drops) and the integrated LVR and LVI

features and dedicated LVR reset vector are provided to manage this fact

cleanly. For best practice, the application's software should be written

to recover from a Low Voltage Reset in a controlled manner. 

An application software written to deal with valid Low Voltage Resets

should correctly manage erroneous LVR events. 



It can also be possible to avoid erroneous Low Voltage Resets from

synchronous wake-up events by configuring the application software to

ensure that the entry into stop occurs at such a time, in relation to

the wake-up event timer, that a wake-up event does not occur within

1.6µs to 4.7µs after Stop/Pseudo-Stop entry. 

When writing or reading the internal BDM resources (address range $FF00

to $FFFF) via BDM hardware commands, the /XCS Chip Select signal is

erroneously driven low during the BDM access. 



The /XCS signal is also driven low for CPU accesses performed to execute

BDM firmware when the CPU is in BDM active mode (BDMACT=1). This

includes the specific read/write cycle of the BDM firmware commands

READ_NEXT and WRITE_NEXT to access the targeted address of BDM firmware.



The R/W signal remains in read state in all these cases. The data

received by the above false external read accesses are discarded by the MCU.

 

None. 

If the PWM emergency shutdown feature is enabled (PWM5ENA=1) and PWM

channel 5 is disabled (PWME5=0) another lower priority function

available on the related pin can take control over the data direction.

This does not lead to a problem if input mode is maintained. If the

alternative function switches to output mode the shutdown function may

unintentionally be triggered by the output data.



 

When using the PWM emergency shutdown feature the GPIO function on the

pin associated with PWM channel 5 should be selected as an input. 



In the case that this pin is selected as an output or where an

alternative function is enabled which could drive it as an output,

enable PWM channel 5 by setting the PWME5 bit. This prevents an

active shutdown level driven on the (output) pin from resulting in an

emergency shutdown of the enabled PWM channels.



 

The pulse width of an output compare (which resets the free running

counter when TCRE = 1) will measure one more bus clock cycle than 

expected. 



 

The specification has been updated. Please refer to revision 01.02 (06 

May 2010) or later.



In description of bitfield TCRE in register TSCR2,a note has been added:

TCRE=1 and TC7!=0, the TCNT cycle period will be TC7 x "prescaler

counter width" + "1 Bus Clock". When TCRE is set and TC7 is not equal to

0, then TCNT will cycle from 0 to TC7. When TCNT reaches TC7 value, it

will last only one bus cycle then reset to 0.













 

When the PWM is used in 16-bit (concatenation) channel and the 

emergency

shutdown feature is being used, after de-asserting PWM channel 5

(note:PWMRSTRT should be set) the PWM channels (PP0-PP4) do not show 

the

state which is set by PWMLVL bit when the 16-bit counter is non-zero. 



 

None. 

In low power modes (stop/p-stop/wait ?PSWAI=1) and during PWM PP5

de-assert and when PWM counter reaching 0, the PWM channel outputs

(PP0-PP4) cannot keep the state which is set by PWMLVL bit.  





 

None. 

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.