AVR32UC datasheet(21/118 Pages) ATMEL

21 / 118 page

32002C–AVR32–11/07

AVR32

The scall instruction behaves differently depending on which mode it is called from. The behav-

iour is detailed in the instruction set reference. In order to allow the scall routine to return to the

correct context, a return from supervisor call instruction, rets, is implemented. In the AVR32A

microarchitecture, scall and rets uses the system stack to store the return address and the sta-

tus register.

3.7.3

Debug requests

The AVR32 architecture defines a dedicated debug mode. When a debug request is received by

the core, Debug mode is entered. Entry into Debug mode can be masked by the DM bit in the

status register. Upon entry into Debug mode, hardware sets the SR[D] bit and jumps to the

Debug Exception handler. By default, debug mode executes in the exception context, but with

dedicated Return Address Register and Return Status Register. These dedicated registers

remove the need for storing this data to the system stack, thereby improving debuggability.

Debug mode is exited by executing the retd instruction. This returns to the previous context.

3.8

Special concerns

3.8.1

System stack

Event handling in AVR32UC, like in all AVR32A architectures, uses the system stack pointed to

by the system stack pointer, SP_SYS, for pushing and popping R8-R12, LR, status register and

return address. Since exception code may be timing-critical, SP_SYS should point to memory

addresses in the IRAM section, since the timing of accesses to this memory section is both fast

and deterministic.

The user must also make sure that the system stack is large enough so that any event is able to

push the required registers to stack. If the system stack is full, and an event occurs, the system

will enter an UNDEFINED state.

3.8.2

Clearing of pending interrupt requests

When an interrupt request is accepted by the CPU, the interrupt handler will eventually be

called. The interrupt handler is responsible for performing the required actions so that the

requesting module disasserts the interrupt request before the interrupt routine is exited with rete.

Failing to do so will cause the interrupt handler to be re-entered after the rete instruction has

been executed, since the interrupt request is still active. Different interrupt sources have differ-

ent ways of disasserting requests, for example reading an interrupt cause register or writing to

specific control registers. Refer to the module-specific documentation for information on how to

disassert interrupt requests.

Disasserting an interrupt request often requires that a bus access is performed to the requesting

module. An example of such an access is to read an interrupt cause register. There will be a

latency from the execution of the load or store instruction that is to disassert the interrupt request

and the actual disassertion of the request. This latency can be caused by the bus system and

internal latencies in the interrupting module. It is important that the programmer makes sure that

the interrupt request has actually been disasserted before returning from the interrupt with rete.

This can usually be ensured by scheduling the code sequence disasserting the interrupt request

in such a way that one can be certain that the interrupt request has actually been disasserted

before the rete instruction is executed.

AVR32UC Datasheet(PDF) 21 Page - ATMEL Corporation

AVR32UC Datasheet(HTML) 21 Page - ATMEL Corporation

Html Pages

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 ...More

Datasheet Download

Link URL