When tracing from both the CPU and the XGATE in Loop1 mode, multiple

XGATE entries caused by tight looping constructs are erroneously stored

in the trace buffer, hence the suppression of multiple XGATE entries

does not work as specified in loop1 mode. 



The suppression of multiple CPU entries is unaffected by this bug and

works correctly. The suppression of multiple XGATE entries works

correctly when tracing from the XGATE alone in loop1 mode.

 

Use multiple tracing sessions to trace the XGATE and CPU activity and

disregard the extra loop entries. The same information will be

extracted, however more tracing sessions are required due to the

repeated XGATE loop1 entries.



Depending on the application, it may be helpful to perform a tracing

session on XGATE alone in loop1 mode to get a picture of XGATE activity

without repeated loop entries. This can be used to determine points of

reference that can be compared to the tracing sessions with both the

XGATE and the CPU together. 

The PIT registers between addresses $0340 and $0347 can also be accessed

between addresses $0360 and $0367. Read accesses to the reserved

register space between $0360 and $0367 will return the contents of the

PIT registers instead of zero. Write accesses to the reserved register

space between $0360 and $0367 will change the content of the PIT control

registers. 

 

Do not access the reserved register space between addresses $0360 and

$0367. 

Both the RW and the RWE bits in the DBGACTL and DBGCCTL registers have

no effect in outside range trigger mode. Read and write qualification

specified by these bits is erroneously ignored by the DBG module. This

may generate erroneous triggers in outside range mode if read/write

qualification is expected by the user. If the DBG module is configured

for an outside range comparator match on read accesses only, a match is

additionally erroneously generated for a write access in the same range.

Similarly, when configured for an outside range comparator match on

write accesses, a match is additionally erroneously generated on read

accesses in the same range.

 

An outside range is equivalent to two inside ranges. If an outside range

with read/write qualification is required, two inside ranges with

read/write qualification covering the two areas outside the desired

range may be configured.

 

 

As both the TRIG and the ARM bits are contained in the same register

(DBGC1), the ARM bit is written by default when writing the TRIG bit.

Writing "1" to the ARM bit always initializes the trace buffer and the

DBGSR register (this includes situations when the ARM bit is written

with "1" when it is already set). When END alignment is configured, a

simultaneous write of "1" to the TRIG and "1" to the ARM bits

initializes the DBGSR. This may clear the TBF flag. The impact of this

initialisation will depend on the alignment mode that is configured.



When BEGIN alignment is configured, the TBF flag will not have been

previously set - by definition the trace session ends when the trace

buffer is full. However, the EXTF flag may have been previously set and

would hence be cleared by the initialisation described above. 



When MID alignment is configured, the initialisation described above

will clear the TBF and EXTF flags if they were previously set.



When tracing has started with BEGIN or MID alignment configured, an

initialisation as described above will restart the tracing session. In

this case, information stored in the trace buffer prior to the TRIG bit

being written to "1" is overwritten.

 

By configuring END alignment, the tracing session is immediately

terminated by writing "1" to TRIG, thus writing "0" to ARM

simultaneously would retain the DBGSR contents and prevent unexpected

TBF flag clearing. 



If the configuration of BEGIN or MID alignment is necessary, it is

recommended that the ARM bit is written as "1" when writing "1" to TRIG.

If the EXTF status is required, it should be read immediately before

writing "1" to TRIG to start the trace session. Depending on the

application it may be possible that tracing may have been initiated by

another match prior to the writing of the TRIG bit. In this case DBGSR

should be read to check whether SSF = 4. This indicates that the module

has triggered and that tracing has already begun. In this case it is

obviously not necessary to write "1" to the TRIG bit.

 

The XGATE registers between addresses $0380 and $03BF can also be

accessed from address $03C0 to $03FF. Read access to the reserveregister

space between $03C0 and $03FF returns the XGATE registers content

instead of zero. Writing to the reserved register space between $03C0

and $03FF changes the content of the XGATE registers. 

Do not access the reserved register space between $03C0 and $03FF.  

Pull devices which are configured on the following pins are not enabled

if the pins are configured as outputs in the associated data direction

register.



* SCI3 receive pin (RXD3) - Port M pin 6

* Re-routed SPI0 pin (MISO0) - Port M pin 2  

* Re-routed SPI0 pin (MOSI0) - Port M pin 4   

 

Set these pins to input using the data direction register when using

pull devices with SCI3 and re-routed SPI0. 

