The EEE algorithm can produce duplicate records when a EEE buffer RAM 

location is written to a new value then changed back to the original 

data value.

When the EEE copy/erase processes the sector containing these records 

it cannot distinguish between the duplicates and does not remove older 

duplicates as intended. 

If large amounts of duplicate records occur the EEE can get to the 

stage where no space will be recovered by the copy/erase process, in 

which case the MGBUSY will remain continuously set. 

None. 

If a sector has to be invalidated during the EEE copy/erase process due 

to a write or erase fault, the algorithm continues the write/erase 

process until it has successfully regained the lost sector during which 

time a CCOB command will not be serviced. This is not a functional 

issue for the EEE but does extend the CCOB command latency.

For a worst case situation where the maximum amount of sequential 

records required to be

copied this could take as long as 13s. 

This condition will only be experienced where large groups of static 

(unchanging) data have been "written" to the EEE buffer RAM at the same 

time.  



 

None.



However, dispersing frequently updated data amongst static (unchanging) 

data will alleviate (but not remove) this extended EEE latency. 

Duplicate data records can be created in the case that there is new 

data pending for the same location associated with a record contained 

in the oldest sector being recovered by the copy/erase process. These 

duplicate records can end up in different sectors if little space is 

gained as part of the compress. This will result in the EEE system 

being unable to gain space in a few rotations of the data Flash.



The worst scenario would be 63 records repeatedly written to in a 

sequence such that the same 63 records appear in every sector. If 63 

tags are then set for these records a copy/erase cycle would not be 

able to recover any space and the MGBUSY flag would remain continuously 

set. 



These duplicate records can reduce the maximum amount of expected write 

cycles, this may be especially relevant for EEE configurations 

utilizing a low number of D-Flash sectors. 

None. 

If there are less than four available erased (READY) sectors available 

the EEE algorithm can start a copy/erase cycle when not at the end of 

the current sector.

If a double fault occurred at this point, while creating a record 

within that sector, the sector would be invalidated. 



In this scenario the original records contained in the sector requiring 

to be copied to a new sector will be lost. This situation is considered 

extreme and could only occur in the event of many double faults being 

generated which is associated with part being used well in excess of 

its normal operating life.

 

None. 

Certain IO values on the three lower bits of PortT (PTT[2:0]) can 

cause the internal Vreg output level to go out of specification. If 

the Vreg level is modified unintentionally, the device may function 

incorrectly and/or a low voltage reset (LVR) may occur. If pins PTT

[2:0] are required in an application, and the three scenarios 

described below (PTT[2:0] configurations with one pin high and two 

pins low) are unavoidable, it is possible to ensure that the regulator 

level remains within specification by configuring the logic levels on 

four or five PTAD0 pins (ATD0 channels). 



If the PT0AD0[5:0] input buffer value is non-zero, and PTT[2:0] = 100b

or 010b or 001b, then the voltage regulator output is affected and 

must be considered out of specification.



At reset, the default value of the PT0AD0[5:0] input buffer is 0x3F; 

this will result in lower than specified VDD/VDDF voltages if PTT[2:0] 

is equal to one of these values. 



Note - the value of the PT0AD0[5:0] input buffer can be modified by 

enabling the appropriate ATD0 digital inputs buffers (in the ATD0DIENL 

register) and either a) ensuring the associated input pins levels 

remain below VIL  or b) configuring them as output and writing the 

required buffer value to the PT0AD0[5:0] register bits. 



 

Workaround Proposal (1):



To avoid the above PortT configurations, do one of the following: 

a) Drive 2 of the 3 bits of PT[2:0] permanently to logic 1. The third 

pin can then be used as normal. Fixing PT[1:0] = 11b allows free use 

of PT[2]; fixing PT[2,0] = 11b allows free use of PT[1]; fixing PT

[2:1] = 11b allows free use of PT[0]

b) Drive any 2 of the 3 pins of PT[2:0] high always at the same time. 



Workaround Proposal (2):



To ensure functionality independent of PortT with LVR functionality 

