1 Microsoft's Azure RTOS ThreadX for Cortex-M4 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-M4 simulator. The instructions that follow describe 24how to get the ThreadX evaluation running under the MULTI Cortex-M4 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-M4 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 82Non-FPU Stack Frame: 83 84 Stack Offset Stack Contents 85 86 0x00 LR Interrupted LR (LR at time of PENDSV) 87 0x04 r4 Software stacked GP registers 88 0x08 r5 89 0x0C r6 90 0x10 r7 91 0x14 r8 92 0x18 r9 93 0x1C r10 94 0x20 r11 95 0x24 r0 Hardware stacked registers 96 0x28 r1 97 0x2C r2 98 0x30 r3 99 0x34 r12 100 0x38 lr 101 0x3C pc 102 0x40 xPSR 103 104FPU Stack Frame (only interrupted thread with FPU enabled): 105 106 Stack Offset Stack Contents 107 108 0x00 LR Interrupted LR (LR at time of PENDSV) 109 0x04 s16 Software stacked FPU registers 110 0x08 s17 111 0x0C s18 112 0x10 s19 113 0x14 s20 114 0x18 s21 115 0x1C s22 116 0x20 s23 117 0x24 s24 118 0x28 s25 119 0x2C s26 120 0x30 s27 121 0x34 s28 122 0x38 s29 123 0x3C s30 124 0x40 s31 125 0x44 r4 Software stacked registers 126 0x48 r5 127 0x4C r6 128 0x50 r7 129 0x54 r8 130 0x58 r9 131 0x5C r10 132 0x60 r11 133 0x64 r0 Hardware stacked registers 134 0x68 r1 135 0x6C r2 136 0x70 r3 137 0x74 r12 138 0x78 lr 139 0x7C pc 140 0x80 xPSR 141 0x84 s0 Hardware stacked FPU registers 142 0x88 s1 143 0x8C s2 144 0x90 s3 145 0x94 s4 146 0x98 s5 147 0x9C s6 148 0xA0 s7 149 0xA4 s8 150 0xA8 s9 151 0xAC s10 152 0xB0 s11 153 0xB4 s12 154 0xB8 s13 155 0xBC s14 156 0xC0 s15 157 0xC4 fpscr 158 159 1607. Improving Performance 161 162The distribution version of ThreadX is built without any compiler 163optimizations. This makes it easy to debug because you can trace or set 164breakpoints inside of ThreadX itself. Of course, this costs some 165performance. To make ThreadX run faster, you can change the tx.gpj project 166to disable debug information and enable the desired optimizations. 167 168In addition, you can eliminate the ThreadX basic API error checking by 169compiling your application code with the symbol TX_DISABLE_ERROR_CHECKING 170defined before tx_api.h is included. 171 172 1738. Interrupt Handling 174 175ThreadX provides complete and high-performance interrupt handling for Cortex-M4 176targets. There are a certain set of requirements that are defined in the 177following sub-sections: 178 179 1808.1 Vector Area 181 182The Cortex-M4 vectors start at the label __tx_vectors. The application may modify 183the vector area according to its needs. 184 185 1868.2 Managed Interrupts 187 188A ThreadX managed interrupt is defined below. By following these conventions, the 189application ISR is then allowed access to various ThreadX services from the ISR. 190Here is the standard template for managed ISRs in ThreadX: 191 192 193 .globl __tx_IntHandler 194__tx_IntHandler: 195 PUSH {lr} 196 BL _tx_thread_context_save 197 198 /* Do interrupt handler work here */ 199 200 B _tx_thread_context_restore 201 202 2039. FPU Support 204 205By default, FPU support is disabled for each thread. If saving the context of the FPU registers 206is needed, the ThreadX library should be re-built with TX_ENABLE_FPU_SUPPORT defined. In addition, 207the following API call must be made from the context of the application thread - before 208the FPU usage: 209 210void tx_thread_fpu_enable(void); 211 212After this API is called in the application, FPU registers will be saved/restored for this thread if it 213is preempted via an interrupt. All other suspension of the this thread will not require the FPU registers 214to be saved/restored. 215 216To disable FPU register context saving, simply call the following API: 217 218void tx_thread_fpu_disable(void); 219 220 221 22210. Revision History 223 224For generic code revision information, please refer to the readme_threadx_generic.txt 225file, which is included in your distribution. The following details the revision 226information associated with this specific port of ThreadX: 227 22804-02-2021 Release 6.1.6 changes: 229 tx_port.h Updated macro definition 230 23103-02-2021 The following files were changed/added for version 6.1.5: 232 tx_thread_schedule.s Added low power feature 233 23405/19/2020 Initial ThreadX version of Cortex-M4/Green Hills port. 235 236 237Copyright(c) 1996-2020 Microsoft Corporation 238 239 240https://azure.com/rtos 241 242