If a jump/branch instruction to a conditional branch is executed while

tracing in NORMAL/LOOP1 mode, the S12X_DBG module will erroneously store

the address of the previous jump/branch instruction incremented by two

instead of correctly logging the address of the conditional branch

instruction.



Example:

$E000                  TFR   CCR,R0      ;clear all CCR flags

$E002                  BRA   COND_BRANCH ;branch to conditional branch

$E004                  NOP

$E006                  NOP

$E008                  NOP

$E00A  COND_BRANCH:    BCC   SOMEWHERE   ;branch condition is true



The correct trace buffer entry for the above example would be:   



     source address = "$E00A"



The actual trace buffer entry is:



     source address = "$E004" (BRA address ($E002) incremented by two) 

Avoid jumps/branches to conditional branch instructions. 

When the XGATE resumes program execution from debug or freeze mode, the

address of the first instruction executed by the XGATE module will be

erroneously stored in the trace buffer. The same first instruction

address will be erroneously stored in the trace buffer every time a

single step is executed in debug mode. 

The BKDIF flag in SCIASR1 register is set when the SCI receives a break

frame with the BKDFE bit set in the SCIACR2 register. Writing a "1" to

the BKDIF flag should clear it, however it may remain set after the initial

write "1" to clear operation if the device is not configured with the

fastest baud rate.

 

If the fastest baud rate is selected, BKDIF will be cleared correctly.

If a slower baud rate is selected, BKDIF can be cleared by disabling the

receiver (by clearing the receive enable (RE) bit in SCICR2) and then

writing a "1" to BKDIF bit. The receiver can then be re-enabled if

required. If the receiver cannot be disabled during

run time due to application constraints, wait at least one sixteenth of a

bit time after the BKDIF bit is set and then clear the BKDIF flag by

writing "1" to BKDIF bit. If this procedure is not followed, the BKDIF

bit may set again immediately after it is cleared.

 

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. 

Debug block guide section 4.2.2 states "The comparator A and C bits are

used to tag range comparisons for the AB and CD ranges respectively. The

comparator B and D TAG bits are ignored in range modes."



This was not implemented in design, thus it is necessary to set both TAG

bits when configured for range tagging. Thus to tag in a range specified

by ComparatorA and ComparatorB, both DBGACTL and DBGBCTL TAG bits must

be set.



Similarly, when tagging in a range specified by ComparatorC and

ComparatorD, both DBGCCTL and DBGDCTL TAG bits must be set. 



Failure to set both TAG bits as described causes erroneous triggers to

be generated.

 

To tag in a range specified by ComparatorA and ComparatorB, both DBGACTL

and DBGBCTL TAG bits must be set.



Similarly when tagging in a range specified by ComparatorC and

ComparatorD, both DBGCCTL and DBGDCTL TAG bits must be set.  

CPU instructions that manipulate the stack can cause prolonged taghits. 

This can, depending upon state sequencer configuration cause multiple

state transitions. 



This is a problem when using the same (comparator) channel to trigger

on two consecutive state transitions. Thus if the state sequencer is

configured to transition from state[a] to state[b] on match[n] and then

transition from state[b] to state[a,c,d] on the next match[n], a double

transition can occur at the first taghit.





 

1) When tagging CPU instructions and using the state sequencer to

transition more than once before entering final state, avoid using

DBGSCR set to $00,$01,$02. Configure the state sequencer such that a

taghit on channel[n] transitions to a state in which DBGSCR is

configured so that a further taghit on channel[n] has no effect. 



2) If multiple state sequencer transitions at one particular CPU opcode

address are required, use separate comparator channels to tag the same

address. Then configure the state sequencer such that a taghit on

channel[n] transitions to a state in which DBGSCR is configured so that

a further taghit on channel[n] has no effect.   





 

All BDM read and write accesses to the Port Replacement Unit (PRU)

registers should take two cycles. Such accesses on this device take only

one cycle and the data that is read or written is corrupted. 

Do not use hardware commands to access the PRU from the BDM module.  

Tags to the CPU can be missed when clock stretching is enabled 

Only use CPU instruction tagging when clock stretching is disabled

 

When using range tagging, both bytes of the word should be tagged.

However, tags are only attached to even or odd bytes in range mode,

depending upon the contents of DBGxAL[0] (where x = A or C).



In most cases this is of little consequence. If the tag on the first

byte is missed when entering a range, the tag on the next byte

is hit, leading to a trigger. However, this can cause triggers to be