enabled: 

Configure: 

        ATD0DIENL[5:0] = 111X11b 

        DDR1AD0[5:0] = 111X11b

        PT0AD0[5:0] = 000X00b 

This ensures that the voltage regulator output level remains at the 

nominal value, independent of PTT activity.



Workaround Proposal (3):



To ensure functionality independent of PortT without guarantee of LVR 

assertions:

Configure: 

        ATD0DIENL[5:0] = X11X11b 

        DDR1AD0[5:0] = X11X11b

        PT0AD0[5:0] =X00X00b 

This ensures that the voltage regulator output level remains at the 

nominal value, independent of PTT activity.

 

If a sector fails to erase verify the correct EEE action is taken with 

regards to invalidating that sector and using an alternative sector. In 

addition the ERSERIF flag in the FERSTAT register should be set to 

indicate this has occurred, however this flag is not set. 

The status of the number of sectors that have failed to erase can be 

determined by running the query command and monitoring the number of 

total invalid (or ‘dead') sectors. The number of invalid sectors should 

not exceed 25% of the number of active sectors. More than 24 invalid 

sectors will automatically generate a format error. 

In the case that a reset occurs as the EEE is writing the address field 

part of a data record for the buffer RAM word location 0x13FE1E’G, the 

record can be corrupted if the ECC field was not programmed before the 

reset.  Following the reset, the address field in the record (value 

0xBF0B) may be interpreted as a different address field value (value 

0xBFOF) incorrectly assigning the data record to RAM word location 

0x13FE16’G which will then be corrupted. 

Avoid powering down or resetting the device while the EEE is enabled 

and the memory controller is active.



Avoid using RAM location 0x13FE1E’G as this is vulnerable to corruption. 

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 event will only happen provided ALL of the following conditions are

met: 

    1) Device enters stop or pseudo-stop mode (see Stop mode entry

description below) 

    2) 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. 



Stop or Pseudo-Stop mode entry are: 

    1) Execution of STOP instruction by the CPU (provided 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.

    2) End of XGATE thread (providing the CPU is in stop or pseudo-stop

mode) 

    3) End of CCOB command executed by the NVM state-machine (provided

the CPU is in stop mode and XGATE is idle) 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.  

The internal priority for the software exceptions (TRAP, BGND, SWI, 

SYS) is incorrect in relation to other non-I-bit maskable interrupt 

requests. There are two scenarios for the resulting behaviour:



Scenario (1)

The internal priority of the software exceptions is lower than the 

priority of the MPU error and XGATE error exceptions. This leads to 

problems, if the MPU error interrupt request or the XGATE error 

interrupt request and the vector request for one of the software 

exceptions occur in the same cycle:



In case of a TRAP, SWI or SYS vector request occurring in the same 

cycle as the MPU error interrupt request or the XGATE error interrupt 

request, the CPU will get the MPU error vector address or the XGATE 

error vector address instead. The software exception will be lost.



In case of a BGND vector request occurring in the same cycle as the MPU 

error interrupt request or XGATE error interrupt request, the CPU will 

get the MPU error vector address or XGATE error vector address instead 

of the BGND vector address. Since the BDM firmware ROM is already 

inserted into the memory map, the vector address comes from the 

respective locations in the BDM firmware ROM instead of the regular 

memory locations. This results in a code run-away situation for the CPU.



Scenario (2)

The priority of the SYS software exception is lower than the priority 

of the XIRQ. In the case of a SYS vector request occurring at the same 

cycle as the XIRQ vector request, the CPU will get the XIRQ vector 

address instead. 

In this case, the XIRQ interrupt service routine is actually entered 

twice due to the first interrupt really being the SYS exception but 

with the wrong vector address (XIRQ).

The SYS instruction will be lost.

 

Scenario (1)

None.



Scenario (2)

Since the SYS instruction does not set the X-bit, the incorrectly taken 

XIRQ interrupt service routine is entered again immediately after the 

interrupt stacking sequence ended. This situation can be used to check 

