ATEVK1105 Atmel, ATEVK1105 Datasheet - Page 507

• Manufacturer Part Number: ATEVK1105
• Description: KIT EVAL FOR AT32UC3A0
• Manufacturer: Atmel
• Series: AVR®32r
• Type: MCUr

Specifications of ATEVK1105

• Contents: Evaluation Board, Software and Documentation
• Processor To Be Evaluated: AT32UC3A0512
• Processor Series: AVR
• Data Bus Width: 32 bit
• Interface Type: USART, TWI, USB, SPI, Ethernet
• Operating Supply Voltage: 3.3 V
• Silicon Manufacturer: Atmel
• Core Architecture: AVR
• Core Sub-architecture: AVR UC3
• Silicon Core Number: AT32UC3A0512
• Silicon Family Name: AVR
• Kit Contents: Board CD Docs
• Rohs Compliant: Yes
• For Use With/related Products: AT32UC3A0
• Lead Free Status / RoHS Status: Lead free / RoHS Compliant

Figure 30-8. Allocation and Reorganization of the DPRAM
32058J–AVR32–04/11
U(P/E)RST.(E)PENX = 1
U(P/E)CFGX.ALLOC = 1
Pipes/Endpoints 0..5
Free Memory
Activated
PEP5
PEP4
PEP3
PEP2
PEP1
PEP0
Disabling a pipe (PENX = 0) or an endpoint (EPENX = 0) resets neither its ALLOC bit nor its
configuration (PBK/EPBK, PSIZE/EPSIZE, PTOKEN/EPDIR, PTYPE/EPTYPE, PEPNUM, INT-
FRQ). To free its memory, the firmware should clear its ALLOC bit. The k
memory window then slides down and its data is lost. Note that the following pipe/endpoint
memory windows (from k
Figure 30-8
• First, the pipes/endpoints 0 to 5 are enabled, configured and allocated in ascending order.
• Then, the pipe/endpoint 3 is disabled, but its memory is kept allocated by the controller.
• In order to free its memory, its ALLOC bit is then cleared by the firmware. The pipe/endpoint 4
• Finally, if the firmware chooses to reconfigure the pipe/endpoint 3 with a larger size, the
Note that:
Each pipe/endpoint then owns a memory area in the DPRAM.
memory window slides down, but the pipe/endpoint 5 does not move.
controller allocates a memory area after the pipe/endpoint 2 memory area and automatically
slides up the pipe/endpoint 4 memory window. The pipe/endpoint 5 does not move and a
memory conflict appears as the memory windows of the pipes/endpoints 4 and 5 overlap. The
data of these pipes/endpoints is potentially lost.
•there is no way the data of the pipe/endpoint 0 can be lost (except if it is de-allocated) as
•deactivating then reactivating a same pipe/endpoint with the same configuration only modifies
•when the firmware sets the ALLOC bit, the CFGOK bit is set by hardware only if the
memory allocation and de-allocation may affect only higher pipes/endpoints;
temporarily the controller DPRAM pointer and size for this pipe/endpoint, but nothing
changes in the DPRAM, so higher endpoints seem to not have been moved and their data is
preserved as far as nothing has been written or received into them while changing the
allocation state of the first pipe/endpoint;
configured size and number of banks are correct compared to their maximal allowed values
for the endpoint and to the maximal FIFO size (i.e. the DPRAM size), so the value of CFGOK
does not consider memory allocation conflicts.
U(P/E)RST.(E)PEN3 = 0
illustrates the allocation and reorganization of the DPRAM in a typical example.
Pipe/Endpoint 3
(ALLOC stays at 1)
Free Memory
Disabled
PEP5
PEP4
PEP3
PEP2
PEP1
PEP0
i+2
) do not slide.
U(P/E)CFG3.ALLOC = 0
Pipe/Endpoint 3
PEP4 Lost Memory
Memory Freed
Free Memory
PEP5
PEP4
PEP2
PEP1
PEP0
U(P/E)RST.(E)PEN3 = 1
U(P/E)CFG3.ALLOC = 1
Pipe/Endpoint 3
PEP3 (larger size)
Free Memory
Activated
PEP4
PEP2
PEP1
PEP0
PEP5
AT32UC3A
i+1
Conflict
pipe/endpoint
507