| RTXC ARM Application Notes |
Contents
NOTES FOR RUNNING RTXC EXAMPLE APPLICATIONS
RUNNING THE DUAL-MODE APPLICATION
RUNNING THE SINGLE-STACK APPLICATION
RTXC FOR ARM and THUMB SPECIFIC - TECHNICAL NOTES
RTXC FOR ARM/THUMB KNOWN LIMITATIONS
NOTES FOR RUNNING RTXC EXAMPLE APPLICATIONS
The RTXC for ARM and Thumb Processor binding was qualified using IAR Embedded Workbench. The basic philosophy of the port of RTXC to ARM and Thumb was to use Embedded Workbench in its delivered state wherever possible. Toward that goal, the startup code and ARM runtime library were generally used unmodified in the distributed working application. Since the distributed application is an example, it is not supported by Quadros Systems, Inc. The startup code is part of this example application, and is also not supported. There are separate project files for building sample applications for both the Evaluator-7T board and the Csb337 board.
The RTXC binding for ARM and Thumb to IAR Embedded Workbench was tested using several different configurations. The delivered configurations are for ARM7TDMI and ARM920T. The goal was to try as many different combinations as reasonably possible. Toward that goal, applications were built in ARM only, and ARM/Thumb mixed mode. The mixed mode application required use of the interworking option. A few of the options making up different configurations are described below:
ENDIAN - Both Big and Little endian modes supported.
16/32 bit - Both are supported including ARM/Thumb mixtures. .
Interworking - with and without interworking is supported.
The default is for the source files to be compiled for debugging. Full space and time optimizations were also successfully qualified.
RUNNING THE DUAL MODE (MULTI-STACK/SINGLE-STACK) APPLICATION:
The example applications have been qualified on the Evaluator7t with using several JTAG interfaces: Multi-ICE, MaCraigor Wiggler, MaCraigor Raven, and IAR J-Link USB. The Quadros distribution example applications were designed to run on the Cogent Csb337 or the ARM Evaluator-7t.
If you then "go", you will stop in main (rtxcmain.c). The messages are followed by a continuous sequence of alternating messages from two tasks. One task, EXAMPLE1, runs every 1 second while the other task, EXAMPLE2, runs every 5 seconds. This example application will run until stopped by the debugger.
RUNNING THE SINGLE-STACK APPLICATION:
If you then "go", you will stop in main (rtxcmain.c). Another "go" and you will see a sequence of LED display changes. See the Evaluator-7T board and the Csb337 board documentation for details. What is happening here is that an alarm is going off every 2 seconds, firing off a master thread, THREAD1. The master thread launches one of a number of remaining threads. The thread which is launched is identified on the LEDs.
RTXC FOR ARM and THUMB SPECIFIC - TECHNICAL NOTES:
All RTXC tasks must run in SVC32 mode. USER32 (or SYSTEM32) mode tasks are not supported. This means that main() must switch to SVC32 mode before beginning multitasking. The startup code calls main() in USER mode. . The main() function located in rtxcmain.c then calls EnterSVC() which switches to the SVC32 mode. See rtxcmain.c for more details.
The example application claims the SWI, FIQ and IRQ vectors. A set of direct vector manipulation routines, setvect() and getvect(), are provided in .\rtxc\source\kernel\setvect.c. In a minimal system, the FIQ can be left untouched and the SWI can be left for use by the debug monitor.
Caution: claiming the SWI (or UNDEF) vector by an application will generally render the debug port/monitor useless in a serial port-based C-Angel environment. SWI is used for debug/OS functions and UNDEF is used for breakpoints. It is for this reason that RTXC is usually entered via a direct subroutine call - not via SWI. JTAG (eg. Wiggler, Multi-ICE, and USB) environments however have been successful using SWI-based RTXC environments.
RTXC enables IRQ interrupts during kernel services. Users *CAN* enable IRQs during C level ISR routines that execute after the RTXC ISR prolog code executes and the generic IRQ handler, irqc(), is called. See IRQHandler logic in <root>\include\rtxcmac.inc for more details. The interrupt service logic (device recognition) is currently implemented in an IrqHandler() function found in <root>\Source\Drivers\<board>\irq.c.
FIQ interrupts must be handled completely outside the scope of the kernel. FIQ interrupts cannot call the kernel in any way. RTXC API routines, KS_ISRexit() and KS_ISRSignal(), called from FIQs are *NOT* supported by RTXC. As delivered, RTXC assumes that the FIQs are enabled at all times and *NEVER* masks the FIQ bits in PSR. Optionally, the RTXC kernel can mask the FIQ interrupt enable/disable bit. With this option defined, the kernel globally preserves the F bit status across modes and tasks. See the <root>\include\rtxcopts.h option TOTAL_FIQ_CONTROL for more details.
The initial USER32 stack is utilized by the SVC32 stack upon entering main(). This stack is used only by the main() thread which logically becomes the idle or null task (lowest priority task). Note, the startup code defines the SVC32 stack to be 256 bytes which should be sufficient for most main() tasks. If stack checking is on in the application, the SVC32 stack is set to a predefined stack area called "nulltaskstk". See .\rtxc\examples\apputil\rtxcmain.c for more details.
The IRQ32 stack is set to a predefined stack area called "irqstk". See \source\drivers\<board>\irq.c for more details.
The FIQ32 stack is set to a predefined stack area called "fiqstk". See \source\drivers\<board>\fiq.c for more details.
RTXC switches to a SVC32 stack during kernel calls and during interrupt servicing to allow for interrupt nesting. The variable KSTACKSIZE, configurable from RTXCgen, determines the kernel/interrupt stack depth. Default delivered size is 1024 bytes. This variable is #defined in kproject.h. See statistical information using Kernel Awareness for stack usage by task and by the kernel for tuning stack sizes (NB: Kernel Awareness not yet available for version 4.x of Embedded Workbench). A maximum of 5 levels of nesting have been realized with the example application with approximately 512 bytes of stack usage. The kernel stack requirements depend on the complexity of the handlers.
In general, 192 - 256 byte stacks are sufficient for most application tasks. Note - the use of sprintf-like functions will consume larger stacks.
The initial SVC32 stack is used only by the main() thread which logically becomes the idle or null task (lowest priority task). Therefore its stack size should fall in the stack size range for application tasks mentioned above.
Only 12 bytes (add 4 bytes for TOTAL_FIQ_CONTROL option) of the IRQ32 stack are ever used by RTXC or IRQ interrupts during runtime.
The UNDEF32 and FIQ32 stacks are also not used by RTXC.
ARM APCS REENTRANT MODEL SUPPORT:
The concept of ARM APCS reentrant model (with static base register) is not supported by RTXC. Note, Thumb mode does not support APCS reentrant. However, the RTXC API and other support routines are fully reentrant in the sense that multiple tasks can overlap execution as long as no static (shared) variables exist.
RTXC FOR ARM/THUMB KNOWN LIMITATIONS:
RTXC does not support 26-bit mode (-apcs 3/26bit). However, it will and has run successfully on ARM6.
RTXC and applications run in SVC32 mode only. USER32 mode is not supported. (For speed reasons.)
FIQ interrupts must run outside RTXC environment. (For speed reasons.)
RTXC does not support ARM APCS3 shared libraries. (Not needed.)