2.8.3 RXMode(buffered)

In RXMode(buffered), the received data stream is stored in the 32 bytes deep data FIFO (DFIFO). The fill level can be read out by using the “Read Fill Level Rx FIFO” SPI command.

Note: The content of the DFIFO is overwritten if the incoming data stream exceeds 32 bytes in length and was not read out by using the “Read Rx FIFO” SPI command as described in Read RX FIFO.

In the buffered data reception mode, the current DFIFO fill level is compared to a configurable buffer threshold for path A or path B. These thresholds can be set up independently for path A and path B of each service using the eepServices.rxSetPathx.RXbufx[5:0] variables.


Address Service0	Name	Bit 7	Bit 6	Bit 5	Bit 4	Bit 3	Bit 2	Bit 1	Bit 0
0x00DF	rxSetPathA[0]	—	rxBufEvMaskA	RXbufA[5:0]
0x00E1	rxSetPathB[0]	—	rxBufEvMaskB	RXbufB[5:0]

Any time the fill level reaches the threshold of the current receive path, a DFIFO fill level match condition becomes true. In that case, the firmware indicates its occurrence by setting the event flag DFIFO_RX in events.system (R15).


Name	Bit 7	Bit 6	Bit 5	Bit 4	Bit 3	Bit 2	Bit 1	Bit 0
System (R15) events.system	SYS_ERR	CMD_RDY	SYS_RDY	AVCCLOW	LOWBATT	SFIFO	DFIFO_RX	DFIFO_TX

Note: Every time the RXMode(buffered) starts, a reset of the DFIFO and its related pointers takes place.

Depending on the telegram requirements, the receiver can be configured to swap the incoming bytes (MSB-first or LSB-first) before storing them to the DFIFO. The associated settings for path A and path B are located in the eepServices.RXBC1 variable. For more information, see Data Polarity.

The ID check feature is supported in RXMode(buffered). This feature is described in more detail in ID Check.

The RXMode(buffered) provides internal status information using the event flags of events.system (R15) and events.events (R14), as shown in the general part of the RXMode. In addition, the event flags DFIFO_RX and IDCHKA/B are supported, which might be used to generate an external event on pin 28 (EVENT), if the mask bits rxBufEvMaskA/B and IDCHKA/B_Mask in rxSetPathA/B[0] and rxSysEvent are enabled and the associated event occurs.


Name	Bit 7	Bit 6	Bit 5	Bit 4	Bit 3	Bit 2	Bit 1	Bit 0
System (R15) events.system	SYS_ERR	CMD_RDY	SYS_RDY	AVCCLOW	LOWBATT	SFIFO	DFIFO_RX	DFIFO_TX
Events (R14) events.events	IDCHKA	WCOKA	SOTA	EOTA	IDCHKB	WCOKB	SOTB	EOTB


Address Service0	Name	Bit 7	Bit 6	Bit 5	Bit 4	Bit 3	Bit 2	Bit 1	Bit 0
0x00DF	rxSetPathA[0]	—	rxBufEv MaskA	RXbufA[5:0]
0x00E1	rxSetPathB[0]	—	rxBufEv MaskB	RXbufB[5:0]
0x00E3	rxSysEvent	IDCHKA_Mask	WCOKA_Mask	SOTA_Mask	EOTA_Mask	IDCHKB_Mask	WCOKB_Mask	SOTB_Mask	EOTB_Mask

The demodulated data can additionally be output on pin 17/TMDO and pin 19/TMDO_CLOCK as reshaped transparent output. If eepServices.rxSysSet.PathValidAfterSOT_ENA is set to ‘0’, the data of the active path is output on the TMDO pin after a WCO and the corresponding clock is output on pin TMDO_CLOCK after an SOT.

If eepServices.rxSysSet.PathValidAfterSOT_ENA is set to ‘1’, both the data and clock of the active path are output on the pins together after an SOT.

The reshaped transparent output can be activated independently for each service by setting at least one of the eepServices.RDOCR.TMDS[1:0] bits to ‘1’.


Address Service0	Name	Bit 7	Bit 6	Bit 5	Bit 4	Bit 3	Bit 2	Bit 1	Bit 0
0x00DD	RDOCR	—	`0`	`0`	ETRPB	ETRPA	TMDS[1:0]		—