Freescale SemiconductorMSEPFR4300MAE40_0M92D
Mask Set ErrataRev. March 05, 2007



PFR4300MAE40, Mask 0M92D


Introduction
This errata sheet applies to the following devices:

PFR4300MAE40



MCU Device Mask Set Identification

The mask set is identified by a 5-character code consisting of a version number, a letter, two numerical digits, and a letter, for example 1K79X. All standard devices are marked with a mask set number and a date code.



MCU Device Date Codes

Device markings indicate the week of manufacture and the mask set used. The date is coded as four numerical digits where the first two digits indicate the year and the last two digits indicate the work week. For instance, the date code "0201" indicates the first week of the year 2002.



MCU Device Part Number Prefixes

Some MCU samples and devices are marked with an SC, PC, or XC prefix. An SC prefix denotes special/custom device. A PC prefix indicates a prototype device which has undergone basic testing only. An XC prefix denotes that the device is tested but is not fully characterized or qualified over the full range of normal manufacturing process variations. After full characterization and qualification, devices will be marked with the MC or SC prefix.



Errata System Tracking Numbers

MUCtsXXXXX is the tracking number for device errata. It can be used with the mask set and date code to identify a specific erratum.



Errata Summary


Errata NumberModule affectedBrief DescriptionWork-
around
MUCts03005 chi_gsk Incomplete address decoding leads to non-functional buffers YES
MUCts03006 core_mfr4300 CRG register read after a byte write provides incorrect data in S12 mode YES
MUCts03043 flexray_ipi Receive Message Buffer is not updated after reception of invalid frames during a dynamic slot YES
MUCts03044 flexray_ipi Message Buffer can be locked/unlocked and en/disabled at the same time YES
MUCts03045 flexray_ipi Receive FIFO of depth 0 may cause incorrect system memory writes YES
MUCts03046 flexray_ipi Duration of startup state COLDSTART_LISTEN is too short after an aborted coldstart attempt YES
MUCts03047 flexray_ipi A boundary violation at the start of a slot or segment is not indicated in slot status YES
MUCts03048 flexray_ipi Very short static slots may cause sync frames on channel B not to be measured YES
MUCts03049 flexray_ipi A low bit during channel idle detection phase is detected as a syntax error NO
MUCts03050 flexray_ipi Clock correction values are updated before the start of NIT YES
MUCts03051 flexray_ipi A bit may be decoded with the value of its third sample causing loss of frame or symbol NO
MUCts03052 flexray_ipi A coldstart attempt is not aborted when the header of a received frame crosses a slot or segment boundary YES
MUCts03053 flexray_ipi Slot Status is updated during the dynamic segment of last startup cycle YES
MUCts03054 flexray_ipi A write to MBCCSRn with EDT and LCKS set to 1 is ignored YES
MUCts03127 flexray_ipi Sync frame tables reported incorrectly NO
MUCts03128 flexray_ipi Protocol Status Register 0 (PSR0) may not be updated after a RESET command YES
MUCts03129 flexray_ipi No decoding error detection for communication elements after a boundary violation NO
MUCts03130 flexray_ipi A received dynamic frame with the Null frame indicator set to 0 may be accepted as a valid frame YES
MUCts03234 flexray_ipi Update of PSR0[ERRMODE] not aligned with update of PSR0[PROTSTATE] YES
MUCts03235 flexray_ipi A syntax error may be indicated in the wrong slot if a communication element violates the slot boundary NO
MUCts03236 flexray_ipi Wakeup Pattern not detected after too long low phase or missing channel idle YES
MUCts03237 flexray_ipi Integration fails if a received startup frame begins close to the maximum drift boundary YES
MUCts03238 flexray_ipi No frame transmission in the dynamic segment when pLatestTx set to 1 YES
MUCts03239 flexray_ipi A frame received on channel A may not be stored in the subscribed receive message buffer YES
MUCts03333 crg_mfr4300 Improper device startup during the external reset procedure YES
MUCts03431 flexray_ipi Frame header recognized too early and decoding error in cycle count not detected NO
MUCts03432 flexray_ipi READY command in NORMAL_PASSIVE state ignored, if state will change to HALT in next communication cycle YES
MUCts03433 flexray_ipi Successful startup even though too few valid startup frame pairs received NO
MUCts03434 flexray_ipi Large sync frame deviations incorrectly measured and used by clock synchronization YES
MUCts03435 flexray_ipi Triggering pLatestTx violation not possible via message buffer setup YES
MUCts03436 flexray_ipi Transition from NORMAL_PASSIVE to NORMAL_ACTIVE when only one startup frame is received NO
MUCts03437 flexray_ipi A boundary violation frame followed by a valid startup frame during the startup phase may cause an abort of the startup NO
MUCts03438 flexray_ipi Byte write access to RFSIR register may corrupt its content YES
MUCts03509 crg_mfr4300 FlexRay communication disabled in dual channel mode with only channel B active YES
MUCts03522 flexray_ipi MVR register contains non-specified value during HALT mode entered by FREEZE NO
MUCts03599 clk_div CLKOUT can remain at "1" after external reset with CLK_S[1:0] set to "11" NO
MUCts03630 flexray_ipi Status bit MBCCSRn[DUP] not cleared after reception of emtpy dynamic slot YES
MUCts03679 flexray_ipi PIER1 register bits documented as read-only have read/write access YES



