1 Microsoft's Azure RTOS ThreadX for Cortex-M3 2 3 Using the Green Hills Software Tools 4 51. Open the ThreadX Project Workspace 6 7In order to build the ThreadX library and the ThreadX demonstration first load 8the Azure RTOS Workspace azure_rtos_workspace.gpj, which is located inside the 9"example_build" directory. 10 11 122. Building the ThreadX run-time Library 13 14Building the ThreadX library is easy; simply select the MULTI project file 15tx.gpj and then select the build button. You should now observe the 16compilation and assembly of the ThreadX library. This project build produces 17the ThreadX library file tx.a. 18 19 203. Demonstration System 21 22The ThreadX demonstration is designed to execute under the MULTI environment 23on the Green Hills Cortex-M3 simulator. The instructions that follow describe 24how to get the ThreadX evaluation running under the MULTI Cortex-M3 simulation 25environment. 26 27Building the demonstration is easy; simply select the MULTI project file 28sample_threadx.gpj. At this point, select the "Project Build" button and observe 29the compilation, assembly, and linkage of the ThreadX demonstration application. 30 31After the demonstration is built, invoke the MULTI ARM simulator by selecting 32the simulator connection from within the sample_threadx.con connection file. 33Once connected to the simulator, select the "Debug" button. You should now 34observe the main function of sample_threadx.c. 35 36You are now ready to execute the ThreadX demonstration system. Select 37breakpoints and data watches to observe the execution of the sample_threadx.c 38application. 39 40 414. EventAnalyzer Demonstration 42 43To build a demonstration system that also logs events for the MULTI EventAnalyzer, 44perform the same steps as the regular demo, except build the ThreadX library with 45txe.gpj file and use the sample_threadx_el.gpj build file to build the demonstration. 46The resulting image will log all system events, which can then be displayed by the 47MULTI EventAnalyzer. 48 49 505. System Initialization 51 52The system entry point using the Green Hills tools is at the label _start. 53This is defined within the crt0.arm file supplied by Green Hills. In addition, 54this is where all static and global preset C variable initialization 55processing is called from. 56 57After the Green Hills startup function returns, ThreadX initialization is 58called. The main initialization function is _tx_initialize_low_level and 59is located in the file tx_initialize_low_level.arm. This function is responsible 60for setting up various system data structures, interrupt vectors, and the 61periodic timer interrupt source of ThreadX. 62 63In addition, _tx_initialize_low_level determines where the first available 64RAM memory address is located. This address is supplied to tx_application_define. 65 66By default, the first available RAM memory address is assumed to start at the 67beginning of the ThreadX section .free_mem. If changes are made to the 68sample_threadx.ld file, the .free_mem section should remain the last allocated 69section in the main RAM area. The starting address of this section is passed 70to tx_application_define. 71 72 736. Register Usage and Stack Frames 74 75The following defines the saved context stack frames for context switches 76that occur as a result of interrupt handling or from thread-level API calls. 77All suspended threads have the same stack frame in the Cortex-M3 version of 78ThreadX. The top of the suspended thread's stack is pointed to by 79tx_thread_stack_ptr in the associated thread control block TX_THREAD. 80 81 82 Stack Offset Stack Contents 83 84 0x00 r4 85 0x04 r5 86 0x08 r6 87 0x0C r7 88 0x10 r8 89 0x14 r9 90 0x18 r10 91 0x1C r11 92 0x20 r0 (Hardware stack starts here!!) 93 0x24 r1 94 0x28 r2 95 0x2C r3 96 0x30 r12 97 0x34 lr 98 0x38 pc 99 0x3C xPSR 100 101 1027. Improving Performance 103 104The distribution version of ThreadX is built without any compiler 105optimizations. This makes it easy to debug because you can trace or set 106breakpoints inside of ThreadX itself. Of course, this costs some 107performance. To make ThreadX run faster, you can change the tx.gpj project 108to disable debug information and enable the desired optimizations. 109 110In addition, you can eliminate the ThreadX basic API error checking by 111compiling your application code with the symbol TX_DISABLE_ERROR_CHECKING 112defined before tx_api.h is included. 113 114 1158. Interrupt Handling 116 117ThreadX provides complete and high-performance interrupt handling for Cortex-M3 118targets. There are a certain set of requirements that are defined in the 119following sub-sections: 120 121 1228.1 Vector Area 123 124The Cortex-M3 vectors start at the label __tx_vectors. The application may modify 125the vector area according to its needs. 126 127 1288.2 Managed Interrupts 129 130A ThreadX managed interrupt is defined below. By following these conventions, the 131application ISR is then allowed access to various ThreadX services from the ISR. 132Here is the standard template for managed ISRs in ThreadX: 133 134 135 .globl __tx_IntHandler 136__tx_IntHandler: 137 PUSH {lr} 138 BL _tx_thread_context_save 139 140 /* Do interrupt handler work here */ 141 142 B _tx_thread_context_restore 143 144 1459. Revision History 146 147For generic code revision information, please refer to the readme_threadx_generic.txt 148file, which is included in your distribution. The following details the revision 149information associated with this specific port of ThreadX: 150 15104-02-2021 Release 6.1.6 changes: 152 tx_port.h Updated macro definition 153 15403-02-2021 The following files were changed/added for version 6.1.5: 155 tx_thread_schedule.s Added low power feature 156 15705/19/2020 Initial ThreadX version of Cortex-M3/Green Hills port. 158 159 160Copyright(c) 1996-2020 Microsoft Corporation 161 162 163https://azure.com/rtos 164 165