missed. This is particularly likely to happen if a subroutine is entered

that only contains the RTS instruction, and the alignment of this

instruction is different to that specified by the DBGxAL register. The

subsequent opcode is typically from the main program flow and not in the

specified range, hence the tag is missed and no trigger is generated.



Another example would be where a subroutine consists of two opcodes,

both of which should trigger and the second opcode is an RTS aligned

differently to the DBGxAL register. The first opcode is correctly

aligned causing the first trigger, but the second is incorrectly

aligned, thus the trigger is missed and the program leaves the

subroutine range. In this case a taghit is not generated by the next

opcode. 



 

Avoid the use of very short subroutines that consist of only a single

RTS instruction. Subroutines can be padded by inserting NOP instructions

if necessary.

 

Port Replacement Unit (PRU) read and write accesses from the CPU may be

corrupted if the accesses are followed by a free cycle that is used by

the BDM module. In this case, the data written to or read from the PRU

by the CPU will be corrupted. 

Do not use BDM hardware commands when the CPU is accessing the PRU

registers.

OR

Do not access PRU registers from the CPU when issuing BDM hardware

commands.  

If a particular error condition occurs within the end of frame segment

(EOF) of a CAN message, the msCAN module recognises and accepts a

non-valid message as being valid, contrary to the CAN specification. The

msCAN module incorrectly validates messages after five recessive bits of

the end of frame instead of after six bits. If a bus error occurs during

the sixth bit of end of frame, the msCAN module will already have

accepted the message as valid, even although an error frame is

transmitted and the receive error counter is incremented.



The CAN protocol states that message validation differs between bus

transmitter and receiver devices (refer to part B, section 5 of CAN

protocol for details). In the case where the 7th bit of the EOF segment

is dominant, the message is valid for the receiver but not for the

transmitter. This erratum extends this case to the 6th bit of the EOF

segment. 

This erratum will not be an issue if the application software is

protected against the known double receive problem of the CAN protocol.

This problem occurs when a message is not recognised as valid by the

transmitter, but is recognised as valid by a receiver, as described

above. When this happens, the message is re-transmitted and hence the

receiver will receive the same message twice.

 

Section 5.3.2.8, "BKDIF Description" in the SCI block user guide (v5.00)

states that "This flag [BKDIF] is also cleared if the bit error detect

feature is disabled."



There are two issues relating to this statement:

1. "cleared if the bit error detect feature is disabled" is a typing

mistake. This statement should read "cleared if the break detect feature

is disabled".



2. The clearing mechanism relating to the break detect disable is not

implemented on this version of the SCI module. The BKDIF flag will not

clear when the bit error detect feature is disabled.  

Clear the BKDIF flag manually by writing "1" to the BKDIF flag bit.  

A taghit from the TAGHI/TAGLO inputs can lead to double breakpoint

generation. The entry into the BDM firmware is repeated a few cycles

after the initial entry and this will cause a read of the program

counter to return an erroneous value. 



This can happen if the tagged instruction stays in the execution stage

of the instruction queue for longer than two cycles, which happens when

clock stretching is enabled or when instructions manipulate the stack. 







 

None.

Single byte reads of the trace buffer registers DBGTBH/DBGTBL increment

the internal pointer and read back a byte of the trace buffer. This

should be inhibited such that only word reads are accepted and attempted

byte reads are ignored and have no affect on the trace buffer pointer.

 

Always read the trace buffer registers DBGTBH/DBGTBL using 16-bit word

accesses. eg LDD DBGTBH.  

CPU accesses to all misaligned memory locations will fail when accessing

the Port Replacement Unit (PRU) registers from the XGATE module during

the same CPU cycle. When the XGATE module is accessing the PRU

registers, the CPU will wait until the XGATE access is completed. CPU

accesses to misaligned addresses are split into two successive byte

accesses. If the CPU is forced to wait between the two successive

accesses until the XGATE access to the PRU register is complete, the CPU

higher byte access is performed but the CPU lower byte access does not

occur. 

Do not access PRU registers from the XGATE module while performing

misaligned accesses with the CPU. 

In Normal Expanded Mode the data select signals /UDS and /LDS always

remain deasserted on any BDM access to the external bus and invalidate

the respective data. 

None.

The BDM module behaves incorrectly if the BDM handshake feature is

enabled and the BDM "GO_UNTIL" firmware command is followed by a CPU