Incomplete address decoding leads to non-functional buffersMUCts03005

Description

The internal address decoding in the External Host Interface block is

not complete. Therefore, if there are host accesses to the CHI with
addresses that use bits 9 and 10 and bits 8 to 5 are set to 0111
respectively, then the External Host Interface block does not generate
or generates wrong accesses for the CHI. This is true for the following
adrresses: 0x2EN, 0x2FN, 0x4EN, and 0x4FN, where N is 0x0...0xf. This
means that the following message buffers cannot be used: 60, 61, 62, 63,
124, 125, 126, 127.

Workaround


Do not use buffers 60, 61, 62, 63, 124, 125, 126, 127 in the application. 




CRG register read after a byte write provides incorrect data in S12 modeMUCts03006

Description

When performing a byte write in S12 mode, and immediately afterwards

reading a CRG register, then the returned value can be incorrect. The
reason for this problem is that the previous byte write sets the device
internal byte enables, and the subsequent read operation within the CRG
uses these byte enable signals.

Workaround


Read the CRG register twice and ignore the result of the first read. 




Receive Message Buffer is not updated after reception of invalid frames during a dynamic slotMUCts03043

Description

If the FlexRay module has received only invalid frames during a dynamic

slot, the receive message buffer subscribed to this slot is not updated.
The following bits and fields are affected:
a) The Message Buffer Interrupt Flag MBIF in the Message Buffer
Configuration, Control, Status Register (MBCCSRn) is not set to 1.
b) The Data Updated status bit DUP in the MBCCSRn register is not changed.
c) The Slot Status in Message Buffer Header Field is not changed.

Workaround


The application can observe up to four slots in the dynamic segment

using the Slot Status Registers SSR0 up to SSR7. The FlexRay module
updates these registers at the end of the configured slot and provides
all slot status flags.
If any of the slot status error flags are set, the corresponding
aggregated channel status bit in the Protocol Status Register 3 (PSR3)
register is set. The application can monitor the status of the dynamic
segment when it clears all flags in the PSR3 register at the start of
the dynamic segment and checks the flags after the end of the dynamic
segment.
The Channel A/B Status Error Counter Register (CASERCR/CBSERCR) are
incremented by 1 for each slot status that has at least one error flag
set. The application can monitor the status of the dynamic segment if it
stores the value of the CASERCR/CBSERCR register at the start of the
dynamic segment and checks the value after the end of the dynamic segment.



Message Buffer can be locked/unlocked and en/disabled at the same timeMUCts03044

Description

If the application writes a value to a Message Buffer Configuration,

Control, Status Register (MBCCSRn) that has both the Enable/Disable
Trigger EDT and the Lock/Unlock Trigger LCKT bits set to 1 then both
triggers are executed. In this case, the outcome of the trigger
execution depends on the current message buffer state, and can result in
the message buffer being locked/unlocked and enabled/disabled at the
same time.

Workaround


Ensure the application never writes a value to a MBCCSRn register that

has both the EDT and LCKT bits set to 1.



Receive FIFO of depth 0 may cause incorrect system memory writesMUCts03045

Description

The FlexRay module may write to unintended system memory locations if:

a) the FIFO_DEPTH field in the Receive FIFO Depth and Size
Register(RFDSR) is set to 0, and
b) no system memory is allocated and configured for Receive FIFO message
buffers, and
c) a received frame passes the receive FIFO filters.
In general, the FlexRay module writes the received frame into the system
memory location defined by:
a) the System Memory Base Address High and Low Registers (SYMBADHR and
SYMBADLR), and
b) the Receive FIFO Start Index Register (RFSIR), and
c) the Data Field Offset value of the Message Buffer Header Field.
If any of the three values above is not configured, the FlexRay module
may write to an incorrect system memory address.

Workaround


Ensure the application sets the Receive FIFO Frame ID Rejection Filter

Mask Register (RFFIDRFMR) to 0 (RFFIDRFMR[FRDRFMSK]=0) when setting the
RFDSR[FIFO_DEPTH] to 0, in order to ensure that no frame will pass the
receive FIFO filters.



Duration of startup state COLDSTART_LISTEN is too short after an aborted coldstart attemptMUCts03046

Description

When the FlexRay module aborts a coldstart attempt and consequently

transitions to the COLDSTART_LISTEN state, it will remain in that state
for too short a period of time (less than 1 microsecond), if:
a) the FlexRay module is acting as a leading coldstarter, and
b) the coldstart attempt abort occurred while the FlexRay module was in
the COLDSTART_COLLISION_RESOLUTION state, and
c) the FlexRay module has received a frame, and
d) there are still coldstart attempts available, i.e. the Remaining
Coldstart Attempts field REMCSTAT in the Protocol Status Register 1
(PSR1) is greater than 1.

