diff options
Diffstat (limited to 'ports/xtensa')
27 files changed, 300 insertions, 435 deletions
diff --git a/ports/xtensa/xcc/example_build/demo_threadx.c b/ports/xtensa/xcc/example_build/demo_threadx.c index 5bec9cc8..72632323 100644 --- a/ports/xtensa/xcc/example_build/demo_threadx.c +++ b/ports/xtensa/xcc/example_build/demo_threadx.c @@ -1,5 +1,5 @@ /* This is a small demo of the high-performance ThreadX kernel. It includes examples of eight - threads of different priorities, using a message queue, semaphore, mutex, event flags group, + threads of different priorities, using a message queue, semaphore, mutex, event flags group, byte pool, and block pool. */ #include <stdio.h> @@ -84,42 +84,42 @@ CHAR *pointer = TX_NULL; tx_byte_allocate(&byte_pool_0, (VOID **) &pointer, DEMO_STACK_SIZE, TX_NO_WAIT); /* Create the main thread. */ - tx_thread_create(&thread_0, "thread 0", thread_0_entry, 0, - pointer, DEMO_STACK_SIZE, + tx_thread_create(&thread_0, "thread 0", thread_0_entry, 0, + pointer, DEMO_STACK_SIZE, 1, 1, TX_NO_TIME_SLICE, TX_AUTO_START); /* Allocate the stack for thread 1. */ tx_byte_allocate(&byte_pool_0, (VOID **) &pointer, DEMO_STACK_SIZE, TX_NO_WAIT); - /* Create threads 1 and 2. These threads pass information through a ThreadX + /* Create threads 1 and 2. These threads pass information through a ThreadX message queue. It is also interesting to note that these threads have a time slice. */ - tx_thread_create(&thread_1, "thread 1", thread_1_entry, 1, - pointer, DEMO_STACK_SIZE, + tx_thread_create(&thread_1, "thread 1", thread_1_entry, 1, + pointer, DEMO_STACK_SIZE, 16, 16, 4, TX_AUTO_START); /* Allocate the stack for thread 2. */ tx_byte_allocate(&byte_pool_0, (VOID **) &pointer, DEMO_STACK_SIZE, TX_NO_WAIT); - tx_thread_create(&thread_2, "thread 2", thread_2_entry, 2, - pointer, DEMO_STACK_SIZE, + tx_thread_create(&thread_2, "thread 2", thread_2_entry, 2, + pointer, DEMO_STACK_SIZE, 16, 16, 4, TX_AUTO_START); /* Allocate the stack for thread 3. */ tx_byte_allocate(&byte_pool_0, (VOID **) &pointer, DEMO_STACK_SIZE, TX_NO_WAIT); - /* Create threads 3 and 4. These threads compete for a ThreadX counting semaphore. + /* Create threads 3 and 4. These threads compete for a ThreadX counting semaphore. An interesting thing here is that both threads share the same instruction area. */ - tx_thread_create(&thread_3, "thread 3", thread_3_and_4_entry, 3, - pointer, DEMO_STACK_SIZE, + tx_thread_create(&thread_3, "thread 3", thread_3_and_4_entry, 3, + pointer, DEMO_STACK_SIZE, 8, 8, TX_NO_TIME_SLICE, TX_AUTO_START); /* Allocate the stack for thread 4. */ tx_byte_allocate(&byte_pool_0, (VOID **) &pointer, DEMO_STACK_SIZE, TX_NO_WAIT); - tx_thread_create(&thread_4, "thread 4", thread_3_and_4_entry, 4, - pointer, DEMO_STACK_SIZE, + tx_thread_create(&thread_4, "thread 4", thread_3_and_4_entry, 4, + pointer, DEMO_STACK_SIZE, 8, 8, TX_NO_TIME_SLICE, TX_AUTO_START); /* Allocate the stack for thread 5. */ @@ -127,23 +127,23 @@ CHAR *pointer = TX_NULL; /* Create thread 5. This thread simply pends on an event flag which will be set by thread_0. */ - tx_thread_create(&thread_5, "thread 5", thread_5_entry, 5, - pointer, DEMO_STACK_SIZE, + tx_thread_create(&thread_5, "thread 5", thread_5_entry, 5, + pointer, DEMO_STACK_SIZE, 4, 4, TX_NO_TIME_SLICE, TX_AUTO_START); /* Allocate the stack for thread 6. */ tx_byte_allocate(&byte_pool_0, (VOID **) &pointer, DEMO_STACK_SIZE, TX_NO_WAIT); /* Create threads 6 and 7. These threads compete for a ThreadX mutex. */ - tx_thread_create(&thread_6, "thread 6", thread_6_and_7_entry, 6, - pointer, DEMO_STACK_SIZE, + tx_thread_create(&thread_6, "thread 6", thread_6_and_7_entry, 6, + pointer, DEMO_STACK_SIZE, 8, 8, TX_NO_TIME_SLICE, TX_AUTO_START); /* Allocate the stack for thread 7. */ tx_byte_allocate(&byte_pool_0, (VOID **) &pointer, DEMO_STACK_SIZE, TX_NO_WAIT); - tx_thread_create(&thread_7, "thread 7", thread_6_and_7_entry, 7, - pointer, DEMO_STACK_SIZE, + tx_thread_create(&thread_7, "thread 7", thread_6_and_7_entry, 7, + pointer, DEMO_STACK_SIZE, 8, 8, TX_NO_TIME_SLICE, TX_AUTO_START); /* Allocate the message queue. */ @@ -250,11 +250,11 @@ UINT status; /* Retrieve a message from the queue. */ status = tx_queue_receive(&queue_0, &received_message, TX_WAIT_FOREVER); - /* Check completion status and make sure the message is what we + /* Check completion status and make sure the message is what we expected. */ if ((status != TX_SUCCESS) || (received_message != thread_2_messages_received)) break; - + /* Otherwise, all is okay. Increment the received message count. */ thread_2_messages_received++; } @@ -313,7 +313,7 @@ ULONG actual_flags; thread_5_counter++; /* Wait for event flag 0. */ - status = tx_event_flags_get(&event_flags_0, 0x1, TX_OR_CLEAR, + status = tx_event_flags_get(&event_flags_0, 0x1, TX_OR_CLEAR, &actual_flags, TX_WAIT_FOREVER); /* Check status. */ @@ -366,7 +366,7 @@ UINT status; if (status != TX_SUCCESS) break; - /* Release the mutex again. This will actually + /* Release the mutex again. This will actually release ownership since it was obtained twice. */ status = tx_mutex_put(&mutex_0); diff --git a/ports/xtensa/xcc/inc/tx_api_asm.h b/ports/xtensa/xcc/inc/tx_api_asm.h index 5d4c8003..8eed6752 100644 --- a/ports/xtensa/xcc/inc/tx_api_asm.h +++ b/ports/xtensa/xcc/inc/tx_api_asm.h @@ -1,11 +1,11 @@ /*************************************************************************** - * Copyright (c) 2024 Microsoft Corporation - * + * Copyright (c) 2024 Microsoft Corporation + * * This program and the accompanying materials are made available under the * terms of the MIT License which is available at * https://opensource.org/licenses/MIT. - * + * * SPDX-License-Identifier: MIT **************************************************************************/ @@ -22,12 +22,6 @@ /* which usually means port-specific since a compiler's struct */ /* packing rules depend on properties of the target architecture. */ /* */ -/* RELEASE HISTORY */ -/* */ -/* DATE NAME DESCRIPTION */ -/* */ -/* 12-31-2020 Cadence Design Systems Initial Version 6.1.3 */ -/* */ /**************************************************************************/ #ifndef TX_API_ASM_H diff --git a/ports/xtensa/xcc/inc/tx_port.h b/ports/xtensa/xcc/inc/tx_port.h index 03517ea0..a8897815 100644 --- a/ports/xtensa/xcc/inc/tx_port.h +++ b/ports/xtensa/xcc/inc/tx_port.h @@ -1,11 +1,11 @@ /*************************************************************************** - * Copyright (c) 2024 Microsoft Corporation - * + * Copyright (c) 2024 Microsoft Corporation + * * This program and the accompanying materials are made available under the * terms of the MIT License which is available at * https://opensource.org/licenses/MIT. - * + * * SPDX-License-Identifier: MIT **************************************************************************/ @@ -30,18 +30,6 @@ /* own special types that can be mapped to actual data types by this */ /* file to guarantee consistency in the interface and functionality. */ /* */ -/* RELEASE HISTORY */ -/* */ -/* DATE NAME DESCRIPTION */ -/* */ -/* 11-09-2020 Cadence Design Systems Initial Version 6.1.2 */ -/* 04-02-2021 Bhupendra Naphade Modified comment(s), updated */ -/* macro definition, */ -/* resulting in version 6.1.6 */ -/* 10-31-2022 Scott Larson Modified comment(s), removed */ -/* EPK extension, */ -/* resulting in version 6.2.0 */ -/* */ /**************************************************************************/ #ifndef TX_PORT_H @@ -470,7 +458,7 @@ extern int xt_timer_intnum; #ifdef TX_THREAD_INIT CHAR _tx_version_id[] = - "Copyright (c) 2024 Microsoft Corporation. * Azure RTOS Xtensa Version 6.4.2 *"; + "(c) 2024 Microsoft Corp. (c) 2026-present Eclipse ThreadX contributors. * Azure RTOS Xtensa Version 6.5.0.202601 *"; #else extern CHAR _tx_version_id[]; #endif diff --git a/ports/xtensa/xcc/inc/tx_user.h b/ports/xtensa/xcc/inc/tx_user.h index 38f2ac05..6a1dc181 100644 --- a/ports/xtensa/xcc/inc/tx_user.h +++ b/ports/xtensa/xcc/inc/tx_user.h @@ -1,17 +1,18 @@ /*************************************************************************** - * Copyright (c) 2024 Microsoft Corporation - * + * Copyright (c) 2024 Microsoft Corporation + * Copyright (c) 2026-present Eclipse ThreadX contributors + * * This program and the accompanying materials are made available under the * terms of the MIT License which is available at * https://opensource.org/licenses/MIT. - * + * * SPDX-License-Identifier: MIT **************************************************************************/ /**************************************************************************/ /**************************************************************************/ -/** */ +/** */ /** ThreadX Component */ /** */ /** User Specific */ @@ -20,11 +21,11 @@ /**************************************************************************/ -/**************************************************************************/ -/* */ -/* PORT SPECIFIC C INFORMATION RELEASE */ -/* */ -/* tx_user.h PORTABLE C */ +/**************************************************************************/ +/* */ +/* PORT SPECIFIC C INFORMATION RELEASE */ +/* */ +/* tx_user.h PORTABLE C */ /* 6.0.1 */ /* */ /* AUTHOR */ @@ -32,18 +33,12 @@ /* William E. Lamie, Microsoft Corporation */ /* */ /* DESCRIPTION */ -/* */ -/* This file contains user defines for configuring ThreadX in specific */ -/* ways. This file will have an effect only if the application and */ -/* ThreadX library are built with TX_INCLUDE_USER_DEFINE_FILE defined. */ -/* Note that all the defines in this file may also be made on the */ -/* command line when building ThreadX library and application objects. */ -/* */ -/* RELEASE HISTORY */ -/* */ -/* DATE NAME DESCRIPTION */ /* */ -/* 06-30-2020 William E. Lamie Initial Version 6.0.1 */ +/* This file contains user defines for configuring ThreadX in specific */ +/* ways. This file will have an effect only if the application and */ +/* ThreadX library are built with TX_INCLUDE_USER_DEFINE_FILE defined. */ +/* Note that all the defines in this file may also be made on the */ +/* command line when building ThreadX library and application objects. */ /* */ /**************************************************************************/ @@ -52,12 +47,12 @@ /* Define various build options for the ThreadX port. The application should either make changes - here by commenting or un-commenting the conditional compilation defined OR supply the defines - though the compiler's equivalent of the -D option. - + here by commenting or un-commenting the conditional compilation defined OR supply the defines + though the compiler's equivalent of the -D option. + For maximum speed, the following should be defined: - TX_MAX_PRIORITIES 32 + TX_MAX_PRIORITIES 32 TX_DISABLE_PREEMPTION_THRESHOLD TX_DISABLE_REDUNDANT_CLEARING TX_DISABLE_NOTIFY_CALLBACKS @@ -66,21 +61,21 @@ TX_REACTIVATE_INLINE TX_DISABLE_STACK_FILLING TX_INLINE_THREAD_RESUME_SUSPEND - + For minimum size, the following should be defined: - - TX_MAX_PRIORITIES 32 + + TX_MAX_PRIORITIES 32 TX_DISABLE_PREEMPTION_THRESHOLD TX_DISABLE_REDUNDANT_CLEARING TX_DISABLE_NOTIFY_CALLBACKS TX_NOT_INTERRUPTABLE TX_TIMER_PROCESS_IN_ISR - + Of course, many of these defines reduce functionality and/or change the behavior of the system in ways that may not be worth the trade-off. For example, the TX_TIMER_PROCESS_IN_ISR results in faster and smaller code, however, it increases the amount of processing in the ISR. In addition, some services that are available in timers are not available from ISRs and will - therefore return an error if this option is used. This may or may not be desirable for a + therefore return an error if this option is used. This may or may not be desirable for a given application. */ @@ -88,16 +83,16 @@ to tx_port.h for descriptions on each of these options. */ /* -#define TX_MAX_PRIORITIES 32 -#define TX_MINIMUM_STACK ???? +#define TX_MAX_PRIORITIES 32 +#define TX_MINIMUM_STACK ???? #define TX_THREAD_USER_EXTENSION ???? #define TX_TIMER_THREAD_STACK_SIZE ???? #define TX_TIMER_THREAD_PRIORITY ???? */ -/* Determine if timer expirations (application timers, timeouts, and tx_thread_sleep calls - should be processed within the a system timer thread or directly in the timer ISR. - By default, the timer thread is used. When the following is defined, the timer expiration +/* Determine if timer expirations (application timers, timeouts, and tx_thread_sleep calls + should be processed within the a system timer thread or directly in the timer ISR. + By default, the timer thread is used. When the following is defined, the timer expiration processing is done directly from the timer ISR, thereby eliminating the timer thread control block, stack, and context switching to activate it. */ @@ -108,10 +103,10 @@ /* Determine if in-line timer reactivation should be used within the timer expiration processing. By default, this is disabled and a function call is used. When the following is defined, reactivating is performed in-line resulting in faster timer processing but slightly larger - code size. */ + code size. */ /* -#define TX_REACTIVATE_INLINE +#define TX_REACTIVATE_INLINE */ /* Determine is stack filling is enabled. By default, ThreadX stack filling is enabled, @@ -119,10 +114,10 @@ debuggers with ThreadX-awareness and by the ThreadX run-time stack checking feature. */ /* -#define TX_DISABLE_STACK_FILLING +#define TX_DISABLE_STACK_FILLING */ -/* Determine whether or not stack checking is enabled. By default, ThreadX stack checking is +/* Determine whether or not stack checking is enabled. By default, ThreadX stack checking is disabled. When the following is defined, ThreadX thread stack checking is enabled. If stack checking is enabled (TX_ENABLE_STACK_CHECKING is defined), the TX_DISABLE_STACK_FILLING define is negated, thereby forcing the stack fill which is necessary for the stack checking @@ -132,7 +127,7 @@ #define TX_ENABLE_STACK_CHECKING */ -/* Determine if preemption-threshold should be disabled. By default, preemption-threshold is +/* Determine if preemption-threshold should be disabled. By default, preemption-threshold is enabled. If the application does not use preemption-threshold, it may be disabled to reduce code size and improve performance. */ @@ -140,7 +135,7 @@ #define TX_DISABLE_PREEMPTION_THRESHOLD */ -/* Determine if global ThreadX variables should be cleared. If the compiler startup code clears +/* Determine if global ThreadX variables should be cleared. If the compiler startup code clears the .bss section prior to ThreadX running, the define can be used to eliminate unnecessary clearing of ThreadX global variables. */ @@ -148,13 +143,13 @@ #define TX_DISABLE_REDUNDANT_CLEARING */ -/* Determine if no timer processing is required. This option will help eliminate the timer - processing when not needed. The user will also have to comment out the call to - tx_timer_interrupt, which is typically made from assembly language in +/* Determine if no timer processing is required. This option will help eliminate the timer + processing when not needed. The user will also have to comment out the call to + tx_timer_interrupt, which is typically made from assembly language in tx_initialize_low_level. Note: if TX_NO_TIMER is used, the define TX_TIMER_PROCESS_IN_ISR must also be used. */ -/* +/* #define TX_NO_TIMER #ifndef TX_TIMER_PROCESS_IN_ISR #define TX_TIMER_PROCESS_IN_ISR @@ -170,8 +165,8 @@ */ -/* Determine if the tx_thread_resume and tx_thread_suspend services should have their internal - code in-line. This results in a larger image, but improves the performance of the thread +/* Determine if the tx_thread_resume and tx_thread_suspend services should have their internal + code in-line. This results in a larger image, but improves the performance of the thread resume and suspend services. */ /* @@ -179,7 +174,7 @@ */ -/* Determine if the internal ThreadX code is non-interruptable. This results in smaller code +/* Determine if the internal ThreadX code is non-interruptable. This results in smaller code size and less processing overhead, but increases the interrupt lockout time. */ /* @@ -187,8 +182,8 @@ */ -/* Determine if the trace event logging code should be enabled. This causes slight increases in - code size and overhead, but provides the ability to generate system trace information which +/* Determine if the trace event logging code should be enabled. This causes slight increases in + code size and overhead, but provides the ability to generate system trace information which is available for viewing in TraceX. */ /* diff --git a/ports/xtensa/xcc/inc/xtensa_api.h b/ports/xtensa/xcc/inc/xtensa_api.h index 10255838..28f3e528 100644 --- a/ports/xtensa/xcc/inc/xtensa_api.h +++ b/ports/xtensa/xcc/inc/xtensa_api.h @@ -63,7 +63,7 @@ extern xt_exc_handler xt_set_exception_handler(uint32_t n, xt_exc_handler f); /* ------------------------------------------------------------------------------- Call this function to set a handler for the specified interrupt. - + n - Interrupt number. f - Handler function address, NULL to uninstall handler. arg - Argument to be passed to handler. diff --git a/ports/xtensa/xcc/inc/xtensa_context.h b/ports/xtensa/xcc/inc/xtensa_context.h index 2ec96ecf..11174fff 100644 --- a/ports/xtensa/xcc/inc/xtensa_context.h +++ b/ports/xtensa/xcc/inc/xtensa_context.h @@ -82,16 +82,16 @@ INTERRUPT/EXCEPTION STACK FRAME FOR A THREAD OR NESTED INTERRUPT A stack frame of this structure is allocated for any interrupt or exception. - It goes on the current stack. If the RTOS has a system stack for handling - interrupts, every thread stack must allow space for just one interrupt stack + It goes on the current stack. If the RTOS has a system stack for handling + interrupts, every thread stack must allow space for just one interrupt stack frame, then nested interrupt stack frames go on the system stack. - The frame includes basic registers (explicit) and "extra" registers introduced + The frame includes basic registers (explicit) and "extra" registers introduced by user TIE or the use of the MAC16 option in the user's Xtensa config. The frame size is minimized by omitting regs not applicable to user's config. For Windowed ABI, this stack frame includes the interruptee's base save area, - another base save area to manage gcc nested functions, and a little temporary + another base save area to manage gcc nested functions, and a little temporary space to help manage the spilling of the register windows. ------------------------------------------------------------------------------- */ @@ -206,7 +206,7 @@ XSTRUCT_END(XtExcFrame) #else /* No extra storage required */ -#define XT_STK_NEXT2 XT_STK_NEXT1 +#define XT_STK_NEXT2 XT_STK_NEXT1 #endif @@ -252,7 +252,7 @@ XSTRUCT_END(XtExcFrame) and the context switch of that co-processor is then peformed by the handler. Ownership represents which thread's state is currently in the co-processor. - Co-processors may not be used by interrupt or exception handlers. If an + Co-processors may not be used by interrupt or exception handlers. If an co-processor instruction is executed by an interrupt or exception handler, the co-processor exception handler will trigger a kernel panic and freeze. This restriction is introduced to reduce the overhead of saving and restoring @@ -263,7 +263,7 @@ XSTRUCT_END(XtExcFrame) such as in the thread control block or above the thread stack area. It need not be in the interrupt stack frame since interrupts don't use co-processors. - Along with the save area for each co-processor, two bitmasks with flags per + Along with the save area for each co-processor, two bitmasks with flags per co-processor (laid out as in the CPENABLE reg) help manage context-switching co-processors as efficiently as possible: @@ -279,10 +279,10 @@ XSTRUCT_END(XtExcFrame) XT_CPSTORED A bitmask with the same layout as CPENABLE, a bit per co-processor. - Indicates whether the state of each co-processor is saved in the state + Indicates whether the state of each co-processor is saved in the state save area. When a thread enters the kernel, only the state of co-procs - still enabled in CPENABLE is saved. When the co-processor exception - handler assigns ownership of a co-processor to a thread, it restores + still enabled in CPENABLE is saved. When the co-processor exception + handler assigns ownership of a co-processor to a thread, it restores the saved state only if this bit is set, and clears this bit. XT_CP_CS_ST @@ -338,7 +338,7 @@ XSTRUCT_END(XtExcFrame) For framed functions the frame is created and the return address saved at base of frame (Call0 ABI) or as determined by hardware (Windowed ABI). For frameless functions, there is no frame and return address remains in a0. - Note: Because CPP macros expand to a single line, macros requiring multi-line + Note: Because CPP macros expand to a single line, macros requiring multi-line expansions are implemented as assembler macros. ------------------------------------------------------------------------------- */ @@ -351,7 +351,7 @@ XSTRUCT_END(XtExcFrame) addi sp, sp, -\size s32i a0, sp, 0 .endm - #define ENTRY0 + #define ENTRY0 #define RET(sz) ret1 sz .macro ret1 size=0x10 l32i a0, sp, 0 diff --git a/ports/xtensa/xcc/inc/xtensa_rtos.h b/ports/xtensa/xcc/inc/xtensa_rtos.h index 14e6cb22..d8db73bc 100644 --- a/ports/xtensa/xcc/inc/xtensa_rtos.h +++ b/ports/xtensa/xcc/inc/xtensa_rtos.h @@ -33,8 +33,8 @@ Macros in this header map callouts from generic Xtensa files to specific RTOS functions. It may also be included in C source files. - Xtensa RTOS ports support all RTOS-compatible configurations of the Xtensa - architecture, using the Xtensa hardware abstraction layer (HAL) to deal + Xtensa RTOS ports support all RTOS-compatible configurations of the Xtensa + architecture, using the Xtensa hardware abstraction layer (HAL) to deal with configuration specifics. Should be included by all Xtensa generic and RTOS port-specific sources. @@ -88,7 +88,7 @@ Some of these functions may call back to generic functions in xtensa_context.h . ***************************************************************************/ /* -Inform RTOS of entry into an interrupt handler that will affect it. +Inform RTOS of entry into an interrupt handler that will affect it. Allows RTOS to manage switch to any system stack and count nesting level. Called after minimal context has been saved, with interrupts disabled. RTOS port can call0 _xt_context_save to save the rest of the context. @@ -132,12 +132,12 @@ May be coded in or called from C or assembly, per ABI conventions. #endif /* -Return in a15 the base address of the co-processor state save area for the +Return in a15 the base address of the co-processor state save area for the thread that triggered a co-processor exception, or 0 if no thread was running. -The state save area is structured as defined in xtensa_context.h and has size +The state save area is structured as defined in xtensa_context.h and has size XT_CP_SIZE. Co-processor instructions should only be used in thread code, never in interrupt handlers or the RTOS kernel. May only be called from assembly code -and by the 'call0' instruction. A result of 0 indicates an unrecoverable error. +and by the 'call0' instruction. A result of 0 indicates an unrecoverable error. The implementation may use only a2-4, a15 (all other regs must be preserved). */ // void* XT_RTOS_CP_STATE(void) @@ -153,7 +153,7 @@ and interrupt handlers to facilitate automated testing where each test case can install its own handler for user exceptions and each interrupt priority (level). This consists of an array of function pointers indexed by interrupt priority, with index 0 being the user exception handler hook. -Each entry in the array is initially 0, and may be replaced by a function +Each entry in the array is initially 0, and may be replaced by a function pointer of type XT_INTEXC_HOOK. A handler may be uninstalled by installing 0. The handler for low and medium priority obeys ABI conventions so may be coded diff --git a/ports/xtensa/xcc/inc/xtensa_timer.h b/ports/xtensa/xcc/inc/xtensa_timer.h index d5a29ed5..957a42ed 100644 --- a/ports/xtensa/xcc/inc/xtensa_timer.h +++ b/ports/xtensa/xcc/inc/xtensa_timer.h @@ -64,12 +64,12 @@ select timer 0. #else /* XEA2 */ /* -Select timer to use for periodic tick, and determine its interrupt number +Select timer to use for periodic tick, and determine its interrupt number and priority. User may specify a timer by defining XT_TIMER_INDEX with -D, -in which case its validity is checked (it must exist in this core and must +in which case its validity is checked (it must exist in this core and must not be on a high priority interrupt - an error will be reported in invalid). Otherwise select the first low or medium priority interrupt timer available. -*/ +*/ #ifndef XT_TIMER_INDEX #if XCHAL_TIMER3_INTERRUPT != XTHAL_TIMER_UNCONFIGURED #if XCHAL_INT_LEVEL(XCHAL_TIMER3_INTERRUPT) <= XCHAL_EXCM_LEVEL diff --git a/ports/xtensa/xcc/readme_threadx.txt b/ports/xtensa/xcc/readme_threadx.txt index 29413318..3ad4aec2 100644 --- a/ports/xtensa/xcc/readme_threadx.txt +++ b/ports/xtensa/xcc/readme_threadx.txt @@ -6,7 +6,7 @@ The Xtensa configurable architecture supports a vast space of processor features. This port of ThreadX to the Xtensa architecture is based on -a Cadence Design Systems RTOS porting layer that takes care of Xtensa specifics +a Cadence Design Systems RTOS porting layer that takes care of Xtensa specifics that are common to most embedded real-time operating systems. It supports all Xtensa features (including context-switching custom processor extensions defined in the TIE language) with certain minimum requirements. You @@ -17,7 +17,7 @@ configuration. ThreadX also provides optional thread-safe support for the Xtensa C library and the newlib C library distributed with Xtensa Tools (for use in threads only, not in interrupt handlers). -ThreadX for Xtensa configurable processors requires the following minimum +ThreadX for Xtensa configurable processors requires the following minimum processor configuration options: - Timer interrupt option with at least one interruptible timer for ThreadX. - Interrupt option (implied by the timer interrupt option). @@ -60,10 +60,10 @@ If you wish to build for an evaluation board that is supported by an external package, be sure the appropriate package is installed. See the introduction (section 0) to determine if you need an external package. If you are using an external board package, set the environment variable -XTENSA_BOARDS to the absolute path of the root of the installed support +XTENSA_BOARDS to the absolute path of the root of the installed support package (or you can pass this to xt-make commands on the command line). eg. XTENSA_BOARDS = C:\usr\xtensa\RB-2007.1-xtav60 for Avnet LX60 board. -You do not need to set XTENSA_BOARDS if using a Cadence Design Systems supported +You do not need to set XTENSA_BOARDS if using a Cadence Design Systems supported board with Xtensa Tools RB-2007.2 and up (support is bundled with the tools). Next, change directories to the ThreadX installation directory, as follows: @@ -91,7 +91,7 @@ default when BOARD is defined). eg. BOARD=xtav60 for the Avnet LX60 (XT-AV60) board. > xt-make PLATFORM=raw - + which builds for a raw Xtensa core with no "board support". > xt-make PLATFORM=gdbio @@ -100,11 +100,11 @@ Provides some very slow I/O support through the xt-gdb debugger. For GDBIO to work, xt-gdb must remain connected to the target. If you are building for an Xtensa processor configuration that is not the -default you selected when you installed Xtensa Tools, you need to define the -environment variable XTENSA_CORE. If your configuration is not in the +default you selected when you installed Xtensa Tools, you need to define the +environment variable XTENSA_CORE. If your configuration is not in the default registry you selected when you installed Xtensa Tools, you also need to define the environment variable XTENSA_SYSTEM. See tools manuals. -You can avoid defining these in your environment if you pass the variables +You can avoid defining these in your environment if you pass the variables you need to redefine into xt-make as follows: > xt-make XTENSA_CORE=<your_config_name> XTENSA_SYSTEM=<your_registry> ... @@ -120,7 +120,7 @@ defined), for example "sim", "xtkc705". To build ThreadX with thread-safe C library support, define TX_THREAD_SAFE_CLIB in your build, as described in section 5 and in the Makefile. Please note that the C library is only safe for use in threads, not in interrupt handlers. -It may also safely be used in tx_application_define (after tx_kernel_enter, +It may also safely be used in tx_application_define (after tx_kernel_enter, before threads are running). @@ -130,10 +130,10 @@ The ThreadX demonstration is designed to execute under Xtensa instruction set simulator (ISS) or on a supported evaluation board programmed with your Xtensa processor configuration. -Building the demonstration is easy, simply execute the build_threadx_demo.bat +Building the demonstration is easy, simply execute the build_threadx_demo.bat batch file while inside threadx directory, as follows: -> build_threadx_demo.bat +> build_threadx_demo.bat or @@ -143,8 +143,8 @@ Be sure to set or pass into xt-make the variables described in section 2 above for building the ThreadX library, including the PLATFORM or BOARD you want to run on. -This compiles demo_threadx.c (which is the demonstration application) and links -it with the ThreadX objects in tx.a. The resulting file demo_threadx.out is a +This compiles demo_threadx.c (which is the demonstration application) and links +it with the ThreadX objects in tx.a. The resulting file demo_threadx.out is a ELF binary file that can be downloaded and executed on the target. The demo binary appears in the platform specific sub-directory described earlier. @@ -184,7 +184,7 @@ on your xt-make command line - this is the same as "raw" except it links some stubs that communicate through the debugger. It is very slow! WARNING: It is tempting to add printf calls to other threads in the demo. -If you modify the code in any way, you may need adjust affected threads' +If you modify the code in any way, you may need adjust affected threads' stack sizes. This is especially true if you add a printf call. See 4.5. @@ -207,9 +207,9 @@ xtensa_vectors_xea3.S (for XEA3). 4.2 Memory Allocation -In addition, _tx_initialize_low_level also determines the first available -address for use by the application. By default, the first available address -is assumed to be above all linker-allocated sections at symbol _end. This +In addition, _tx_initialize_low_level also determines the first available +address for use by the application. By default, the first available address +is assumed to be above all linker-allocated sections at symbol _end. This is passed to the application definition function, tx_application_define. This is a convenience to the application developer. Ultimately the developer has full control over memory allocation and can choose to use this or not. @@ -223,7 +223,7 @@ top of the system stack is defined by the symbol _xt_interrupt_stack_top. See the file xtensa_intr_asm.S for the default system stack definition. This stack may be resized and/or relocated according to the application needs. The application developer must ensure that the system stack is -sized appropriately for the application. All interrupts handled by +sized appropriately for the application. All interrupts handled by ThreadX will use the system stack. Handlers written in assembly must not switch to the system stack, since it will not be possible to detect whether the stack is currently in use. @@ -232,9 +232,9 @@ The macro TX_SYSTEM_STACK_SIZE defines the size of the system stack. As a convenience, a macro TX_MINIMUM_STACK_SYSTEM is provided with the minimum size required for the system stack. This is based on the maximum possible interrupt nesting level per the Xtensa processor configuration, -assuming very simple C handlers that do not call deeper than one or two +assuming very simple C handlers that do not call deeper than one or two levels. If the application uses more complex handlers, it will be -necessary to add to this value (accounting for nesting) to determine +necessary to add to this value (accounting for nesting) to determine the space required for the system stack. 4.4 Location and Extent of C Library Heap @@ -244,7 +244,7 @@ for the heap is allocated like this: by default, half the space between the first available memory address and the end of system memory is made available to the heap. -The heap location and limit are available in two global variables, and +The heap location and limit are available in two global variables, and can be fully customized in tx_application_define by assigning to them: _tx_clib_heap_start Base address of heap. @@ -254,9 +254,9 @@ This must be done BEFORE any C library calls. It is advised that it be done at the beginning of tx_application_define. Please note that when the thread-safe C library support is used, the heap -is not initialized before tx_kernel_enter has been called, so malloc will +is not initialized before tx_kernel_enter has been called, so malloc will fail. It is recommended to avoid C library calls that use the heap (such -as printf) outside of ThreadX (eg. in main). The C library is NOT safe +as printf) outside of ThreadX (eg. in main). The C library is NOT safe for use in interrupt or exception handlers, so this should be avoided. 4.5 Thread Stack Sizes @@ -265,13 +265,13 @@ The application must ensure that every thread has enough space for its stack. This must account for the deepest call depth and allow for one interrupt stack frame as defined in xtensa_context.h . Several factors influence the size of the stack required, including compiler optimization -level (-O0 is worst), use of TX_ENABLE_STACK_CHECKING option, and of -course your Xtensa configuration. Some stack size guidelines and macros +level (-O0 is worst), use of TX_ENABLE_STACK_CHECKING option, and of +course your Xtensa configuration. Some stack size guidelines and macros are provided in tx_port.h assuming no optimization (default, -O0). Threads that call C library functions may need larger stacks than those that don't. In particular, use of printf requires a very large stack and -will usually cause a stack overflow if inserted in a thread without +will usually cause a stack overflow if inserted in a thread without enlarging its stack size. See DEMO_STACK_SIZE_PRINTF in demo_threadx.c for a guideline. Use printf with care! @@ -288,8 +288,8 @@ Compiler Switch Meaning -g Specifies debug information. -c Specifies object code generation. -On Sets compiler optimization level n (default -O0). - -mlongcalls Allows assembler and linker to convert call - instructions to longer indirect call sequences + -mlongcalls Allows assembler and linker to convert call + instructions to longer indirect call sequences when target is out of range. -x assembler-with-cpp Passes .s and .S files through C preprocessor. -Dmacro Define a preprocessor macro with no value. @@ -300,16 +300,16 @@ Application Defines (preprocessor macros definable with the -D option): TX_THREAD_SAFE_CLIB Enable support for thread-safe C library. Only the Xtensa C library and the newlib library are supported for thread-safe operation. - When this is enabled, half the available memory - space is allocated by default, below the system - stack, for the heap. The heap size and location + When this is enabled, half the available memory + space is allocated by default, below the system + stack, for the heap. The heap size and location can be customized in tx_application_define. Default off. NOTE: Thread safe support for Xtensa C library requires Xtensa Tools version RF-2015.2 or later. - TX_ENABLE_STACK_CHECKING Enable generic ThreadX support for stack + TX_ENABLE_STACK_CHECKING Enable generic ThreadX support for stack overflow checking. This can help avoid long debugging sessions or customer support calls by identifying many crashes caused by stack @@ -327,13 +327,13 @@ Application Defines (preprocessor macros definable with the -D option): All generic ThreadX options in tx_user.h may also be defined with -D. - Note, the above defines are not specific to Xtensa processors, so + Note, the above defines are not specific to Xtensa processors, so their names begin with "TX_". Defines below are unique to the Xtensa port so have names beginning with "XT_". XT_SIMULATOR Set this if building to run on the simulator. Takes advantage of certain simulator control - and reporting facilities, and adjusts timing + and reporting facilities, and adjusts timing of periodic tick to provide a more acceptable performance in simulation (see XT_CLOCK_FREQ). Set by default unless PLATFORM is overridden. @@ -348,33 +348,33 @@ Application Defines (preprocessor macros definable with the -D option): provided Makefile when PLATFORM=board and BOARD is defined (eg. PLATFORM=board BOARD=xtkc705). - XT_CLOCK_FREQ=freq Specifies the target processor's clock - frequency in Hz. Used primarily to set the + XT_CLOCK_FREQ=freq Specifies the target processor's clock + frequency in Hz. Used primarily to set the timer that generates the periodic interrupt. Defaults are provided and may be edited in xtensa_timer.h (see comments there also). Default for simulator provides more acceptable performance, but cannot provide real-time performance due to variation in simulation - speed per host platform and insufficient + speed per host platform and insufficient cycles between interrupts to process them. - Supported board platforms by default leave - this undefined and compute the clock frequency - at initialization unless this is explicitly + Supported board platforms by default leave + this undefined and compute the clock frequency + at initialization unless this is explicitly defined. XT_TICK_PER_SEC=n Specifies the frequency of the periodic tick. XT_TIMER_INDEX=n Specifies which timer to use for ThreadX. - Set this if your Xtensa processor configuration - provides more than one suitable timer and you + Set this if your Xtensa processor configuration + provides more than one suitable timer and you want to override the default. See xtensa_timer.h. XT_INTEXC_HOOKS Enables hooks in interrupt vector handlers to support dynamic installation of exception - and interrupt handlers. Used by automatic + and interrupt handlers. Used by automatic regression test programs. Disabled by default. - + XT_USE_OVLY Enable code overlay support. XT_USE_SWPRI Enable software prioritization of interrupts. @@ -411,7 +411,7 @@ In the windowed ABI the registers of the current window are used as follows: There are no callee-save registers. The windowed hardware automatically saves registers a0-a3 on a call4, a0-a8 on a call8, a0-a12 on a call12, by rotating the register window. Hardware triggers window overflow and -underflow exceptions as necessary when registers outside the current +underflow exceptions as necessary when registers outside the current window need to be spilled to preallocated space in the stack frame, or restored. Complete details are in the Xtensa manuals. The entire windowed register file is saved and restored on interrupt or thread context switch. @@ -453,11 +453,11 @@ As a consequence, the application developer should NOT assume that special registers are preserved over a ThreadX API call such as tx_thread_sleep. If multiple threads use a register, the caller must save and restore it. -The saved context stack frames for context switches that occur as a result -of interrupt handling (interrupt frame) or from thread-level API calls +The saved context stack frames for context switches that occur as a result +of interrupt handling (interrupt frame) or from thread-level API calls (solicited frame) are described in human readable form in xtensa_context.h . All suspended threads have one of these two types of stack frames. The top -of the suspended thread's stack is pointed to by tx_thread_stack_ptr in the +of the suspended thread's stack is pointed to by tx_thread_stack_ptr in the associated thread control block TX_THREAD. An Xtensa architecture port-specific extension to the thread control block tx_thread_solicited contains 1 for a thread that is currently suspended from an API call, otherwise contains 0. @@ -477,7 +477,7 @@ yield better results. See the compiler manual for details. You can eliminate the ThreadX basic API error checking by compiling your application code with the symbol TX_DISABLE_ERROR_CHECKING defined before -tx_api.h is included. +tx_api.h is included. The Xtensa architecture port-specific assembly files are coded with no file-scope labels inside functions (all labels inside functions begin with @@ -510,7 +510,7 @@ vector locations. The XEA2 architecture supports several different classes of exceptions and interrupts. Being a configurable architecture, many of these are optional, and the vector locations are determined by your processor configuration. The handlers provided use conditional -compilation to adapt to your processor configuration and include only +compilation to adapt to your processor configuration and include only the code that is needed. Xtensa vector locations may reside almost anywhere, including in ROM. @@ -596,7 +596,7 @@ mentioned because there is code to handle them in xtensa_vectors.S. calls _tx_thread_context_save, which saves the rest of the interrupt context. After this the handler sets up a C environment and enables the high-priority class of interrupts (which do not interact with - ThreadX), then reads EXCCAUSE and uses the cause (number) to index + ThreadX), then reads EXCCAUSE and uses the cause (number) to index into a table of user-specified handlers. The correct handler is then called. If the handler returns, the context is restored and control is returned to the code that caused the exception. The user-defined @@ -607,7 +607,7 @@ mentioned because there is code to handle them in xtensa_vectors.S. the handler enables all interrupts above that priority level after saving the thread context and switching to the interrupt stack if it is not a nested interrupt. It then sets up the environment for C code - and then calls the handler (found in the handler table) for the + and then calls the handler (found in the handler table) for the interrupt number. If the user has not specified a handler, then the default handler will be called, which will terminate the program. @@ -627,8 +627,8 @@ mentioned because there is code to handle them in xtensa_vectors.S. 8.2 Medium Priority Interrupt Handlers (XEA2) - Medium priority interrupts are those at levels 2 up to XCHAL_EXCM_LEVEL, - a configuration-specific maximum interrupt level affected by the global + Medium priority interrupts are those at levels 2 up to XCHAL_EXCM_LEVEL, + a configuration-specific maximum interrupt level affected by the global 'exception mode' bit in the processor status word (PS.EXCM). Interrupt levels above XCHAL_EXCM_LEVEL are of the high-priority class. The Xtensa hardware documentation considers medium priority interrupts @@ -640,12 +640,12 @@ mentioned because there is code to handle them in xtensa_vectors.S. 8.3 High Priority Interrupt Handlers (XEA2) - High priority interrupts are those strictly above XCHAL_EXCM_LEVEL, - a configuration-specific maximum interrupt level affected by the + High priority interrupts are those strictly above XCHAL_EXCM_LEVEL, + a configuration-specific maximum interrupt level affected by the global 'exception mode' bit in the processor status word (PS.EXCM). High priority handlers may not directly interact with ThreadX at all, and are described here only for the sake of completeness. They must - be coded in assembler (may not be coded in C) and are intended to be + be coded in assembler (may not be coded in C) and are intended to be used for handling extremely high frequency hardware events that need to be handled in only a few cycles. A high priority interrupt handler may trigger a software interrupt at a medium or low priority level to @@ -655,7 +655,7 @@ mentioned because there is code to handle them in xtensa_vectors.S. priority interrupt, providing for fast dispatch and efficient nesting on top of lower priority interrupts. Handlers are templates included only for the vectors that exist in your Xtensa processor configuration. - These templates are written for only one interrupt per high priority + These templates are written for only one interrupt per high priority level to minimize latency servicing very fast time-critical interrupts. The vector code jumps to the corresponding first-level interrupt handler, which then executes application-provided assembler code before returning @@ -665,7 +665,7 @@ mentioned because there is code to handle them in xtensa_vectors.S. Kernel mode is not used in this port of ThreadX, and therefore kernel exceptions should not happen. A stub is provided for the vector that - triggers the debugger (if connected) or calls _xt_panic to freeze the + triggers the debugger (if connected) or calls _xt_panic to freeze the processor should a kernel exception occur. 8.5 Alloca Exception Handler @@ -692,18 +692,18 @@ mentioned because there is code to handle them in xtensa_vectors.S. 8.7 Co-Processor Exception Handler A coprocessor exception is generated when a thread accesses a - coprocessor that it does not "own". Ownership represents which - thread's state is currently in the coprocessor. Co-processors are - context-switched "lazily" (on demand) only when a non-owning thread - uses a coprocessor instruction, otherwise a thread retains ownership + coprocessor that it does not "own". Ownership represents which + thread's state is currently in the coprocessor. Co-processors are + context-switched "lazily" (on demand) only when a non-owning thread + uses a coprocessor instruction, otherwise a thread retains ownership even when it is preempted from the main processor. The coprocessor exception handler performs the context-switch and manages ownership. Co-processors may not be used by any code outside the context of a thread. A coprocessor exception triggered by code that is not part of a running thread is a fatal error and ThreadX/Xtensa will panic. - This restriction is intended to reduce the overhead of saving and - restoring coprocessor state (which can be quite large) and in + This restriction is intended to reduce the overhead of saving and + restoring coprocessor state (which can be quite large) and in particular remove that overhead from interrupt handlers. It also reduces the thread stack size requirement by allowing coprocessor state to be saved in the thread control block rather than the stack. @@ -727,7 +727,7 @@ mentioned because there is code to handle them in xtensa_vectors.S. A double exception is a general exception that happens while the processor is in exception mode (PS.EXCM set), and thus indicates a bug in kernel code. The double exception vector handler triggers - the debugger (if connected) or calls _xt_panic to freeze the + the debugger (if connected) or calls _xt_panic to freeze the processor. 8.10 Window Overflow and Underflow Exception Handlers @@ -755,13 +755,13 @@ mentioned because there is code to handle them in xtensa_vectors.S. 9. Overlay Support (XEA2 only) ThreadX supports the overlay feature of the Xtensa toolsuite. To enable overlay support, -the ThreadX library should be built with XT_USE_OVLY defined. In addition, the linker -command line must use the overlay library via the -loverlay linker option and the +the ThreadX library should be built with XT_USE_OVLY defined. In addition, the linker +command line must use the overlay library via the -loverlay linker option and the xtensa_overlay_os_hook.o object file must be explicitly specified in order to override the overlay libary version. -You will also need to generate a custom LSP for overlay use. Please reference the -Xtensa System Software Reference and Xtenas Linker Support Packages (LSPs) for more +You will also need to generate a custom LSP for overlay use. Please reference the +Xtensa System Software Reference and Xtenas Linker Support Packages (LSPs) for more information on using overlays. diff --git a/ports/xtensa/xcc/src/tx_clib_lock.c b/ports/xtensa/xcc/src/tx_clib_lock.c index b95bf12b..9e308720 100644 --- a/ports/xtensa/xcc/src/tx_clib_lock.c +++ b/ports/xtensa/xcc/src/tx_clib_lock.c @@ -30,16 +30,6 @@ /* operation of the C library. Both newlib and the Xtensa C Library */ /* are supported. */ /* */ -/* RELEASE HISTORY */ -/* */ -/* DATE NAME DESCRIPTION */ -/* */ -/* 12-31-2020 Cadence Design Systems Initial Version 6.1.3 */ -/* 12-31-2023 Xiuwen Cai Modified comment(s), and */ -/* added error handling in */ -/* lock initialization, */ -/* resulting in version 6.4.0 */ -/* */ /**************************************************************************/ #include "tx_api.h" /* TX_THREAD_SAFE_CLIB may be defined by tx_port.h */ @@ -137,7 +127,7 @@ __env_unlock (struct _reent * ptr) #include <errno.h> #include <sys/reent.h> - + #define XT_NUM_CLIB_LOCKS (_MAX_LOCK + FOPEN_MAX) typedef TX_MUTEX * _Rmtx; diff --git a/ports/xtensa/xcc/src/tx_initialize_low_level.c b/ports/xtensa/xcc/src/tx_initialize_low_level.c index eebae217..de2c2b93 100644 --- a/ports/xtensa/xcc/src/tx_initialize_low_level.c +++ b/ports/xtensa/xcc/src/tx_initialize_low_level.c @@ -48,15 +48,6 @@ int32_t xt_timer_intnum = -1; /* available RAM memory address for tx_application_define. */ /* It also sets the default heap region for the optional C library. */ /* */ -/* RELEASE HISTORY */ -/* */ -/* DATE NAME DESCRIPTION */ -/* */ -/* 12-31-2020 Cadence Design Systems Initial Version 6.1.3 */ -/* 04-25-2022 Scott Larson Modified comments and updated */ -/* function names, */ -/* resulting in version 6.1.11 */ -/* */ /**************************************************************************/ VOID _tx_initialize_low_level(VOID) { @@ -123,8 +114,8 @@ VOID _tx_initialize_low_level(VOID) Initialize co-processor management for threads. Leave CPENABLE alone. This is called from a normal Xtensa single-threaded run-time environment before multi-threading has commenced. All co-processors are enabled. - It is important NOT to clear CPENABLE yet because tx_application_define() - is user code which might use a co-processor. The co-processor exception + It is important NOT to clear CPENABLE yet because tx_application_define() + is user code which might use a co-processor. The co-processor exception handler does not expect to be called outside a thread. */ _xt_coproc_init(); diff --git a/ports/xtensa/xcc/src/tx_thread_context_restore.S b/ports/xtensa/xcc/src/tx_thread_context_restore.S index c36f0a5c..89a66b35 100644 --- a/ports/xtensa/xcc/src/tx_thread_context_restore.S +++ b/ports/xtensa/xcc/src/tx_thread_context_restore.S @@ -1,10 +1,11 @@ /*************************************************************************** - * Copyright (c) 2024 Microsoft Corporation - * + * Copyright (c) 2024 Microsoft Corporation + * Copyright (c) 2026-present Eclipse ThreadX contributors + * * This program and the accompanying materials are made available under the * terms of the MIT License which is available at * https://opensource.org/licenses/MIT. - * + * * SPDX-License-Identifier: MIT **************************************************************************/ @@ -59,11 +60,6 @@ /* preemption is necessary. Otherwise, if preemption is necessary or */ /* if no thread was running, the function returns to the scheduler. */ /* */ -/* RELEASE HISTORY */ -/* 12-31-2020 Cadence Design Systems Initial Version 6.1.3 */ -/* 10-31-2022 Scott Larson Updated EPK definitions, */ -/* resulting in version 6.2.0 */ -/* */ /**************************************************************************/ // VOID _tx_thread_context_restore(VOID) diff --git a/ports/xtensa/xcc/src/tx_thread_context_save.S b/ports/xtensa/xcc/src/tx_thread_context_save.S index 109b954f..397ea822 100644 --- a/ports/xtensa/xcc/src/tx_thread_context_save.S +++ b/ports/xtensa/xcc/src/tx_thread_context_save.S @@ -1,10 +1,11 @@ /*************************************************************************** - * Copyright (c) 2024 Microsoft Corporation - * + * Copyright (c) 2024 Microsoft Corporation + * Copyright (c) 2026-present Eclipse ThreadX contributors + * * This program and the accompanying materials are made available under the * terms of the MIT License which is available at * https://opensource.org/licenses/MIT. - * + * * SPDX-License-Identifier: MIT **************************************************************************/ @@ -33,8 +34,8 @@ /**************************************************************************/ /**************************************************************************/ -/** */ -/** ThreadX Component */ +/** */ +/** ThreadX Component */ /** */ /** Thread */ /** */ @@ -49,23 +50,17 @@ .text -/**************************************************************************/ -/* */ -/* DESCRIPTION */ -/* */ -/* This function saves the context of an executing thread in the */ -/* beginning of interrupt processing. The function also ensures that */ -/* the system stack is used upon return to the calling ISR. */ -/* */ -/* Interrupts remain disabled and no exceptions are triggered! */ -/* */ -/* RELEASE HISTORY */ -/* */ -/* DATE NAME DESCRIPTION */ -/* */ -/* 12-31-2020 Cadence Design Systems Initial Version 6.1.3 */ -/* */ -/**************************************************************************/ +/**************************************************************************/ +/* */ +/* DESCRIPTION */ +/* */ +/* This function saves the context of an executing thread in the */ +/* beginning of interrupt processing. The function also ensures that */ +/* the system stack is used upon return to the calling ISR. */ +/* */ +/* Interrupts remain disabled and no exceptions are triggered! */ +/* */ +/**************************************************************************/ // VOID _tx_thread_context_save(VOID) // { @@ -77,13 +72,13 @@ _tx_thread_context_save: /* Please note: Control flow might seem strange. This is because it has been optimized to avoid taken branches in the longest normal path (the critical - one for worst-case latency), presumed to be a non-nested interrupt and + one for worst-case latency), presumed to be a non-nested interrupt and non-idle) and to hide pipeline interlock cycles where possible. */ /* Save a couple of scratch regs to work with that are preserved over the - call to _xt_context_save. The latter assumes the interruptee's values + call to _xt_context_save. The latter assumes the interruptee's values of these are already saved and these regs contain different data to be preserved, so doesn't save them in the stack frame, and thereby requires that its caller have already saved them in the interrupt stack frame. @@ -107,7 +102,7 @@ _tx_thread_context_save: .Ln_tx_thread_not_nested_save: /* Otherwise, not nested, check to see if a thread was running. */ - // else + // else // { // if (_tx_thread_current_ptr) // { @@ -127,10 +122,10 @@ _tx_thread_context_save: .L_tx_thread_idle_system_save: - /* + /* If interrupted in the idle state, it's not necessary to save any context. - But even in the idle case where we are already on the system stack, it is - necessary to reset the (system) stack pointer so a series of consecutive + But even in the idle case where we are already on the system stack, it is + necessary to reset the (system) stack pointer so a series of consecutive interrupts in the idle state do not keep moving the SP downward. */ @@ -146,7 +141,7 @@ _tx_thread_context_save: /* Nested interrupt condition. */ /* Save the rest of the interrupted context and return to ISR. */ call0 _xt_context_save - + mov a0, a12 /* retrieve return address */ ret diff --git a/ports/xtensa/xcc/src/tx_thread_interrupt_control.c b/ports/xtensa/xcc/src/tx_thread_interrupt_control.c index dfc9552d..3a0cae27 100644 --- a/ports/xtensa/xcc/src/tx_thread_interrupt_control.c +++ b/ports/xtensa/xcc/src/tx_thread_interrupt_control.c @@ -1,10 +1,11 @@ /*************************************************************************** - * Copyright (c) 2024 Microsoft Corporation - * + * Copyright (c) 2024 Microsoft Corporation + * Copyright (c) 2026-present Eclipse ThreadX contributors + * * This program and the accompanying materials are made available under the * terms of the MIT License which is available at * https://opensource.org/licenses/MIT. - * + * * SPDX-License-Identifier: MIT **************************************************************************/ @@ -33,8 +34,8 @@ /**************************************************************************/ /**************************************************************************/ -/** */ -/** ThreadX Component */ +/** */ +/** ThreadX Component */ /** */ /** Thread */ /** */ @@ -46,21 +47,15 @@ #include "xtensa_rtos.h" -/**************************************************************************/ -/* */ -/* DESCRIPTION */ -/* */ -/* This function is responsible for changing the interrupt lockout */ -/* posture of the system. */ -/* NOTE: In earlier versions this was implemented in assembly. */ -/* */ -/* RELEASE HISTORY */ -/* */ -/* DATE NAME DESCRIPTION */ -/* */ -/* 12-31-2020 Cadence Design Systems Initial Version 6.1.3 */ -/* */ -/**************************************************************************/ +/**************************************************************************/ +/* */ +/* DESCRIPTION */ +/* */ +/* This function is responsible for changing the interrupt lockout */ +/* posture of the system. */ +/* NOTE: In earlier versions this was implemented in assembly. */ +/* */ +/**************************************************************************/ UINT _tx_thread_interrupt_control(UINT new_posture) { diff --git a/ports/xtensa/xcc/src/tx_thread_schedule.S b/ports/xtensa/xcc/src/tx_thread_schedule.S index a98d7495..448dc6d7 100644 --- a/ports/xtensa/xcc/src/tx_thread_schedule.S +++ b/ports/xtensa/xcc/src/tx_thread_schedule.S @@ -1,10 +1,11 @@ /*************************************************************************** - * Copyright (c) 2024 Microsoft Corporation - * + * Copyright (c) 2024 Microsoft Corporation + * Copyright (c) 2026-present Eclipse ThreadX contributors + * * This program and the accompanying materials are made available under the * terms of the MIT License which is available at * https://opensource.org/licenses/MIT. - * + * * SPDX-License-Identifier: MIT **************************************************************************/ @@ -56,14 +57,6 @@ /* the _tx_thread_execute_ptr variable. Once a thread pointer appears */ /* in the variable, the corresponding thread is resumed. */ /* */ -/* RELEASE HISTORY */ -/* */ -/* DATE NAME DESCRIPTION */ -/* */ -/* 12-31-2020 Cadence Design Systems Initial Version 6.1.3 */ -/* 10-31-2022 Scott Larson Updated EPK definitions, */ -/* resulting in version 6.2.0 */ -/* */ /**************************************************************************/ // VOID _tx_thread_schedule(VOID) diff --git a/ports/xtensa/xcc/src/tx_thread_stack_build.S b/ports/xtensa/xcc/src/tx_thread_stack_build.S index 53d7e1c6..a52fc35e 100644 --- a/ports/xtensa/xcc/src/tx_thread_stack_build.S +++ b/ports/xtensa/xcc/src/tx_thread_stack_build.S @@ -1,10 +1,11 @@ /*************************************************************************** - * Copyright (c) 2024 Microsoft Corporation - * + * Copyright (c) 2024 Microsoft Corporation + * Copyright (c) 2026-present Eclipse ThreadX contributors + * * This program and the accompanying materials are made available under the * terms of the MIT License which is available at * https://opensource.org/licenses/MIT. - * + * * SPDX-License-Identifier: MIT **************************************************************************/ @@ -33,8 +34,8 @@ /**************************************************************************/ /**************************************************************************/ -/** */ -/** ThreadX Component */ +/** */ +/** ThreadX Component */ /** */ /** Thread */ /** */ @@ -47,21 +48,15 @@ .text -/**************************************************************************/ -/* */ -/* DESCRIPTION */ -/* */ +/**************************************************************************/ +/* */ +/* DESCRIPTION */ +/* */ /* This function builds a stack frame on the supplied thread's stack. */ /* The stack frame looks like an interrupt frame or a solicited frame */ -/* depending on the exception architecture of the target hardware. */ -/* */ -/* RELEASE HISTORY */ -/* */ -/* DATE NAME DESCRIPTION */ -/* */ -/* 12-31-2020 Cadence Design Systems Initial Version 6.1.3 */ -/* */ -/**************************************************************************/ +/* depending on the exception architecture of the target hardware. */ +/* */ +/**************************************************************************/ // VOID _tx_thread_stack_build(TX_THREAD *thread_ptr, VOID (*function_ptr)(VOID)) // { diff --git a/ports/xtensa/xcc/src/tx_thread_system_return.S b/ports/xtensa/xcc/src/tx_thread_system_return.S index 38330082..d1fc4a9f 100644 --- a/ports/xtensa/xcc/src/tx_thread_system_return.S +++ b/ports/xtensa/xcc/src/tx_thread_system_return.S @@ -1,10 +1,11 @@ /*************************************************************************** - * Copyright (c) 2024 Microsoft Corporation - * + * Copyright (c) 2024 Microsoft Corporation + * Copyright (c) 2026-present Eclipse ThreadX contributors + * * This program and the accompanying materials are made available under the * terms of the MIT License which is available at * https://opensource.org/licenses/MIT. - * + * * SPDX-License-Identifier: MIT **************************************************************************/ @@ -56,13 +57,6 @@ /* is saved since the compiler assumes temp registers are going to get */ /* slicked by a function call anyway. */ /* */ -/* RELEASE HISTORY */ -/* */ -/* DATE NAME DESCRIPTION */ -/* 12-31-2020 Cadence Design Systems Initial Version 6.1.3 */ -/* 10-31-2022 Scott Larson Updated EPK definitions, */ -/* resulting in version 6.2.0 */ -/* */ /**************************************************************************/ // VOID _tx_thread_system_return(VOID) diff --git a/ports/xtensa/xcc/src/tx_timer_interrupt.S b/ports/xtensa/xcc/src/tx_timer_interrupt.S index 7cca247c..d09badde 100644 --- a/ports/xtensa/xcc/src/tx_timer_interrupt.S +++ b/ports/xtensa/xcc/src/tx_timer_interrupt.S @@ -1,10 +1,11 @@ /*************************************************************************** - * Copyright (c) 2024 Microsoft Corporation - * + * Copyright (c) 2024 Microsoft Corporation + * Copyright (c) 2026-present Eclipse ThreadX contributors + * * This program and the accompanying materials are made available under the * terms of the MIT License which is available at * https://opensource.org/licenses/MIT. - * + * * SPDX-License-Identifier: MIT **************************************************************************/ @@ -33,8 +34,8 @@ /**************************************************************************/ /**************************************************************************/ -/** */ -/** ThreadX Component */ +/** */ +/** ThreadX Component */ /** */ /** Timer */ /** */ @@ -49,26 +50,17 @@ .text -/**************************************************************************/ -/* */ -/* DESCRIPTION */ -/* */ -/* This function processes the hardware timer interrupt. This */ -/* processing includes incrementing the system clock and checking for */ -/* time slice and/or timer expiration. If either is found, the */ -/* interrupt context save/restore functions are called along with the */ -/* expiration functions. */ -/* */ -/* RELEASE HISTORY */ -/* */ -/* DATE NAME DESCRIPTION */ -/* */ -/* 12-31-2020 Cadence Design Systems Initial Version 6.1.3 */ -/* 04-25-2022 Scott Larson Modified comments and updated */ -/* function name, */ -/* resulting in version 6.1.11 */ -/* */ -/**************************************************************************/ +/**************************************************************************/ +/* */ +/* DESCRIPTION */ +/* */ +/* This function processes the hardware timer interrupt. This */ +/* processing includes incrementing the system clock and checking for */ +/* time slice and/or timer expiration. If either is found, the */ +/* interrupt context save/restore functions are called along with the */ +/* expiration functions. */ +/* */ +/**************************************************************************/ // VOID _tx_timer_interrupt(VOID) // { @@ -99,13 +91,13 @@ _tx_timer_interrupt: /* Xtensa timers work by comparing a cycle counter with a preset value. - Once the match occurs an interrupt is generated, and the handler has + Once the match occurs an interrupt is generated, and the handler has to set a new cycle count into the comparator. To avoid clock drift due to interrupt latency, the new cycle count is computed from the old, - not the time the interrupt was serviced. However if a timer interrupt + not the time the interrupt was serviced. However if a timer interrupt is ever serviced more than one tick late, it is necessary to process - multiple ticks until the new cycle count is in the future, otherwise - the next timer interrupt would not occur until after the cycle counter + multiple ticks until the new cycle count is in the future, otherwise + the next timer interrupt would not occur until after the cycle counter had wrapped (2^32 cycles later). do { diff --git a/ports/xtensa/xcc/src/tx_xtensa_stack_error_handler.c b/ports/xtensa/xcc/src/tx_xtensa_stack_error_handler.c index 012b3612..a46f65cc 100644 --- a/ports/xtensa/xcc/src/tx_xtensa_stack_error_handler.c +++ b/ports/xtensa/xcc/src/tx_xtensa_stack_error_handler.c @@ -1,10 +1,11 @@ /*************************************************************************** - * Copyright (c) 2024 Microsoft Corporation - * + * Copyright (c) 2024 Microsoft Corporation + * Copyright (c) 2026-present Eclipse ThreadX contributors + * * This program and the accompanying materials are made available under the * terms of the MIT License which is available at * https://opensource.org/licenses/MIT. - * + * * SPDX-License-Identifier: MIT **************************************************************************/ @@ -33,8 +34,8 @@ /**************************************************************************/ /**************************************************************************/ -/** */ -/** ThreadX Component */ +/** */ +/** ThreadX Component */ /** */ /** Support for Xtensa applications */ /** */ @@ -65,10 +66,10 @@ #include <unistd.h> -/**************************************************************************/ -/* */ -/* DESCRIPTION */ -/* */ +/**************************************************************************/ +/* */ +/* DESCRIPTION */ +/* */ /* Callback to notify of a stack overflow when registered with */ /* tx_stack_error_notify and stack checking is enabled (ThreadX */ /* is compiled with TX_ENABLE_STACK_CHECKING defined). */ @@ -85,20 +86,14 @@ /* - Passes control to the debugger (if attached). */ /* - Terminates the simulation (simulator only). */ /* - Panics. */ -/* */ -/* RELEASE HISTORY */ -/* */ -/* DATE NAME DESCRIPTION */ -/* */ -/* 12-31-2020 Cadence Design Systems Initial Version 6.1.3 */ -/* */ -/**************************************************************************/ +/* */ +/**************************************************************************/ VOID _tx_xtensa_stack_error_handler(TX_THREAD * thread) { #ifdef XT_SIMULATOR register int32_t sc __asm__ ("a2") = SYS_log_msg; - register char * msg __asm__ ("a3") + register char * msg __asm__ ("a3") = "**** Stack overflow in thread 0x%08x.\n"; register TX_THREAD * thd __asm__ ("a4") = thread; __asm__ volatile ("simcall" :: "a" (sc), "a" (msg), "a" (thd) ); diff --git a/ports/xtensa/xcc/src/xtensa_context.S b/ports/xtensa/xcc/src/xtensa_context.S index af3138aa..e4b9aa0a 100644 --- a/ports/xtensa/xcc/src/xtensa_context.S +++ b/ports/xtensa/xcc/src/xtensa_context.S @@ -41,12 +41,6 @@ /* anyway, and are always restored even in Call0 ABI. Only A14, A15 are */ /* truly handled as callee-save regs. */ /* */ -/* RELEASE HISTORY */ -/* */ -/* DATE NAME DESCRIPTION */ -/* */ -/* 12-31-2020 Cadence Design Systems Initial Version 6.1.3 */ -/* */ /**************************************************************************/ @@ -71,7 +65,7 @@ interrupt stack frame defined in xtensa_rtos.h. Its counterpart is _xt_context_restore (which also restores A12, A13). Caller is expected to have saved PC, PS, A0, A1 (SP), A12, A13 in the frame. -This function preserves A12 & A13 in order to provide the caller with 2 scratch +This function preserves A12 & A13 in order to provide the caller with 2 scratch regs that need not be saved over the call to this function. The choice of which 2 regs to provide is governed by xthal_window_spill_nw and xthal_save_extra_nw, to avoid moving data more than necessary. Caller can assign regs accordingly. @@ -80,7 +74,7 @@ Entry Conditions: A0 = Return address in caller. A1 = Stack pointer of interrupted thread or handler ("interruptee"). Original A12, A13 have already been saved in the interrupt stack frame. - Other processor state except PC, PS, A0, A1 (SP), A12, A13, is as at the + Other processor state except PC, PS, A0, A1 (SP), A12, A13, is as at the point of interruption. If windowed ABI, PS.EXCM = 1 (exceptions disabled). @@ -156,8 +150,8 @@ _xt_context_save: and underflow exceptions disabled (assured by PS.EXCM == 1). */ s32i a12, sp, XT_STK_TMP0 /* temp. save stuff in stack frame */ - s32i a13, sp, XT_STK_TMP1 - s32i a9, sp, XT_STK_TMP2 + s32i a13, sp, XT_STK_TMP1 + s32i a9, sp, XT_STK_TMP2 /* Save the overlay state if we are supporting overlays. Since we just saved @@ -177,12 +171,12 @@ _xt_context_save: call0 xthal_window_spill_nw /* preserves only a4,5,8,9,12,13 */ addi sp, sp, -XT_STK_FRMSZ l32i a12, sp, XT_STK_TMP0 /* recover stuff from stack frame */ - l32i a13, sp, XT_STK_TMP1 - l32i a9, sp, XT_STK_TMP2 + l32i a13, sp, XT_STK_TMP1 + l32i a9, sp, XT_STK_TMP2 #endif #if XCHAL_EXTRA_SA_SIZE > 0 - /* + /* NOTE: Normally the xthal_save_extra_nw macro only affects address registers a2-a5. It is theoretically possible for Xtensa processor designers to write TIE that causes more address registers to be @@ -212,7 +206,7 @@ _xt_context_restore !! MUST BE CALLED ONLY BY 'CALL0' INSTRUCTION !! Restores all Xtensa processor state except PC, PS, A0, A1 (SP) (and in Call0 -ABI, A14, A15 which are preserved by all interrupt handlers) from an interrupt +ABI, A14, A15 which are preserved by all interrupt handlers) from an interrupt stack frame defined in xtensa_rtos.h . Its counterpart is _xt_context_save (whose caller saved A12, A13). @@ -225,7 +219,7 @@ Entry Conditions: Exit conditions: A0 = Return address in caller. A1 = Stack pointer of interrupted thread or handler ("interruptee"). - Other processor state except PC, PS, A0, A1 (SP), is as at the point + Other processor state except PC, PS, A0, A1 (SP), is as at the point of interruption. *******************************************************************************/ @@ -236,7 +230,7 @@ Exit conditions: _xt_context_restore: #if XCHAL_EXTRA_SA_SIZE > 0 - /* + /* NOTE: Normally the xthal_restore_extra_nw macro only affects address registers a2-a5. It is theoretically possible for Xtensa processor designers to write TIE that causes more address registers to be @@ -312,7 +306,7 @@ _xt_context_restore: /* Call0 ABI callee-saved regs a12-15 do not need to be restored here. - However a12-13 were saved for scratch before XT_RTOS_INT_ENTER(), + However a12-13 were saved for scratch before XT_RTOS_INT_ENTER(), so need to be restored anyway, despite being callee-saved in Call0. */ l32i a12, sp, XT_STK_A12 @@ -337,7 +331,7 @@ to "unowned". Leaves CPENABLE as it found it (does NOT clear it). Called during initialization of the RTOS, before any threads run. This may be called from normal Xtensa single-threaded application code which -might use co-processors. The Xtensa run-time initialization enables all +might use co-processors. The Xtensa run-time initialization enables all co-processors. They must remain enabled here, else a co-processor exception might occur outside of a thread, which the exception handler doesn't expect. @@ -378,13 +372,13 @@ _xt_coproc_init: _xt_coproc_release -Releases any and all co-processors owned by a given thread. The thread is +Releases any and all co-processors owned by a given thread. The thread is identified by it's co-processor state save area defined in xtensa_context.h . Must be called before a thread's co-proc save area is deleted to avoid memory corruption when the exception handler tries to save the state. May be called when a thread terminates or completes but does not delete -the co-proc save area, to avoid the exception handler having to save the +the co-proc save area, to avoid the exception handler having to save the thread's co-proc state before another thread can use it (optimization). Entry Conditions: diff --git a/ports/xtensa/xcc/src/xtensa_coproc_handler.S b/ports/xtensa/xcc/src/xtensa_coproc_handler.S index 33de2070..0540d633 100644 --- a/ports/xtensa/xcc/src/xtensa_coproc_handler.S +++ b/ports/xtensa/xcc/src/xtensa_coproc_handler.S @@ -28,12 +28,6 @@ /* Xtensa coprocessor handling routines. This code is only active if */ /* one or more coprocessors are present. */ /* */ -/* RELEASE HISTORY */ -/* */ -/* DATE NAME DESCRIPTION */ -/* */ -/* 12-31-2020 Cadence Design Systems Initial Version 6.1.3 */ -/* */ /**************************************************************************/ @@ -225,7 +219,7 @@ _xt_coproc_handler: _tx_thread_coproc_state: - // return ( _tx_thread_system_state == 0 && _tx_thread_current_ptr != 0 + // return ( _tx_thread_system_state == 0 && _tx_thread_current_ptr != 0 // ? (&_tx_thread_current_ptr->tx_thread_cp_state) : 0 ) movi a15, _tx_thread_system_state // check if interrupt state @@ -512,15 +506,15 @@ _xt_coproc_exc: .global _xt_coproc_exc .type _xt_coproc_exc,@function .align 4 - + _xt_coproc_exc: - + mov a0, sp // Allocate stack frame addi sp, sp, -XT_STK_FRMSZ s32i a0, sp, XT_STK_A1 // save SP #if XCHAL_HAVE_WINDOWED s32e a0, sp, -12 // for debug backtrace -#endif +#endif rsr a0, PS s32i a0, sp, XT_STK_PS // save PS rsr a0, EPC_1 diff --git a/ports/xtensa/xcc/src/xtensa_init.c b/ports/xtensa/xcc/src/xtensa_init.c index 298ca28d..d153ad35 100644 --- a/ports/xtensa/xcc/src/xtensa_init.c +++ b/ports/xtensa/xcc/src/xtensa_init.c @@ -27,12 +27,6 @@ /* */ /* Xtensa initialization routines. */ /* */ -/* RELEASE HISTORY */ -/* */ -/* DATE NAME DESCRIPTION */ -/* */ -/* 12-31-2020 Cadence Design Systems Initial Version 6.1.3 */ -/* */ /**************************************************************************/ @@ -49,7 +43,7 @@ uint32_t xt_tick_divisor = 0; /* cached number of cycles per tick */ /* -Compute and initialize at run-time the tick divisor (the number of +Compute and initialize at run-time the tick divisor (the number of processor clock cycles in an RTOS tick, used to set the tick timer). Called when the processor clock frequency is not known at compile-time. */ diff --git a/ports/xtensa/xcc/src/xtensa_intr_asm.S b/ports/xtensa/xcc/src/xtensa_intr_asm.S index 78fd8a70..e972378a 100644 --- a/ports/xtensa/xcc/src/xtensa_intr_asm.S +++ b/ports/xtensa/xcc/src/xtensa_intr_asm.S @@ -28,12 +28,6 @@ /* Xtensa interrupt handling data and assembly routines. */ /* Also see xtensa_intr.c. */ /* */ -/* RELEASE HISTORY */ -/* */ -/* DATE NAME DESCRIPTION */ -/* */ -/* 12-31-2020 Cadence Design Systems Initial Version 6.1.3 */ -/* */ /**************************************************************************/ diff --git a/ports/xtensa/xcc/src/xtensa_intr_wrapper.c b/ports/xtensa/xcc/src/xtensa_intr_wrapper.c index ff70f4ea..4ccb29f5 100644 --- a/ports/xtensa/xcc/src/xtensa_intr_wrapper.c +++ b/ports/xtensa/xcc/src/xtensa_intr_wrapper.c @@ -27,12 +27,6 @@ /* */ /* Xtensa-specific interrupt handler wrapper. */ /* */ -/* RELEASE HISTORY */ -/* */ -/* DATE NAME DESCRIPTION */ -/* */ -/* 12-31-2020 Cadence Design Systems Initial Version 6.1.3 */ -/* */ /**************************************************************************/ diff --git a/ports/xtensa/xcc/src/xtensa_overlay_os_hook.c b/ports/xtensa/xcc/src/xtensa_overlay_os_hook.c index 8fd92701..4a63479c 100644 --- a/ports/xtensa/xcc/src/xtensa_overlay_os_hook.c +++ b/ports/xtensa/xcc/src/xtensa_overlay_os_hook.c @@ -27,12 +27,6 @@ /* */ /* Xtensa overlay manager OS hooks for ThreadX. XEA2 only. */ /* */ -/* RELEASE HISTORY */ -/* */ -/* DATE NAME DESCRIPTION */ -/* */ -/* 12-31-2020 Cadence Design Systems Initial Version 6.1.3 */ -/* */ /**************************************************************************/ @@ -45,7 +39,7 @@ /* Required to work around a bug in the overlay header. */ #ifdef XT_DISABLE_OVERLAYS #undef xt_overlay_fatal_error -#define xt_overlay_fatal_error(id) +#define xt_overlay_fatal_error(id) #endif @@ -67,7 +61,7 @@ xt_overlay_init_os(void) /* Create the mutex for overlay access. Priority inheritance is * required. */ - UINT status = + UINT status = tx_mutex_create (&xt_overlay_mutex, "xt_overlay_lock", TX_INHERIT); if (status != TX_SUCCESS) { diff --git a/ports/xtensa/xcc/src/xtensa_vectors.S b/ports/xtensa/xcc/src/xtensa_vectors.S index b115abf5..7b09638e 100644 --- a/ports/xtensa/xcc/src/xtensa_vectors.S +++ b/ports/xtensa/xcc/src/xtensa_vectors.S @@ -64,12 +64,6 @@ /* changes to the saved state in the exception frame, the changes will */ /* be applied when restoring the context. */ /* */ -/* RELEASE HISTORY */ -/* */ -/* DATE NAME DESCRIPTION */ -/* */ -/* 12-31-2020 Cadence Design Systems Initial Version 6.1.3 */ -/* */ /**************************************************************************/ @@ -297,7 +291,7 @@ /* -------------------------------------------------------------------------------- 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. -------------------------------------------------------------------------------- */ @@ -331,7 +325,7 @@ _xt_panic_message: -------------------------------------------------------------------------------- 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. @@ -363,7 +357,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, @@ -742,7 +736,7 @@ _xt_syscall_exc: ------------------------------------------------------------------------------- */ - .text + .text .type _xt_lowint1,@function .align 4 @@ -762,12 +756,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 @@ -799,7 +793,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, @@ -1181,7 +1175,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 @@ -1444,12 +1438,12 @@ _xt_nmi: 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 diff --git a/ports/xtensa/xcc/src/xtensa_vectors_xea3.S b/ports/xtensa/xcc/src/xtensa_vectors_xea3.S index 9a25dcee..22d9db89 100644 --- a/ports/xtensa/xcc/src/xtensa_vectors_xea3.S +++ b/ports/xtensa/xcc/src/xtensa_vectors_xea3.S @@ -52,12 +52,6 @@ /* changes to the saved state in the exception frame, the changes will */ /* be applied when restoring the context. */ /* */ -/* RELEASE HISTORY */ -/* */ -/* DATE NAME DESCRIPTION */ -/* */ -/* 12-31-2020 Cadence Design Systems Initial Version 6.1.3 */ -/* */ /**************************************************************************/ |