ATMEGA256RZAV-8AU Atmel, ATMEGA256RZAV-8AU Datasheet - Page 89
![MCU ATMEGA2561/AT86RF230 64-TQFP](/photos/12/13/121332/313-64-tqfp_sml.jpg)
ATMEGA256RZAV-8AU
Manufacturer Part Number
ATMEGA256RZAV-8AU
Description
MCU ATMEGA2561/AT86RF230 64-TQFP
Manufacturer
Atmel
Series
ATMEGAr
Datasheets
1.ATMEGA640V-8CU.pdf
(38 pages)
2.ATMEGA640V-8CU.pdf
(444 pages)
3.AT86RF230-ZU.pdf
(98 pages)
Specifications of ATMEGA256RZAV-8AU
Frequency
2.4GHz
Modulation Or Protocol
802.15.4 Zigbee
Applications
ISM, ZigBee™
Power - Output
3dBm
Sensitivity
-101dBm
Voltage - Supply
1.8 V ~ 3.6 V
Current - Receiving
15.5mA
Current - Transmitting
16.5mA
Data Interface
PCB, Surface Mount
Memory Size
256kB Flash, 4kB EEPROM, 8kB RAM
Antenna Connector
PCB, Surface Mount
Package / Case
64-TQFP
Wireless Frequency
2.4 GHz
Interface Type
JTAG, SPI
Output Power
3 dBm
For Use With
ATAVRISP2 - PROGRAMMER AVR IN SYSTEM
Lead Free Status / RoHS Status
Lead free / RoHS Compliant
Operating Temperature
-
Data Rate - Maximum
-
Lead Free Status / Rohs Status
Lead free / RoHS Compliant
For Use With/related Products
ATmega256
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