Workaround


Ensure the number of coldstart attempts field coldstart_attempts in the

Protocol Configuration Register 3 (PCR3) is configured to 2. With this
configuration, the FlexRay module will perform only one coldstart
attempt and the situation described above can never occur.



A boundary violation at the start of a slot or segment is not indicated in slot statusMUCts03047

Description

The FlexRay module only indicates slot or segment boundary violations

when they occur at the end of a slot or segment. Slot or segment
boundary violations that occur at the start of a slot or segment will
not be indicated in the respective slot or segment status.
The following counters and indicators are affected:
a) Channel A/B Status Error Counter Registers (CASERCR,CBSERCR)
If only boundary violations occur, the value of this counter is half the
number of actual boundary violations.
b) Network Idle Time (NIT) related boundary violation flags NBVB and
NBVA in the Protocol Status Register 2 (PSR2)
These flags are not set on boundary violations that occur at the start
of the NIT.
c) Symbol window related boundary violation flags SBVB and SBVA in the
Protocol Status Register 2 (PSR2)
These flags are not set on boundary violations that occur at the start
of the symbol window.
d) Slot boundary violation flags BVB and BVA in the Slot Status
Registers (SSR0–SSR7)
These flags are not set on boundary violations that occur at the start
of the slot.
e) Slot boundary violation flags BVB and BVA in the Slot Status of the
Message Buffer Header Field
These flags are not set on boundary violations that occur at the start
of the slot.
f) Increment condition STATUSMASK[1] of the Slot Status Counter
Registers (SSCRn)
The slot status counter is not incremented on boundary violations that
occur at the start of the slot.

Workaround


From the FlexRay Protocol Specification 2.1 it can be concluded that a

boundary violation at the end of a slot or segment implies a boundary
violation at the start of the next slot or segment. Consequently, for
each boundary violation at the start of a slot or segment, there was a
boundary violation at the end of the preceding slot or segment, which
can be indicated by the FlexRay module. The application can retrieve the
missing information of boundary violations at the start of a slot or
segment from the information provided for boundary violations at the end
of a slot or segment as follows:
a) A boundary violation occurred at the start of static slot 1, when a
boundary violation occurred at the end of the NIT
(PSR2[NBVB]=1,PSR2[NBVA]=1).
b) A boundary violation occurred at the start of static slot n (n>1),
when a boundary violation occurred at the end of static slot n-1.
c) A boundary violation occurred at the start of the first dynamic slot,
when a boundary violation occurred at the end of the last static slot.
d) A boundary violation occurred at the start of the Symbol Window, when
a boundary violation occurred at the end of the last slot.
e) A boundary violation occurred at the start of the NIT, when a
boundary violation occurred at the end of the Symbol Window / last slot.



Very short static slots may cause sync frames on channel B not to be measuredMUCts03048

Description

The FlexRay module may not correctly record all sync frames received on

channel B in the sync frame table if:
a) the static slot length defined in the Protocol Configuration Register
0 (PCR0[static_slot_length]) is less than 20 microseconds, and
b) the FlexRay module receives more than 5 consecutive sync frames, and
c) the FlexRay module receives sync frame on both channel A and channel B
The following registers and fields may be affected:
a) The Sync Frames Channel B, even cycle field SFEVB and Sync Frames
Channel B, odd cycle field SFODB in the Sync Frame Counter Register
(SFCNTR) may indicate a too small number of sync frames.
b) The sync frame ID table for channel B may not show not all received
sync frames.
c) The sync frame deviation table for channel B may not show all
received sync frames.
d) The clock synchronization will not consider the sync frames not
received, performs an incorrect clock correction, and the Rate
Correction Value Register (RTCORVR) and Offset Correction Value Register
(OFCORVR) may show incorrect values.

Workaround


No action is required if the FlexRay module is either configured in the

Module Configuration Register as a single-channel device (MCR[SCM]=1) or
in the dual-channel device mode (MCR[SCM]=0) with one disabled channel.
If the FlexRay module is in the dual channel device mode and both
channels are enabled (MCR[CHA]=MCR[CHB]=1), it needs to be ensured that
the protocol configuration fulfills at least one of the two following
requirements:
a) The static slot length (PCR0[static_slot_length]) is at least 20
microseconds.
b) Sync frames have no consecutive slot IDs, for example sync frames
allocated on odd slot IDs only.



A low bit during channel idle detection phase is detected as a syntax errorMUCts03049

Description

When the FlexRay module has transmitted a frame or symbol, and receives

a low bit during the channel idle detection phase that follows the frame
or symbol transmission, it will indicate a syntax error.
The following flags and fields may be affected:
a) Channel A/B Status Error Counter Registers (CASERCR,CBSERCR)
b) Symbol Window Syntax Error on Channel A/B flags SSEA and SSEB in the
Protocol Status Register 2 (PSR2)
c) Syntax Error on Channel A/B flags SEA and SEB in the Slot Status
Registers (SSR0-SSR7)
d) Syntax Error on Channel A/B flags SEA and SEB in the Slot Status of
the message buffer assigned to the respective slot.
e) Increment condition STATUSMASK[2] of the Slot Status Counter
Registers (SSCRn)