"STOP" or "WAI" (with the core stops in wait mode bit (CWAI) set)

instruction before the "UNTIL" condition (BDM active) is reached.



When stop or wait mode is exited, the BDM module should be ready to

receive the next BDM command, and the acknowledge pulse of the

"GO_UNTIL" command should be aborted. However, after exiting from stop

or wait mode, the first bit of the initialization sequence (negative

edge and low for four cycles) sent from the host to the target is

erroneously interpreted by the BDM module as an abort sequence and not

as the start of a bit transmission.



This will occur only if the first bit of the next command is issued no

later than five hundred and twelve target clock cycles after exiting

from stop or wait mode (before BDM time-out).

 

Two workarounds are available:



1. Force the BDM module to time-out after exiting from stop or wait mode

(i.e. wait more than five hundred and twelve target clock cycles after

exiting stop or wait mode before issuing the next command to the target).



OR



2. Issue a "SYNC" command to the target after exiting from stop or wait

mode.  

When tracing using a begin or mid aligned trigger, the tracing session

ends when the trace buffer is full and this event should generate a

break request to the XGATE module if DBGBRK[0] is set. If the final

trace buffer entry is from code executing on the XGATE module, the break

request generation to the XGATE module depends upon the current clock

phase and has a 50% chance of occurring correctly. 



To summarise, this issue only occurs when:

1. Tracing with begin or mid alignment is configured.

AND

2. The last trace buffer entry contains XGATE data.

AND

3. The last trace buffer entry occurred during a particular phase of the

internal clock (50% chance of this situation occurring). 

If XGATE breakpoints do not occur when expected, using the configuration

described in this erratum, insert a "NOP" instruction to the XGATE code

thread and re-run the tracing session.

 

This issue occurs due to a specification issue.



When the MCU is secure and is reset into special single chip mode (by

forcing the BKGD pin low during reset), the on-chip firmware will check

whether the on-chip flash and EEPROM are erased before allowing BDM

communication.



No communication with the MCU is possible before the flash and EEPROM

blank check commands are executed and completed. If the Computer

Operating Properly Watchdog (COP) time-out period is shorter than the

time required for the blank check commands to complete, the MCU will be

reset before any communication is possible. In this case, the COP cannot

be disabled nor refreshed before a reset occurs and hence no

communication with the MCU will be possible and the MCU cannot therefore

be erased and unsecured.



In summary, it may not be possible to unsecure the MCU if all of the

following conditions are met:

1. The COP is enabled out of reset.

AND

2. The COP is configured with a time-out period shorter than 2^18 cycles

(by programming flash location $7F_FF0E with an appropriate value).



AND

3. The device is secured (by programming flash location $7F_FF0F with an

appropriate value).  

There is no workaround if the above conditions have been met. However,

there are two ways to prevent this issue if security is to be enabled:



1. Ensure that the COP is disabled out of reset (do not program flash

location $7F_FF0E).

OR

2. Ensure that the COP time-out period out of reset is set to 2^18 or

more cycles.  

When tagging an XGATE software breakpoint instruction (BRK), there is a

significant possibility that two separate tag hits may be flagged to the

debug module. This could result in an unintended transition in the debug

module state sequencer. 

Do not set XGATE hardware breakpoints at the same location as software

breakpoints. 

The spurious interrupt vector may be fetched and the associated service

routine may be executed if the PULCW instruction is used to set the

condition code register I-bit or to raise the interrupt priority level

while another interrupt is simultaneously pending. 

Do not use the PULCW instruction if an interrupt is pending. 

$0000 and $FFFF are allowed as the first Flash backdoor security key. 

None.

The comparator A and C databus compare feature does not generate a match

for misaligned word accesses of peripheral addresses. In this context

peripheral addresses are all addresses except internal RAM addresses.



 

None.

When the module is configured for Detail mode tracing, the trace buffer

 entries consist of memory/register access information. Each trace

buffer entry contains the address and data bus information assocaited

with the access,allowing the user to monitor all loads and stores. 



When tracing S12X CPU accesses in Detail mode, the misaligned word

accesses to peripheral memory locations are incorrectly stored to the

trace buffer. The trace buffer dataword entry is incorrect in this case.



XGATE detail mode trace buffer entries are not affected by this bug. 

Aligned word and byte accesses are not affected by this bug. 



Misaligned accesses of internal RAM are not affected by this bug.

  

None.

If the S12X_CPU and the XGATE attempt to lock a semaphore at the same

