|
|
|
@@ -34,14 +34,14 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
|
|
|
|
medium level interrupts, by calling xt_set_interrupt_handler(). These
|
|
|
|
|
handlers can be written in C, and must obey C calling convention. The
|
|
|
|
|
handler table is indexed by the interrupt number. Each handler may be
|
|
|
|
|
provided with an argument.
|
|
|
|
|
provided with an argument.
|
|
|
|
|
|
|
|
|
|
Note that the system timer interrupt is handled specially, and is
|
|
|
|
|
dispatched to the RTOS-specific handler. This timer cannot be hooked
|
|
|
|
|
by application code.
|
|
|
|
|
|
|
|
|
|
Optional hooks are also provided to install a handler per level at
|
|
|
|
|
run-time, made available by compiling this source file with
|
|
|
|
|
Optional hooks are also provided to install a handler per level at
|
|
|
|
|
run-time, made available by compiling this source file with
|
|
|
|
|
'-DXT_INTEXC_HOOKS' (useful for automated testing).
|
|
|
|
|
|
|
|
|
|
!! This file is a template that usually needs to be modified to handle !!
|
|
|
|
@@ -81,17 +81,17 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
|
|
|
|
This allows more flexibility in locating code without the performance
|
|
|
|
|
overhead of the 'l32r' literal data load in cases where the destination
|
|
|
|
|
is in range of 'call0'. There is an additional benefit in that 'call0'
|
|
|
|
|
has a longer range than 'j' due to the target being word-aligned, so
|
|
|
|
|
has a longer range than 'j' due to the target being word-aligned, so
|
|
|
|
|
the 'l32r' sequence is less likely needed.
|
|
|
|
|
3. The use of 'call0' with -mlongcalls requires that register a0 not be
|
|
|
|
|
live at the time of the call, which is always the case for a function
|
|
|
|
|
3. The use of 'call0' with -mlongcalls requires that register a0 not be
|
|
|
|
|
live at the time of the call, which is always the case for a function
|
|
|
|
|
call but needs to be ensured if 'call0' is used as a jump in lieu of 'j'.
|
|
|
|
|
4. This use of 'call0' is independent of the C function call ABI.
|
|
|
|
|
|
|
|
|
|
*******************************************************************************/
|
|
|
|
|
|
|
|
|
|
#include "xtensa_rtos.h"
|
|
|
|
|
#include "esp_panic.h"
|
|
|
|
|
#include "esp_private/panic_reason.h"
|
|
|
|
|
#include "sdkconfig.h"
|
|
|
|
|
#include "soc/soc.h"
|
|
|
|
|
#include "soc/dport_reg.h"
|
|
|
|
@@ -365,7 +365,7 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
|
|
|
|
/*
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
|
Panic handler.
|
|
|
|
|
Should be reached by call0 (preferable) or jump only. If call0, a0 says where
|
|
|
|
|
Should be reached by call0 (preferable) or jump only. If call0, a0 says where
|
|
|
|
|
from. If on simulator, display panic message and abort, else loop indefinitely.
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
@@ -437,7 +437,7 @@ panic_print_hex_a:
|
|
|
|
|
panic_print_hex_ok:
|
|
|
|
|
s32i a5,a3,0
|
|
|
|
|
slli a2,a2,4
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
addi a4,a4,-1
|
|
|
|
|
bnei a4,0,panic_print_hex_loop
|
|
|
|
|
movi a5,' '
|
|
|
|
@@ -456,12 +456,12 @@ panic_print_hex_ok:
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
|
Hooks to dynamically install handlers for exceptions and interrupts.
|
|
|
|
|
Allows automated regression frameworks to install handlers per test.
|
|
|
|
|
Consists of an array of function pointers indexed by interrupt level,
|
|
|
|
|
Consists of an array of function pointers indexed by interrupt level,
|
|
|
|
|
with index 0 containing the entry for user exceptions.
|
|
|
|
|
Initialized with all 0s, meaning no handler is installed at each level.
|
|
|
|
|
See comment in xtensa_rtos.h for more details.
|
|
|
|
|
|
|
|
|
|
*WARNING* This array is for all CPUs, that is, installing a hook for
|
|
|
|
|
*WARNING* This array is for all CPUs, that is, installing a hook for
|
|
|
|
|
one CPU will install it for all others as well!
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
@@ -491,7 +491,7 @@ _xt_intexc_hooks:
|
|
|
|
|
the appropriate stack frame, saves a few vector-specific registers and
|
|
|
|
|
calls XT_RTOS_INT_ENTER to save the rest of the interrupted context
|
|
|
|
|
and enter the RTOS, then sets up a C environment. It then calls the
|
|
|
|
|
user's interrupt handler code (which may be coded in C) and finally
|
|
|
|
|
user's interrupt handler code (which may be coded in C) and finally
|
|
|
|
|
calls XT_RTOS_INT_EXIT to transfer control to the RTOS for scheduling.
|
|
|
|
|
|
|
|
|
|
While XT_RTOS_INT_EXIT does not return directly to the interruptee,
|
|
|
|
@@ -867,7 +867,7 @@ _xt_syscall_exc:
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
|
Co-Processor Exception Handler (jumped to from User Exception Handler).
|
|
|
|
|
These exceptions are generated by co-processor instructions, which are only
|
|
|
|
|
allowed in thread code (not in interrupts or kernel code). This restriction is
|
|
|
|
|
allowed in thread code (not in interrupts or kernel code). This restriction is
|
|
|
|
|
deliberately imposed to reduce the burden of state-save/restore in interrupts.
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
@@ -984,7 +984,7 @@ _xt_coproc_exc:
|
|
|
|
|
or a4, a4, a2 /* a4 = CPENABLE | (1 << n) */
|
|
|
|
|
wsr a4, CPENABLE
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
/*
|
|
|
|
|
Keep loading _xt_coproc_owner_sa[n] atomic (=load once, then use that value
|
|
|
|
|
everywhere): _xt_coproc_release assumes it works like this in order not to need
|
|
|
|
|
locking.
|
|
|
|
@@ -1030,8 +1030,8 @@ locking.
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
The config-specific HAL macro invoked below destroys a2-5, preserves a0-1.
|
|
|
|
|
It is theoretically possible for Xtensa processor designers to write TIE
|
|
|
|
|
that causes more address registers to be affected, but it is generally
|
|
|
|
|
It is theoretically possible for Xtensa processor designers to write TIE
|
|
|
|
|
that causes more address registers to be affected, but it is generally
|
|
|
|
|
unlikely. If that ever happens, more registers needs to be saved/restored
|
|
|
|
|
around this macro invocation, and the value in a15 needs to be recomputed.
|
|
|
|
|
*/
|
|
|
|
@@ -1056,8 +1056,8 @@ locking.
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
The config-specific HAL macro invoked below destroys a2-5, preserves a0-1.
|
|
|
|
|
It is theoretically possible for Xtensa processor designers to write TIE
|
|
|
|
|
that causes more address registers to be affected, but it is generally
|
|
|
|
|
It is theoretically possible for Xtensa processor designers to write TIE
|
|
|
|
|
that causes more address registers to be affected, but it is generally
|
|
|
|
|
unlikely. If that ever happens, more registers needs to be saved/restored
|
|
|
|
|
around this macro invocation.
|
|
|
|
|
*/
|
|
|
|
@@ -1138,12 +1138,12 @@ _xt_lowint1:
|
|
|
|
|
/* Save rest of interrupt context and enter RTOS. */
|
|
|
|
|
call0 XT_RTOS_INT_ENTER /* common RTOS interrupt entry */
|
|
|
|
|
|
|
|
|
|
/* !! We are now on the RTOS system stack !! */
|
|
|
|
|
/* !! We are now on the RTOS system stack !! */
|
|
|
|
|
|
|
|
|
|
/* Set up PS for C, enable interrupts above this level and clear EXCM. */
|
|
|
|
|
#ifdef __XTENSA_CALL0_ABI__
|
|
|
|
|
movi a0, PS_INTLEVEL(1) | PS_UM
|
|
|
|
|
#else
|
|
|
|
|
#else
|
|
|
|
|
movi a0, PS_INTLEVEL(1) | PS_UM | PS_WOE
|
|
|
|
|
#endif
|
|
|
|
|
wsr a0, PS
|
|
|
|
@@ -1175,7 +1175,7 @@ _xt_lowint1:
|
|
|
|
|
the appropriate stack frame, saves a few vector-specific registers and
|
|
|
|
|
calls XT_RTOS_INT_ENTER to save the rest of the interrupted context
|
|
|
|
|
and enter the RTOS, then sets up a C environment. It then calls the
|
|
|
|
|
user's interrupt handler code (which may be coded in C) and finally
|
|
|
|
|
user's interrupt handler code (which may be coded in C) and finally
|
|
|
|
|
calls XT_RTOS_INT_EXIT to transfer control to the RTOS for scheduling.
|
|
|
|
|
|
|
|
|
|
While XT_RTOS_INT_EXIT does not return directly to the interruptee,
|
|
|
|
@@ -1602,7 +1602,7 @@ and used for purposes requiring very short service times.
|
|
|
|
|
|
|
|
|
|
Here are templates for high priority (level 2+) interrupt vectors.
|
|
|
|
|
They assume only one interrupt per level to avoid the burden of identifying
|
|
|
|
|
which interrupts at this level are pending and enabled. This allows for
|
|
|
|
|
which interrupts at this level are pending and enabled. This allows for
|
|
|
|
|
minimum latency and avoids having to save/restore a2 in addition to a0.
|
|
|
|
|
If more than one interrupt per high priority level is configured, this burden
|
|
|
|
|
is on the handler which in any case must provide a way to save and restore
|
|
|
|
@@ -1727,12 +1727,12 @@ _NMIExceptionVector:
|
|
|
|
|
|
|
|
|
|
WINDOW OVERFLOW AND UNDERFLOW EXCEPTION VECTORS AND ALLOCA EXCEPTION HANDLER
|
|
|
|
|
|
|
|
|
|
Here is the code for each window overflow/underflow exception vector and
|
|
|
|
|
Here is the code for each window overflow/underflow exception vector and
|
|
|
|
|
(interspersed) efficient code for handling the alloca exception cause.
|
|
|
|
|
Window exceptions are handled entirely in the vector area and are very
|
|
|
|
|
tight for performance. The alloca exception is also handled entirely in
|
|
|
|
|
tight for performance. The alloca exception is also handled entirely in
|
|
|
|
|
the window vector area so comes at essentially no cost in code size.
|
|
|
|
|
Users should never need to modify them and Cadence Design Systems recommends
|
|
|
|
|
Users should never need to modify them and Cadence Design Systems recommends
|
|
|
|
|
they do not.
|
|
|
|
|
|
|
|
|
|
Window handlers go at predetermined vector locations according to the
|
|
|
|
|
morris
suda-morris