Workaround


There is no workaround. 




Clock correction values are updated before the start of NITMUCts03050

Description

If the FlexRay module runs in a cluster that has a dynamic segment

and/or symbol window configured, the FlexRay module may update the clock
correction values before the start of the Network Idle Time (NIT).
The following flags and registers may be affected:
a) Rate Correction Value Register (RTCORVR)
b) Offset Correction Value Register (OFCORVR)
c) Max Sync Frames Detected Interrupt Flag MXS_IF in the Protocol
Interrupt Flag Register 0 (PIFR0)

Workaround


Ensure the application reads the values for cycle N from the affected

registers after the start of the offset correction phase of cycle N, as
configured in the offset_correction_start field in the Protocol
Configuration Register 11 (PCR11), and before the end of the static
segment of the next communication cycle N+1.



A bit may be decoded with the value of its third sample causing loss of frame or symbolMUCts03051

Description

The FlexRay module may strobe a received bit at the third sample of the

filtered signal. This causes the two following erroneous behaviours.
The FlexRay module may ignore a frame or symbol if its reception starts
less that 1.3 microseconds after a low pulse with a duration of at least
two sample clock periods. In addition, this low pulse may be decoded as
a syntactically erroneous communication element and a syntax error is
indicated.
The FlexRay module may indicate a syntax or content error for a frame if
this frame contains a bit with a distortion in the third sample,
resulting in the frame not being tagged as valid.

The following flags and fields may be affected:
a) Channel A/B Status Error Counter Registers (CASERCR,CBSERCR)
b) Symbol Window Syntax Error on Channel A/B flags SSEA and SSEB in the
Protocol Status Register 2 (PSR2)
c) Syntax Error on Channel A/B flags SEA and SEB in the Slot Status
Registers (SSR0-SSR7)
d) Syntax Error on Channel A/B flags SEA and SEB in the Slot Status of
the message buffer assigned to the respective slot.
e) Increment condition STATUSMASK[2] of the Slot Status Counter
Registers (SSCRn)

Workaround


There is no workaround. 




A coldstart attempt is not aborted when the header of a received frame crosses a slot or segment boundaryMUCts03052

Description

The FlexRay module will not abort a coldstart attempt if:

a) The FlexRay module is acting as a leading coldstarter and
b) the FlexRay module is in the COLDSTART_COLLISION_RESOLUTION,
COLDSTART_CONSISTENCY_CHECK, or COLDSTART_GAP state, and
c) a frame is received whose frame header overlaps a slot or segment
boundary.

Workaround


If all coldstart attempts were unsuccessful, the application should

either let the FlexRay module integrate into the cluster as a
non-coldstarter or should retry coldstarting the cluster via the command
sequence of FREEZE, DEFAULT_CONFIG, CONFIG, READY, ALLOW_COLDSTART, and RUN.



Slot Status is updated during the dynamic segment of last startup cycleMUCts03053

Description

If the FlexRay module runs in a FlexRay cluster with a dynamic segment

and/or symbol window configured, the slot status update starts within
the dynamic segment or symbol window of the last startup cycle.
The following registers are affected:
a) Channel A/B Status Error Counter Registers (CASERCR/CBSERCR) start
counting
b) Slot Status Registers (SSR0-SSR7) are updated if already configured
c) Slot Status Counter Registers (SSCR0-SSCR3) start counting if already
configured

Workaround


a) The application can read the CASERCR/CBSERCR registers, after the

FlexRay module has left the STARTUP state, and store the values. When
the registers are read out at a later point in time, the stored value
must be subtracted from the current value in order to calculate the
absolute number of errors that have occurred after the STARTUP phase.
b) Ensure the application does not write to the Slot Status Selection
Register (SSSR) before leaving the STARTUP state.
c) Ensure the application does not write to the Slot Status Counter
Condition Register (SSCCR) before leaving the STARTUP state.



A write to MBCCSRn with EDT and LCKS set to 1 is ignoredMUCts03054

Description

The FlexRay module ignores any write access to the Message Buffer

Configuration, Control, Status Registers (MBCCSRn) if a value is written
that has both the Enable/Disable Trigger EDT and the Lock Status LCKS
bits set to 1.

Workaround


Ensure the application clears all other bits when writing a value to a

MBCCSRn register with the Enable/Disable Trigger EDT set to 1.



Sync frame tables reported incorrectlyMUCts03127

Description

The FlexRay module may not always report the correct size of the sync