in the XIRQ interrupt service routine if the problem has occurred: if 

the return address in the exception stack-frame points to the entry of 

the XIRQ service routine, it was entered twice (and SYS was not 

executed correctly) and the return address can be modified to jump to 

the SYS interrupt service routine. 

The memory controller RAM can lock up on a slow power up of the VDD core

supply such that no RAM access is possible. The condition is not

recoverable until the device is powered down and powered up again with a

faster VDD power up. This behavior is more evident at high temperature. 

The system power supply must rise adequately so that the VDD core 

supply powers up from 0V to 500mV within 1us across the operational 

range of the application (i.e. including the hottest required power up 

condition).

 

The system RAM can lock up on a slow power up of the VDD core supply

such that no RAM access is possible. The condition is not recoverable

until the device is powered down and powered up again with a faster VDD

power up. This behavior is more evident at high temperature. 

The system power supply must rise adequately so that the VDD core 

supply powers up from 0V to 500mV within 1us across the operational 

range of the application (i.e. including the hottest required power up 

condition). 

If the APIEA, APIES and APIFE bits are all set in order to output a

clock with twice the selected API Period at the external pin the

waveform at the pin can be incorrect. 

1) If using only positive edges of the output waveform is acceptable,

then use APIEA=1, APIES=0, APIFE=1 to output pulses at the API period. 



2) If a square wave at twice the API frequency is required either: 

a) Use the API interrupt to generate the waveform at an external pin via

software / GPIO functionality. 

b) Use APIEA=1, APIES=0, APIFE=1 and connect a T-flip-flop externally to

generate the waveform. 

The memory controller can prematurely halt an erase verify in the case 

that an ECC single bit fault is detected in either of the last two 

memory fields in the range being checked.



In this case a double bit fault in the last or next to last field may 

not be detected. Also any application count of single bit faults might 

be incorrect. These scenarios would require multiple faults to occur in 

the last three addresses in the memory region verified.



The following commands are affected:

Erase Verify All Blocks 		

Erase Verify Block 			

Erase Verify P-Flash Section 		

Erase All Blocks

Erase P-Flash Block

Erase P-Flash Sector 		

Un-secure Flash

Erase Verify D-Flash Section 		

Erase D-Flash Sector 		

Full Partition D-Flash

Enable EEPROM Emulation 

Any ECC faults in skipped locations will be detected and flagged during 

the verfy step of following Program operations. 

Pending data in the EEE buffer RAM data is prevented from being written 

to the EEE NVM when the EEE erase error interrupt flag (ERSERIF) is set.



As a sector erase error is not a fatal condition for the EEE, this is 

considered to be an errata which will be fixed in future.



As errata MUCts3665 prevents the ERSERIF being set, this particular 

problem will not be observed in an application.



 

This problem is masked in any case by errata MUCts3665. 



The level of 'sectors failing to erase' can be monitored by 

periodically executing the EEPROM Emulation Query command which reports 

the total number of invalid sectors. 

The memory controller remains busy (MGBUSY flag set) if all available 

EEE D-Flash sectors have been flagged as invalid. This can happen in 

the case that an EEE write or erase activity generates a fault in the 

last available valid sector and it is marked invalid.



This scenario can only happen if all sectors other than the erased 

(READY) sectors have suffered from errors. If the partition defined 

uses greater than 28 Data Flash sectors then this condition will be 

indicated cleanly by setting of the ERSVIF0 flag. 



This condition can only happen if all available EEE data sectors have 

been flagged invalid which would be an extreme condition associated 

with part being used well in excess of its normal operating life.  

Partition the Emulated EEPROM for >28 sectors of D-Flash (i.e. DFPART < 

99) and ensure that the ERSVIF0 flag is monitored (the associated 

interrupt can be enabled).



In the case there are 28 D-Flash sectors or less allocated for EEE the 

following considerations will avoid this condition:



(1) take care to not work the part in excess of its normal life. 

(2) use the EEPROM Emulation Query command to monitor the number of 

invalid (or 'dead') sectors after reset and flag a system error if the 

