ATMEGA64RZAV-10MU Atmel, ATMEGA64RZAV-10MU Datasheet - Page 89

• Manufacturer Part Number: ATMEGA64RZAV-10MU
• Description: MCU ATMEGA644/AT86RF230 44-QFN
• Manufacturer: Atmel
• Series: ATMEGAr

Specifications of ATMEGA64RZAV-10MU

• Frequency: 2.4GHz
• Modulation Or Protocol: 802.15.4 Zigbee
• Power - Output: 3dBm
• Sensitivity: -101dBm
• Voltage - Supply: 1.8 V ~ 3.6 V
• Data Interface: PCB, Surface Mount
• Memory Size: 64kB Flash, 2kB EEPROM, 4kB RAM
• Antenna Connector: PCB, Surface Mount
• Package / Case: 44-VFQFN Exposed Pad
• Wireless Frequency: 2.4 GHz
• Interface Type: JTAG, SPI
• Output Power: 3 dBm
• For Use With: ATSTK600-TQFP32 - STK600 SOCKET/ADAPTER 32-TQFP770-1005 - ISP 4PORT FOR ATMEL AVR MCU JTAG770-1004 - ISP 4PORT FOR ATMEL AVR MCU SPIATAVRISP2 - PROGRAMMER AVR IN SYSTEMATJTAGICE2 - AVR ON-CHIP D-BUG SYSTEMATSTK500 - PROGRAMMER AVR STARTER KIT
• Lead Free Status / RoHS Status: Lead free / RoHS Compliant
• Operating Temperature: -
• Applications: -
• Data Rate - Maximum: -
• Current - Transmitting: -
• Current - Receiving: -
• Lead Free Status / Rohs Status: Lead free / RoHS Compliant
• For Use With/related Products: ATmega64

Appendix B - Errata
AT86RF230 Rev. B
AT86RF230 Rev. A
5131E-MCU Wireless-02/09
No known errata.
1. Data frames with destination address=0xFFFF is acknowledged in RX_AACK
2. Frame upload in RX_AACK
3. TX_ARET returns TRAC_STATUS=SUCCESS even though transaction failed
1.
2.
According to IEEE 802.15.4-2003 data frames with destination address=0xFFFF
(broadcast) should not have the acknowledgment request subfield set in the frame
control field. If such a non-standard compliant data frame arrives, a device in
RX_AACK state acknowledges that frame.
Fix/Workaround
Use only standard compliant frames, i.e. do not initiate frames with destination
address=0xFFFF (broadcast) and the acknowledgment request subfield set.
The following frames are not uploaded:
(1) Data frames and command frames with destination PAN ID=0xFFFF and
extended destination addressing mode
(2) Beacon frames, when the PAN ID of the receiving node is set to 0xFFFF.
Fix/Workaround
(1) Use Basic Operating Mode for orphan scanning
(2) Use Basic Operating Mode for network scanning
It might happen that under very special conditions (e.g. noisy network environment)
the status bit TRAC_STATUS (register 0x02) after transmission of a frame is
SUCCESS even though the transaction failed.
Example
A node transmits a frame with the acknowledgment request subfield set to logic high
and waits for an incoming ACK. If no frame is received at the end of the ACK wait
period (54 symbols), but a valid preamble is detected (e.g. jammer/interferer signal),
the TX_ARET procedure is finished immediately. A TRX_END interrupt is generated.
The TRAC_STATUS is not updated and thus shows the default value SUCCESS.
Fix/Workaround
The workaround comprises two changes:
Set
retransmissions in the TX_ARET procedure. The frame retransmission has to
be implemented in S/W. A retransmission does not require a frame download
again, only TX_START command is necessary.
Control of the TX_ARET procedure should follow these steps:
o
o
o
register
TRX_STATUS == TX_ARET_ON
set TRX_CMD = TX_START and download frame
poll for TRX_STATUS == BUSY_TX_ARET
bits
MAX_FRAME_RETRIES
to
0.
AT86RF230
This
prevents
any
89