frame tables for the FlexRay communication cycle during which the clock
correction starts, if the FlexRay module was not acting as a leading
coldstarter, and the FlexRay communication cycle contains neither a
dynamic segment nor a symbol window.
The following registers and fields are affected:
a) The Sync Frames Channel A field SFEVA and the Sync Frames Channel B
field SFEVB in the Sync Frame Counter Register (SFCNTR) contain 0
instead of the number of sync frames used for clock synchronization.
b) The sync frame ID and sync frame deviation tables for the affected
communication cycle are not updated .

Note: This is only a reporting and transfer problem. The FlexRay module
will use the correct sync frame tables for clock synchronization.

Workaround


There is no workaround. 




Protocol Status Register 0 (PSR0) may not be updated after a RESET commandMUCts03128

Description

The FlexRay module may not always update the Protocol Status Register 0

(PSR0) when the application has written the RESET command to the
Protocol Control Command field POCCMD in the Protocol Operation Control
Register (POCR). The circumstances that cause this to occur are
transparent to the application.

Workaround


Ensure the application executes the following sequence of commands after

sending the RESET command:
1) Repeatedly send the command FREEZE via POCR, until the freeze bit
PSR1[FRZ] is set.
2) Repeatedly send the command DEFAULT_CONFIG via POCR, until the freeze
bit PSR1[FRZ] is cleared and the field PSR0[PROTSTATE] indicates
DEFAULT_CONFIG.



No decoding error detection for communication elements after a boundary violationMUCts03129

Description

The FlexRay module will not indicate any subsequent reception decoding

errors if a boundary violation was detected for a communication element.
The following flags and fields may be affected:
a) Channel A/B Status Error Counter Registers (CASERCR,CBSERCR)
b) Symbol Window Syntax Error on Channel A/B flags SSEA and SSEB in the
Protocol Status Register 2 (PSR2)
c) Syntax Error on Channel A/B flags SEA and SEB in the Slot Status
Registers (SSR0-SSR7)
d) Syntax Error on Channel A/B flags SEA and SEB in the Slot Status of
the message buffer assigned to the respective slot.
e) Increment condition STATUSMASK[2] of the Slot Status Counter
Registers (SSCRn)

Workaround


There is no workaround. 




A received dynamic frame with the Null frame indicator set to 0 may be accepted as a valid frameMUCts03130

Description

If the FlexRay module has received a dynamic frame with the Null frame

indicator bit set to 0, and no other syntax or content errors appeared
in this frame, this frame is accepted as a valid frame and will be
stored in the subscribed message buffer of receive FIFO.
The following flags and fields may be affected:
a) Valid Frame on Channel A/B flags VFA and VFB in the Slot Status
Registers (SSR0-SSR7)
b) Valid Frame on Channel A/B flags VFA and VFB in the Slot Status Field
of the subscribed receive message buffer or receive FIFO buffer
c) Increment condition VFR of the Slot Status Counter Registers (SSCRn)
d) Aggregated Valid Frame on Channel A/B flags AVFA and AVFB in the
Protocol Status Register 3 (PSR3)
e) The frame data of the receive message buffer subscribed to this slot.
f) The frame data of the receive FIFO buffer assigned to the reception
channel.

Workaround


Ensure the application ignores all frames in receive message buffers and

receive FIFOs with the Null frame indicator NUF in the Frame Header
Field is set to 0.



Update of PSR0[ERRMODE] not aligned with update of PSR0[PROTSTATE]MUCts03234

Description

When the FlexRay module transitions from NORMAL_PASSIVE to

NORMAL_ACTIVE, which is indicated by the Protocol State field PROTSTATE
in the Protocol Status Register 0 (PSR0), the FlexRay module will not
update the Error Mode field ERRMODE in PSR0 from PASSIVE to ACTIVE.
When the FlexRay module transitions from NORMAL_ACTIVE to
NORMAL_PASSIVE, it updates PSR0[ERRMODE] from ACTIVE to PASSIVE at the
end of the static segment and updates PSR0[PROTSTATE] at the end of the
communication cycle.
When the FlexRay module transitions from NORMAL_ACTIVE to HALT, it
updates PSR0[ERRMODE] from ACTIVE to COMM_HALT at the end of the static
segment and updates PSR0[PROTSTATE] some microseconds later.

Workaround


Ensure the application uses only PSR0[PROTSTATE] to determine the

protocol state and never uses PSR0[ERRMODE].



A syntax error may be indicated in the wrong slot if a communication element violates the slot boundaryMUCts03235

Description

The FlexRay module will indicate a syntax error for a slot if:

a) The FlexRay module has received a valid frame and
b) later in the same slot, the FlexRay module has received an additional
communication element that crosses the slot boundary.
The following flags and fields may be affected:
a) Channel A/B Status Error Counter Registers (CASERCR,CBSERCR)
b) Symbol Window Syntax Error on Channel A/B flags SSEA and SSEB in the
Protocol Status Register 2 (PSR2)
c) Syntax Error on Channel A/B flags SEA and SEB in the Slot Status
Registers (SSR0-SSR7)
d) Syntax Error on Channel A/B flags SEA and SEB in the Slot Status of
the message buffer assigned to the respective slot
e) Increment condition STATUSMASK[2] of the Slot Status Counter
Registers (SSCRn)