number of invalid sectors exceed 25% of the total sectors allocated for 

EEE. 

The memory controller will remain busy (MGBUSY flag set) following 

reset if all available EEE D-Flash sectors have been have suffered 

write or erase faults and have been flagged as invalid. This will 

happen during the reset copy down of the EEE data in the case that all 

available EEE D-Flash sectors have suffered from errors.



This scenario can only happen if all sectors other than the READY 

sector have suffered from errors. If the partition defined uses greater 

than 28 Data Flash sectors this condition will be flagged earlier as 

the maximum number of invalid sectors (24) will have been violated and 

flagged. 



This condition could only happen if all sectors had become invalid 

which would be an extreme condition associated with part being used 

well in excess of its normal operating life.

 

Partition the Emulated EEPROM for >28 sectors of D-Flash (i.e. DFPART < 

99) and ensure that the ERSVIF0 flag is monitored (the associated 

interrupt can be enabled).



In the case there are 28 D-Flash sectors or less allocated for EEE the 

following considerations will avoid this condition:



(1) take care to not work the part in excess of its normal life. 

(2) use the EEPROM Emulation Query command to monitor the number of 

invalid (or 'dead') sectors after reset and flag a system error if the 

number of invalid sectors exceed 25% of the total sectors allocated for 

EEE.

 

Simultaneous disarming (hardware) and arming (software) results in 

status, flag and counter register (DBGSR, DBGMFR, DBGCNT) corruption. 



Hardware disarming initiated by an internal trigger or by tracing 

completion takes 2 clock cycles. If a write to DBGC1 with the ARM bit 

set occurs in the final clock cycle of this disarming process, arming 

is suppressed but the DBGSR register is initialized to state1 and

DBGMFR/DBGCNT are initialized to zero.



The result is that the DBG module is disarmed by hardware but DBGSR 

indicates state1.



NOTE: DBGC1 is typically only written to whilst armed to set the TRIG 

bit or update the COMRV bits to map different registers to the address 

map window.



Generally during debugging, after arming the DBG module and returning 

to application code a further write access of DBGC1 over the BDM 

interface requires considerable time relative to application code 

execution, therefore in many cases the breakpoint may be reached before 

a DBGC1 update is attempted. Furthermore the probability of hitting the 

same cycle is seen to be very low.

 

If the fault condition is caused by writing to DBGC1 to set the TRIG 

bit (to request an immediate breakpoint), then the application code may 

be rerun again without the attempted setting of TRIG. The software 

trigger (TRIG) is unnecessary in any case at the same point point in 

time as an internal hardware trigger occurs.



Development tool vendors should avoid COMRV updates while the DBG is 

armed.



Users that observe the problem due to development tool COMRV updates 

can add a NOP to code and rerun to shift the disarm cycle, thereby 

preventing a collision with the COMRV updates. 

When the Analogue to Digital Converter converts an analogue value of

(Vrefh-Vrefl)/4 on any ADC channel, there is a risk to get a wrong value. 



When noise occurs on the input, the highest bit of the conversion result

can be erroneously set. 

This is because internal voltage comparators are asynchronous to the ADC

clock.

The error can only occur on the most significant bit when the conversion

result is measured as (Vrefh-Vrefl)/4 exactly.



The error always occurs on a unique value depending on the conversion mode:

- For 12-bit conversion if the result value is 1024 the ADC will

erroneously report a result of 2048. 

- For 10-bit conversion if the result value is 256 the ADC will

erroneously report a result of 512. 

- For 8-bit conversion if the result value is 64 the ADC will

erroneously report a result of 128. 



 

It is not possible to avoid the error occurring, however, it is possible

to minimize or avoid the effects of the error by using one of the

following methods:



- Reject values outside a determined sigma. For instance, when

monitoring slow-moving voltages (i.e. battery level), the software can

discard a conversion result which is greatly different from the previous

result and is the erroneous value.



- Simply discard conversion results of 2048 in 12-bit mode, 512 in

10-bit mode and 128 in 8-bit mode and use the previous result.