time the S12X_CPU will obtain the semaphore, but the Carry-Flag will be

set for the XGATE (falsely indicating that the XGATE has locked the

semaphore). 

Execute two consecutive "SSEM" instructions to set a semaphore. Ignore

result of the first "SSEM" instruction. Carry-Flag will indicate

correctly whether XGATE has allocated the semaphore after the second

"SSEM" instruction is executed. 

If the device executes the BACKGROUND command (received over BDM) in the

cycle when it is about to execute a tagged instruction the DBG module

may indicate that a tagged breakpoint was hit even though the tagged

instruction itself was not executed yet. 

If the DBG module indicates a tagged breakpoint hit after the BACKGROUND

command was issued, verify contents of PC to determine whether the

tagged breakpoint was hit or not. 

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





 

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 

The initial eight ID bits will be corrupted if a message is set up for

transmission during the third bit of INTERMISSION and a dominant bit is

sampled leading to an early-SOF*.



The CRC is calculated from the resulting bit stream so that the

receiving nodes will still validate the message.



An early-SOF condition may only occur if the oscillators in the network

operate at a tolerance range which could lead to a cumulated phase error

after 11 bit times larger than phase segment 2. 



In case arbitration is lost during transmission of the corrupt

identifier, a non-corrupted ID will be sent with the next attempt if the

transmit request remains active.



*The CAN protocol condition referred to as 'early-SOF' in this erratum

is detailed in "Bosch CAN Specification Version 2.0" Part A, section 9,

and a Note to section 3.2.5 INTERFRAME SPACING – INTERMISSION in Part B. 

Due to increased oscillator tolerance a transmission start in the third

bit of intermission is possible and allowed. The errata can be avoided

when calculating the maximum oscillator tolerance of the overall CAN

system. The phase error after 11 bit times due to the oscillator

tolerance should be smaller than phase segment 2.



If an early-SOF cannot be avoided the following methods will provide

prevention:



- Assigning the same value to all upper eight ID bits in the network

- Allocating dedicated data length codes (DLC) to every identifier used 

  in the network and checking for correspondence after reception

- Assigning only IDs (x) which do not consist of a combination of other 

  assigned IDs (y,z) and using the acceptance filters to reject 

  erroneous messages, i.e. 

  - for standard frames: IDx[11:0]  != {IDy[11:3], IDz[2:0]}

  - for extended frames: IDx[28:21] != {IDy[28:21],IDz[20:0]} 

When the ATD is started with write to ATDCTL5

and, which is very unusual and not necessary,

within a certain period again started with write

to ATDCTL5. The conversion will not start at all.

This does only happen if the two consecutive writes to ATDCTL5 occur 

within one "ATD clock period". An ATD clock period is defined by a full 

rollover of the ATD clock prescaler. That is for example PRS[4:0] = 2 -

> (2+1)*2 = within 6 bus cycles.

 

Only write once to ATDCTL5 when starting a conversion.



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 

When the ATD is started with write to ATDCTL5

and, which is very unusual and not necessary,

within a certain period again started with write

to ATDCTL5. The conversion will not start at all.

This does only happen if the two consecutive writes to ATDCTL5 occur 

within one "ATD clock period". An ATD clock period is defined by a full 

rollover of the ATD clock prescaler. That is for example PRS[4:0] = 2 -

> (2+1)*2 = within 6 bus cycles.

 

Only write once to ATDCTL5 when starting a conversion.



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 

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