Workaround


There is no workaround. 




Wakeup Pattern not detected after too long low phase or missing channel idleMUCts03236

Description

The FlexRay module will not recognize a valid low-high-low phase on the

FlexRay bus as a wakeup pattern (WUP) if:
a) the first low phase is longer than the wakeup symbol window as
defined in the Protocol Configuration Register 4
(PCR4[wakeup_symbol_rx_window]), or
b) the first low phase is not preceded by a valid channel idle phase.

Workaround


Ensure all nodes in the FlexRay cluster are configured to send at least

three repetitions of the wakeup symbol to form a wakeup pattern
(wakeup_pattern defined in Protocol Configuration Register 18
PCR18[wakeup_pattern]>=3).



Integration fails if a received startup frame begins close to the maximum drift boundaryMUCts03237

Description

The FlexRay module will stay in the INTEGRATION_COLDSTART_CHECK state if:

a) the FlexRay module is configured in Protocol Configuration Register
11 as a startup node (PCR11[key_slot_used_for_startup]=1) and
b) the FlexRay module tries to integrate into the cluster, and
c) the second startup frame from the cluster starts
PCR26[micro_per_cycle_max] - 1 microticks after the start of the first
startup frame.
The FlexRay module will stay in the INTEGRATION_CONSISTENCY_CHECK state if:
a) the FlexRay module is configured as a non-startup node
(PCR11.[key_slot_used_for_startup]=0) and
b) the FlexRay module tries to integrate into the cluster, and
c) the second startup frame from the cluster starts
PCR26[micro_per_cycle_max] - 1 microticks after the start of the first
startup frame.

Workaround


If the FlexRay module is configured as a startup node and stays in the

INTEGRATION_COLDSTART_CHECK state for more then
4*PCR26[micro_per_cycle_max] microticks, then the host shall abort the
startup via the FREEZE command and initiate startup again via the
command sequence DEFAULT_CONFIG, CONFIG, READY and RUN.
If the FlexRay module is configured as a non-startup node and stays in
the INTEGRATION_CONSISTENCY_CHECK state for more then
8*PCR26[micro_per_cycle_max] microticks, then the host shall abort the
startup via the FREEZE command and initiate startup again via the
command sequence DEFAULT_CONFIG, CONFIG, READY and RUN.



No frame transmission in the dynamic segment when pLatestTx set to 1MUCts03238

Description

The FlexRay module will not transmit any frame in the dynamic segment if

the protocol parameter pLatestTx is set to 1, which is equivalent to
Protocol Configuration Register field latest_tx being equal to field
minislots_max (PCR21[latest_tx] = PCR29[minislots_max]).

Workaround


Ensure the application configures pLatestTx to be greater than 1, which

is equivalent to PCR21[latest_tx] < PCR29[minislots_max].



A frame received on channel A may not be stored in the subscribed receive message bufferMUCts03239

Description

The FlexRay module will not store a valid frame received on channel A in

the receive message buffer subscribed to this slot if:
a) The receive message buffer has the buffer number n, and
b) the receive message buffer is subscribed to slot S and channel A, and
c) a transmit message buffer is assigned to slot S and channel B, and
d) the transmit message buffer has the buffer number m, with m < n, and
e) the slot S occurs for both channel A and B at the same point in time.

Workaround


Ensure that all receive message buffers assigned to a slot S have lower

message buffer numbers than all transmit message buffers assigned to the
same slot S.



Improper device startup during the external reset procedureMUCts03333

Description

In normal cases, after external reset deassertion, the MFR4300 samples

the IF_SEL inputs (TXD_BG[1:2]/IF_SEL[1:0] pins) and after ~70
EXTAL/CLK_CC periods the device starts to drive the TXD_BG function
(please refer to the MFR4300 Data Sheet, Figure 6-6). The reported
problem happens when the MFR4300 samples the external reset signal at
the time it is changing from "0" (asserted) to "1" (deasserted). The
frequency of that failure may vary. For example, if the external reset
is produced by a manual switch it can reach a ratio of one failure out
of 600 cases.
There are two outcomes possible after the external reset deassertion:
-The MFR4300 switches to the TXD_BG output function after a long delay
of ~16400 EXTAL/CLK_CC periods; however, samples the IF_SEL inputs
correctly.
-The MFR4300 switches to the TXD_BG output function after a very short
delay of ~8 EXTAL/CLK_CC periods and samples the IF_SEL inputs incorrectly.
This problem is caused by an asynchronous external reset signal (RESET#)
deassertion which happens at the capturing time of that signal by the
MFR4300. The MFR4300 device uses this signal without synchronizing it to
its internal clock.

Workaround


Please check the Application Note AN3287 "MFR4300 External Reset" for

details on the available workaround.



Frame header recognized too early and decoding error in cycle count not detectedMUCts03431

Description

If the FlexRay module receives a frame header with a decoding error in

the cycle count field of the frame header, it will recognize this as a
valid frame header. However, the complete frame will still be considered
as invalid. The FlexRay module will recognize a frame header reception
immediately after the reception of the header CRC and not after the
reception of the cycle count. This may result in: a) If the FlexRay
module is in WAKEUP_LISTEN state, the wakeup may be aborted and it may
indicate a RECEIVED_HEADER in the Wakeup Status field WAKEUPSTATUS in
the Protocol Status Register 0 (PSR0[WAKEUPSTATUS]) instead of
TRANSMITTED. b) If the FlexRay module is in WAKEUP_DETECT state, it may
indicate a COLLISION_HEADER (PSR0[WAKEUPSTATUS]) instead of
COLLISION_WUP. c) If the FlexRay module is in WAKEUP_DETECT state, it
may indicate a COLLISION_HEADER (PSR0[WAKEUPSTATUS]) instead of
COLLISION_UNKNOWN. d) If the FlexRay module is in COLDSTART_LISTEN
state, it may transmit a CAS symbol 800ns earlier than expected. e) If
the FlexRay module is in COLDSTART_COLLISION_RESOLUTION or COLDSTART_GAP
state, the startup attempt may be aborted.