- Launch a new conversion when the conversion result is 2048 in 12-bit

mode, 512 in 10-bit mode and 128 in 8-bit mode and use the new result. 

If the EEPROM Emulation flow is reset (or powered down) during the 

programming or copying of data records in a data clean–up cycle 

(periodically caused by programming of an EEE data record to the D-

flash) and a successive Enable EEPROM Emulation command is also 

interrupted by a reset (or power down) then the EEPROM Emulation record 

system can become corrupted. 



This will be flagged following the second reset by the ACCERR, MGSTAT1 

& MGSTAT0 bits in the FSTAT register being set. 



This condition is not recoverable without re-partitioning the D-flash.

 

Ensuring the following will minimize susceptibility to this scenario -

a) that all EEPROM Emulation activity has completed (by checking 

ETAG = 0 and the MGBUSY flag in FSTAT is cleared) before the module 

powers down or generates any controlled reset.

b) that any other system resets that might occur during EEE programming 

activity are kept to a minimum. 

If the EEPROM Emulation flow is reset (or powered down) within a 20us 

window at the beginning of the programming of an EEE data record to the 

D-flash, this can cause the EEPROM Emulation to erroneously drop a 

sector from the flow as a dead sector. 

This error condition is managed correctly by the Emulated EEPROM flow 

and flagged by the setting of the PGMERIF flag in the FERSTAT register. 

This does not affect the EEPROM Emulation data or operation, however in 

the case that this occurs several times the maximum number of dead 

sectors will be reached and a critical EEPROM Emulation error flagged 

by the setting of the ERSVIF0 flag in the FERSTAT register. 

Ensuring the following will minimize susceptibility to this scenario -

a) that all EEPROM Emulation activity has completed (by checking 

ETAG = 0 and the MGBUSY flag in FSTAT is cleared) before the module 

powers down or generates any controlled reset.

b) that any other system resets that might occur during EEE programming 

activity are kept to a minimum.



 

If the EEPROM Emulation flow is reset (or powered down) during a data 

clean–up cycle (periodically caused by programming of an EEE data 

record to the D-flash) then if, following the reset, the Enable EEPROM 

Emulation command is executed twice by the application flow the EEPROM 

Emulation records system can become corrupted on the second enable. 

If the Enable EEPROM Emulation command is used only once during program 

execution after reset there is no issue. 



The error condition will be flagged by the second Enable EEPROM 

Emulation command setting the ERSVIF0 flag followed shortly by the 

SFDIF and DFDIF flags in the FERSTAT register.



Following any further resets this condition will also be flagged by the 

ACCERR, MGSTAT1 & MGSTAT0 bits in the FSTAT register being set. 



This condition is not recoverable without re-partitioning the D-flash. 

Only execute the Enable Emulated EEPROM command once in the application 

flow.



Ensuring the following will minimize susceptibility to this scenario -

a) that all EEPROM Emulation activity has completed (by checking 

ETAG = 0 and the MGBUSY flag in FSTAT is cleared) before the module 

powers down or generates any controlled reset.

b) that any other system resets that might occur during EEE programming 

activity are kept to a minimum.

 

The CPU execution priority encoder evaluates taghits and then 

generates  a breakpoint if a taghit must lead to an immediate 

breakpoint as determined by the DBG module.



If the DBG module indicates that this taghit leads to an immediate 

breakpoint then the CPU loads the execution stage with SWI or BGND thus 

generating the breakpoint.



At simultaneous taghits the lowest channel has priority.

If taghits on 2 channels simultaneously, whereby the lower channel tag 

must be ignored, but the higher channel tag must cause a breakpoint, 

then the breakpoint request is erroneously missed.

Thus if channel[1:0] taghits occur simultaneously whereby channel[0] 

must be ignored but channel[1] must cause a breakpoint, then the 

breakpoint request on channel[1] is erroneously missed and no 

breakpoint generated.



The DBG module recognises the taghit and the state sequencer 

transitions accordingly. Furthermore the taghit causes the DBG module 

