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. 

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

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. 

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

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. 

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. 

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. 

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

has both the EDT and LCKT bits set to 1. 

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. 

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. 

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. 

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. 

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. 

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. 

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. 

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. 

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) 

There is no workaround. 

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) 

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. 

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) 

There is no workaround. 

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. 

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. 

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 

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. 

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. 

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

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

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. 

There is no workaround. 

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. 

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. 

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) 

There is no workaround. 

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. 

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. 

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. 

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

protocol state and never uses PSR0[ERRMODE]. 

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) 

There is no workaround. 

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. 

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

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. 

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. 

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

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

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

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. 

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. 

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. 

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

details on the available workaround. 

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. 

There is no workaround. 

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. 

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. 

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. 

There is no workaround. 

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. 

Within the FlexRay protocol configuration ensure that 

gdActionPointOffset * gdMacrotick is less than 204.8us. 

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. 

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. 

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. 

There is no workaround. 

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. 

There is no workaround. 

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. 

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

register. 

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. 

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

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. 

There is no workaround. 

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".

 

There is no workaround. 

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. 

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. 

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. 

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

to the PIER1 register.