Workaround


There is no workaround. 




READY command in NORMAL_PASSIVE state ignored, if state will change to HALT in next communication cycleMUCts03432

Description

The FlexRay module will ignore a READY command, if 1) it is in

NORMAL_PASSIVE state, which is indicated by the Protocol State field in
the Protocol Status Register 0 (PSR0[PROTSTATE]), and 2) the threshold
of gMaxWithoutClockCorrectionFatal as configured in the Protocol
Configuration Register field PCR8[max_without_clock_correction_fatal]
was reached and it would transition to HALT state in the next
communication cycle, and 3) pAllowHaltDueToClock as configured in the
Protocol Configuration Register field PCR26[allow_halt_due_to_clock] is
true, and 4) the READY command occurs after the end of the static
segment. The FlexRay module then will transition into the HALT state
instead of the expected READY state.

Workaround


If a READY command is sent when the FlexRay module is in NORMAL_PASSIVE

(PSR0[PROTSTATE]), the next protocol state must be checked.
If the next state is READY, the READY command was correctly executed.
If the next state is HALT, the READY command was ignored and the READY
state can be reached by sending DEFAULT_CONFIG, CONFIG and READY commands.



Successful startup even though too few valid startup frame pairs receivedMUCts03433

Description

The FlexRay module may incorrectly perform a successful startup and

transition to NORMAL_ACTIVE state, if a) it is in
COLDSTART_CONSISTENCY_CHECK, INTEGRATION_COLDSTART_CHECK or
INTEGRATION_CONSISTENCY_CHECK state, and b) it receives an insufficient
number of valid startup frame pairs. A startup frame pair is a set of 2
startup frames where the first is received during an even communication
cycle and the second is received during the subsequent odd communication
cycle on the same channel and in the same slot. If the FlexRay module
receives a startup frame pair where one of the frames is a valid startup
frame and within the other frame the startup frame indicator is set, but
the sync frame indicator is not set, the FlexRay module will treat this
as a valid frame pair.

Workaround


There is no workaround. 




Large sync frame deviations incorrectly measured and used by clock synchronizationMUCts03434

Description

If the FlexRay module receives sync frames where the absolute value of

the deviation is larger than 204.8us (corresponds to 8192 microticks),
this value is incorrectly measured and an incorrect value is inserted in
the sync frame deviation table. If -16384uT <= deviation <= -8193uT,
16384uT are added to the deviation. If 8192uT <= deviation <= 16384uT,
16384uT are subtracted from the deviation. The incorrect values will be
used for rate- and offset-correction calculation. This will lead to
incorrect results for the rate- and offset-correction and consequently
an incorrect action point offset for frames transmitted by the FlexRay
module. This may lead to loss of synchronization on the FlexRay bus.

Workaround


Within the FlexRay protocol configuration ensure that 

gdActionPointOffset * gdMacrotick is less than 204.8us.



Triggering pLatestTx violation not possible via message buffer setupMUCts03435

Description

The FlexRay module can not be triggered to transmit a frame overlapping

the end of the dynamic segment via an inconsistent message buffer setup.
The FlexRay Conformance Test 2.3.1.12 intends to check the correct
behavior and error reporting in case of this segment violation. The
setup in this testcase defines the pPayloadLenDynMax parameter
configured in the max_payload_length_dynamic field of the Protocol
Configuration Register 24 (PCR24) to 1 two-byte word and configures a
message buffer to transmit a frame with an actual payload longer than
pPayloadLenDynMax. In the testcase it is expected that this frame is
transmitted, the segment boundary is violated and a pLatestTx error
reported. The FlexRay module will not transmit this frame, no segment
boundary violation occurs and consequently no pLatestTx error is
reported. Instead the Dynamic Payload Length Error Flag in the CHI Error
Flag Register CHIERFR[DPL_EF] is set.