channel 7 is disabled (PWME7=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 7 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 7 by setting the PWME7 bit. This prevents an

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

emergency shutdown of the enabled PWM channels.

 

Channel 0 – 3 Input Capture interrupts are inhibited when BUFEN=1, 

LATQ=0 and NOVWx=1 if an Input Capture edge occurs during or between a 

read of TCx and TCxH or between a read of TCx/TCxH and clearing of CxF.





Details:



When any of the buffered input capture channels 0 - 3 are configured 

for buffered/queue mode  (BUFEN=1, LATQ=0) each of the channel’s input 

capture holding registers and each channel’s associated pulse 

accumulator and its holding register are enabled. When the input 

capture channel is enabled by writing to a channel’s EDGxB and EDGxA 

bits, both the input capture and input capture holding register are 

considered empty. The first valid edge received after enabling a 

channel will latch the ECT’s free running counter into the input 

capture register (TCx) without setting the channel’s associated CxF 

interrupt flag. The second valid edge received will transfer the value 

of the input capture register, TCx, into the channel’s TCxH holding 

register, latch the current value of the free running timer into the 

input capture register and set the channel’s associated CxF interrupt 

flag. In this condition, both the TCx and TCxH registers are 

considered ‘full’.



If a corresponding channel’s NOVWx bit in the ICOVW register is set, 

the capture register or its holding register cannot be written by a 

valid edge at the input pin unless they are first emptied by reading 

the TCx and TCxH registers. The act of reading the TCx and TCxH 

registers and clearing the channel’s associated CxF interrupt flag 

involves three separate operations. Two 16-bit read operations and an 8-

bit write operation.



If a channel’s associated CxF interrupt flag is cleared before reading 

the TCx and TCxH registers and if a valid input edge occurs during or 

between the reading of the capture and holding register, a channel’s 

associated CxF interrupt flag will no longer be set as the result of 

valid input edges. For example:



Clear CxF

    |

    |

    V

Read TCx <----+

    |         |

    |<--------+--- Valid Input Edge Occurs

    V         |

Read TCxH <---+



If the TCx and TCxH registers are read before a channel’s associated 

CxF interrupt flag is cleared and if a valid input edge occurs between 

the reading of TCx/TCxH and the clearing of a channel’s associated CxF 

interrupt flag, a channel’s associated CxF interrupt flag will no 

longer be set as the result of valid input edges. For example:



Clear CxF

    |

    |

    V

Read TCx 

    |

    |<------------ Valid Input Edge Occurs

    V

Read TCxH





Systems that service the interrupt request and read the TCx and TCxH 

registers before the next valid edge occurs at a channel’s associated 

input pin will avoid the conditions under which the errata will occur.  

A simple workaround exists for this errata:



1. Clear the input capture channel’s associated CxF bit.

2. Disable the input capture function by writing 0:0 to a channel’s 

   EDGxB and EDGxA bits.

3. Read TCx

4. Read TCxH

5. Re-enable the input capture function by writing to a channel’s EDGxB 

   and EDGxA bits.





Code Example:



unsigned char ICSave;

unsigned int TC0Val;

unsigned int TC0HVal;



ICSave = TCTL4 & 0x03;  /* save state of EDG0B and EDG0A */

TFLG1 = 0x01;           /* clear ECT Channel 0 flag */

TCTL4 &= 0xfc;          /* disable Channel 0 input capture function */

TC0Val = TC0;           /* Read value of TC0 */

TC0HVal = TC0H;         /* Read value of TC0H */

TCTL4 |= ICSave;        /* Restore Channel 0 input capture function */ 

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 02.05 (04

 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.







 

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

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

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



 

None. 

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

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

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

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

 

None. 

When executing a flash erase verify (0x05) command sequence to a flash 

block different from the block where the backdoor keys are written to, 

both blocks will be erase verified. Any programmed location in either 

block will terminate the operation preventing the FSTAT.BLANK flag from 

setting.



When executing a flash data compress (0x06) command sequence to a flash 

block different from the block where the backdoor keys are written to, 

a given number of words from both blocks will be compressed, this 

number will be equal to the value written at last key’s address. The 

signature from the block containing the backdoor keys will affect the 

signature returned in the FDATA register.



When executing a flash program (0x20) command sequence to a flash block 

different from the block where the backdoor keys are written to, both 

blocks will be programmed at the same relative address with the 

unselected block being programmed to a data value equal to the last key 

written. Setting protection at the location in the block where the 

backdoor keys are written will not prevent the flash command from 

executing.



When executing a flash sector erase (0x40) command sequence to a flash 

block different from the block where the backdoor keys are written to, 

both blocks will receive the erase at the sector address provided in 

the flash sector erase command sequence. Setting protection in the 

location where the backdoor keys are written to will not prevent the 

flash command from executing.



When executing a flash mass erase (0x41) command sequence to a flash 

block different from the block where the backdoor keys are written to, 

both blocks will be erased. Setting protection in the block where the 

backdoor keys are written to will not prevent the flash command from 

executing.



The flash sector erase abort (0x47) command is not impacted as all 

active sector erase operations will be terminated if successfully 

aborted. 

Write 0x30 to FSTAT register (ACCERR = 1, PVIOL = 1) prior to 

executing any flash command sequence when backdoor keys have been 

written. This step can be done in conjunction with or instead of 

checking the FSTAT register as shown in the flash command sequence 

flow in the reference manual. 

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.