to request a  forced breakpoint, which means that a late CPU breakpoint 

occurs. If the tagged instruction is a single cycle instruction, the 

breakpoint occurs at the second instruction following the tagged 

instruction.  

Otherwise the breakpoint occurs at the instruction immediately 

following the tagged instruction.



This bug requires that separate tags are placed on the same 

instruction. This is not a typical case when using exact tag addresses. 

It is more relevant in debugging environments using range modes, where 

tags may cover a whole range. In this case a tagged range may cover a 

tag or another tagged range, making simultaneous taghits possible.



This is a debugging issue only. 

Do not attach multiple tags to the same exact address. 

When attaching multiple tags to the same address by overlapping tag 

ranges in range modes, or covering a tag with a tag range in range 

modes, then the missed tag can be avoided by mapping the final state

change to the lower channel number.



For example the case

Channel[0] tags a range; channel[3] tags an instruction within that 

range. 

From DBG State1 Taghit[0] leads to State2.    (DBGSCR1=$6)

From DBG State2 Taghit[3] leads to FinalState.(DBGSCR2=$5)

In State2 a simultaneous Taghit[3,0] scenario would miss the breakpoint.



This can be avoided by using the alternative DBG configuration

Channel[2] tags a range; channel[0] tags an instruction within that 

range. 

From DBG State1 Taghit[2] leads to State2.    (DBGSCR1=$3)

From DBG State2 Taghit[0] leads to FinalState.(DBGSCR2=$7) 

If a misaligned word write access is directly followed by an attempted

entry into active BDM, then the second byte access may be performed on a

different target due to the memory map switching for BDM active. 



Depending on the type of access this can lead to the following situations...

1. When writing in the address range from $7F_FEFF to $7F_FFFD in the

external space the MMC splits the accesses into two 8-bit accesses. It

is able to complete the first access, but just before the second access

the BDM firmware becomes mapped into this address location and the

second byte access goes to the firmware.

This can only occur if the last cycle of the access instruction is a

word write to an odd address AND the instruction is followed by BGND or

a tagged breakpoint. 



This can only occur on devices featuring an External Bus Interface.



2. On a misaligned word write with a global store (GSTD,GSTS,GSTX,GSTY)

in the address range $XX_0FFF to $XX_3FFD, the first split access is

performed correctly in the external space, but in the second byte cycle

the MMC is instructed to interpret the address coming from the CPU as a

local address, which is the internal RAM. Since accesses to the RAM are

not split, the MMC enters an inconsistent state and never acknowledges

the CPU access. This causes the CPU flow to cease.

This can only occur if the CPU executes a global store instruction which

writes to an odd address in the last instruction cycle AND the

instruction is followed by BGND or a tagged breakpoint.



This can only occur on devices featuring an External Bus Interface.



3. Generally on a misaligned global store (GSTD,GSTS,GSTX,GSTY) the

lower 16-bits of the global address are interpreted as a local address

for the second byte access. This can result result in unintended

accesses to registers or external RAM.



 







 

Do not set breakpoints or insert BGND after a GSTD.



Remove all instances of BGND from code when not debugging.









 

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.

 

Where the IRQ interrupt is being used in edge-sensitive mode and a 

lower priority interrupt is already pending when an IRQ edge event 

occurs, if the IRQ edge event occurs inside a very narrow (<3ns) window 

just as the pending interrupt vector is being fetched, then a different 

vector other than that relating to either the pending interrupt or IRQ 

will be taken.

 

In the case that a programmed interrupt vector is fetched both the 

originally pending interrupt and the IRQ interrupt request will remain 

pending and will be serviced once the erroneously called service 

routine has completed (and RTI has been executed).



In the case that the incorrect vector fetch is from an unprogrammed 

vector table entry (i.e. erased state = 0xFFFF) then erroneous 

execution from the start of the register space will occur most often 

resulting in an illegal memory access reset, COP reset or Unimplemented 

Instruction Trap occurring. 



In the less likely case that one of the three reset vectors is 