Workaround


If it is required to check the correct behavior in case of a dynamic

segment violation, do this via setting the value of pLatestTx equal to
gNumberOfMinislots (latest_tx parameter in Protocol Configuration
Register PCR21 equals to 0).
Important: This may only be done for testing purpose. Do not configure
the FlexRay module this way for the final application.



Transition from NORMAL_PASSIVE to NORMAL_ACTIVE when only one startup frame is receivedMUCts03436

Description

If the FlexRay module is configured as an integrating node

(key_slot_used_for_startup field in the Protocol Configuration Register
11 set to 1), it may transition from NORMAL_PASSIVE to NORMAL_ACTIVE
state (allow_passive_to_active field in the Protocol Configuration
Register 12 (PCR12) > 0) and it currently is in NORMAL_PASSIVE state,
the FlexRay module will transition from NORMAL_PASSIVE to NORMAL_ACTIVE
after PCR12[allow_passive_to_active] communication cycles even if only 1
startup frame is received per communication cycle.

Workaround


There is no workaround. 




A boundary violation frame followed by a valid startup frame during the startup phase may cause an abort of the startupMUCts03437

Description

The FlexRay module may abort the startup due to a wrong deviation

measurement if: (a) The FlexRay module is in STARTUP state and (b) the
FlexRay module receives startup frame that violates the boundary at the
beginning of the slot followed by a valid startup frame in the same
slot. The following flags and fields may be affected: (a) The PROTSTATE
field of the Protocol Status Register PSR0 may indicate
INTEGRATION_LISTEN instead of NORMAL_ACTIVE after the startup. (b) The
OFFSETCORR field in the Offset Correction Value Register (OFCORVR) may
show a wrong value for the related communication cycle. (c) The RATECORR
field in the Rate Correction Value Register (RTCORVR) may show a wrong
value for the related communication cycle pair. (d) The Clock Correction
Limit Reached Interrupt Flag CCL_IF of the Protocol Interrupt Flag
Register 0 (PIFR0) may be set by the FlexRay module, indicating an
EXCEED_BOUNDS condition due to the erroneous deviation measurement.

Workaround


There is no workaround. 




Byte write access to RFSIR register may corrupt its contentMUCts03438

Description

When the applications performs an 8-bit write access to the high byte of

the Receive FIFO Start Index Register (RFSIR), the FlexRay module writes
an undefined value into the low byte of this register.

Workaround


Ensure the application performs only 16-bit write accesses to the RFSIR

register.



FlexRay communication disabled in dual channel mode with only channel B activeMUCts03509

Description

When the device is operating in dual channel mode (MCR.SCM = 0), but

only channel B is enabled (MCR.CHB = 1 and MCR.CHA = 0), the device
neither receives nor transmits on channel B.

Workaround


Do not use the dual channel mode with only channel B enabled. 




MVR register contains non-specified value during HALT mode entered by FREEZEMUCts03522

Description

According to the MFR4300 data sheet, the MVR has a constant value.

However, when the device is in HALT mode as a result of a CHI FREEZE
command or protocol error (PSR1.FRZ = 1), reading the MVR register
returns a different value.

Caution: Do not use a change in MVR content (instead of checking the
state of PSR1.FRZ) to indicate that the device has entered HALT mode as
a result of a CHI FREEZE command or protocol error.

Workaround


There is no workaround. 




CLKOUT can remain at "1" after external reset with CLK_S[1:0] set to "11"MUCts03599

Description

During the external reset sequence, the CRG block latches the values on

CLK_S[1:0].
The data sheet specifies that, if the latched values of CLK_S[1:0] =
"11", CLKOUT is disabled and is equal to "0". However, CLKOUT can remain
at "1" while disabled, if the following conditions are all true:
- CLKOUT was not disabled (i.e. was running), or was already disabled
and set to "1" prior to the current external reset.
- An external reset is applied.
- During the external reset sequence, the CLK_S[1:0] inputs are set to
"11" to disable CLKOUT.
- When the CRG latched the CLK_S[1:0] values, CLKOUT was "1".


Workaround


There is no workaround. 




Status bit MBCCSRn[DUP] not cleared after reception of emtpy dynamic slotMUCts03630

Description

If the FlexRay module has received an empty dynamic slot, the DUP bit in

the Message Buffer Configuration, Control, Status Registers (MBCCSRn) of
the receive message buffer subscribed to this slot is not cleared.

Workaround


The application should use the value of the MBCCSRn[DUP] bit only if the

MBCCSRn[MBIF] flag is set. The MBCCSRn[MBIF] flag is not set in case of
empty dynamic slot reception.



PIER1 register bits documented as read-only have read/write accessMUCts03679

Description

The following bits of the PIER1 register have read/write access while

they are documented as bits with read-only access: 0,1,2,3,6 and 7.

Workaround


Use 0 values for the PIER1 bits 0,1,2,3,6 and 7 during write operations

to the PIER1 register.


Freescale Semiconductor, Inc., 2007. All rights reserved.