incorrectly fetched then execution will jump to the appropriate reset 

code.  



The following vectors are not affected will not cause erroneous 

behavior if pending: 

$F0 - RTI

$F6 - SWI

$E2 – ECT channel 6

$B2 – CAN0 Rx

$72 – XGATE software trigger 0



This issue is limited to the edge-sensitive mode of the IRQ input only -

 applications not using IRQ interrupts or configured for level-

sensitive IRQ input are not affected.



There is no issue where a pending interrupt has higher priority than 

the IRQ request. 

Where using IRQ in edge-sensitive mode then configure the interrupt 

priority levels of all interrupts being used to ensure that the IRQ 

request always has the lowest priority. 



For new designs, where possible use the IRQ input in level-sensitive 

mode or alternatively use a key-interrupt port. 



There are a number of ‘best practices’ and features of the S12X which 

can help minimize the impact of this errata in the case of it occurring:



1) As ‘best practice’ initialize all unused and unimplemented/reserved 

interrupt vector table locations to point to a dummy interrupt service 

routine (terminated with an RTI). 



2) Where possible, check for appropriate asserted flags in interrupt 

service routines and return / flag a system error if no request flag is 

set.



3) Support is provided on the MCU for managing the following system 

conditions:

* COP watchdog reset 

* Illegal access reset 

* Unimplemented instruction trap

For ‘best practice’ the application's software should be written to 

recover from any of these conditions in a controlled manner. 



4) In the case of erroneous code execution jumping to unused Flash the 

typical practice of filling all unused Flash and RAM space with the op-

code for the SWI instruction will help manage this. SWI exception 

routine should be written in this case to manage this event.

 

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 */ 

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 do

not show the state which is set by PWMLVL bit when the 16-bit counter is

non-zero. 





 

If emergency shutdown mode is required:



In 16-bit concatenation mode, user can disable the related PWM 

channels and set the corresponding general-purpose IO to be the PWM 

LVL value. After a intend period, restart the PWM channels.



 

In low power modes (P-STOP/STOP/WAIT mode) and during PWM7

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

cannot keep the state which is set by PWMLVL bit.  









 

Before entering low power modes, user can disable the related PWM 

channels and set the corresponding general-purpose IO to be the PWM 

LVL value. After a intend period, restart the 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 V03.08 (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.







 

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 V02.07 (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.







 

If the PLL is manually turned off (PLLCTL_ PLLON = 0) before a STOP

instruction and the PLL is manually turned on (PLLCTL_PLLON=1) after

execution of the STOP instruction, the PLL might have a premature lock

condition in the case of a STOP instruction being executed with a

pending interrupt and the corresponding interrupt is enabled. In this

case the STOP is executed similar to NOP instruction. 



Due to the manual control of the PLL, the VCO clock is switched on and

off. The PLL lock detection logic uses the VCO clock as well as the

reference clock (based on the external oscillator). The external

oscillator is not stopped because the STOP instruction is executed like

a NOP instruction, which keeps the reference clock running. 



This causes the logic in the PLL lock detection being uncorrelated and

thus resulting in a possible premature LOCK condition (CRGFLG_LOCK=1). 



After the next lock detection cycle the lock is lost (CRGFLG_LOCK=0)

because the VCO clock frequency has not reached the correct value. Some

lock detection cycles later the correct lock condition is reached (VCO

clock frequency reached the correct value) and the LOCK bit is set again

(CRGFLG_LOCK=1). Each transition of the LOCK bit is indicated by the

lock interrupt flag (CRGFLG_LOCKIF). 

Do not modify the PLLON bit around the STOP instruction. 



The clock control and power down/up sequencing is automatically done by

the device CRG module. Only the system clock source selection after exit

from STOP must be controlled by software (CLKSEL_PLLSEL bit) as

described in the Reference Manual. 



Depending on the application if the fast wake-up feature is used the

software also needs to control the bit FSTWKP and bit SCME (both located

in the PLLCTL register) as described in the device Reference Manual when

STOP Mode is entered or exited.





 

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.