uC/OS-II and the Cogent CSB337 - pudn.comread.pudn.com/downloads64/sourcecode/others/227959/Micrium/... · µC/OS-II and the Cogent CSB337 Figure 2-1, The Atmel AT91RM9200 Block Diagram

Micriµm, Inc. © Copyright 2003, Micriµm, Inc.

All Rights reserved

µC/OS-II

and The Cogent CSB337

Application Note

AN-1337

www.Micrium.com

http://www.micrium.com/

µC/OS-II and the Cogent CSB337

Table of Contents 1.Introduction .................................................................................................................. 3 2.Hardware environment ................................................................................................. 3

2.1. The Atmel AT91RM9200 microcontroller ................................................... 3 2.2. The Cogent CSB337 development board .................................................. 5 2.3. The Cogent CSB300 base board............................................................... 6 2.4. JTAG debugger ......................................................................................... 7

3.Software environment .................................................................................................. 8

3.1. Setup your development environment ....................................................... 8 3.2. GNU X-Tools ............................................................................................. 8

4.CBS337 port of µC/OS-II............................................................................................ 11

4.1. Directories and files ................................................................................. 11 4.2. Port files................................................................................................... 12 4.3. Configuration files .................................................................................... 13

5.Example application ................................................................................................... 14

5.1. APP.C...................................................................................................... 14 5.2. Micromonitor (µMon)................................................................................ 16

6.Handling interrupts ..................................................................................................... 17 7.Building and running example code ........................................................................... 18 8.Conclusion ................................................................................................................. 20

2


1. Introduction This application note describes the Micriµm port of µC/OS-II v2.70 for the Cogent CSB337 single-board computer. This development platform is based on the Atmel AT91RM9200 microcontroller, an implementation of the ARM 920T core. The example code is built using MicroCross Visual X-Tools 1.0 and MicrosCross GNU X-Tools 3.0.

2. Hardware environment

2.1. The Atmel AT91RM9200 microcontroller The Atmel AT91RM9200 microcontroller provides the following features: • Incorporates the ARM920T™ ARM® Thumb® Processor

o 200 MIPS at 180 MHz o 16-KByte Data Cache, 16-KByte Instruction Cache, Write Buffer o Memory Management Unit o In-circuit Emulator including Debug Communication Channel o Mid-level Implementation Embedded Trace Macrocell

• Additional Embedded Memories o 16K Bytes of SRAM and 128K Bytes of ROM

• External Bus Interface (EBI) o Supports SDRAM, Static Memory, Burst Flash, Glueless Connection to CompactFlash®,

SmartMedia™ and NAND Flash • System Peripherals:

o Enhanced Clock Generator and Power Management Controller o Two On-chip Oscillators with Two PLLs o Very Slow Clock Operating Mode and Software Power Optimization o Capabilities o Four Programmable External Clock Signals o System Timer Including Periodic Interrupt, Watchdog and Second Counter o Real-time Clock with Alarm Interrupt o Debug Unit, Two-wire UART and Support for Debug Communication Channel o Advanced Interrupt Controller with 8-level Priority, Individually Maskable o Vectored Interrupt Sources, Spurious Interrupt Protected o Seven External Interrupt Sources and One Fast Interrupt Source o Four 32-bit PIO Controllers with Up to 122 Programmable I/O Lines, Input o Change Interrupt and Open-drain Capability on Each Line o 20-channel Peripheral Data Controller (DMA)

• Ethernet MAC 10/100 Base-T • USB 2.0 Full Speed (12 M-bits per second) Host Double Port and Device Port • Multimedia Card Interface (MCI) • Three Synchronous Serial Controllers (SSC) • Four Universal Synchronous/Asynchronous Receiver/Transmitters (USART) • Master/Slave Serial Peripheral Interface (SPI) • Two 3-channel, 16-bit Timer/Counters (TC) • Two-wire Interface (TWI) • IEEE 1149.1 JTAG Boundary Scan on All Digital Pins

3


Figure 2-1, The Atmel AT91RM9200 Block Diagram We tested the port for the Atmel AT91RM9200 running in ARM mode with the CSB337 evaluation board which is available from Cogent. A diagram of the board is shown in figure 2-2.

4


2.2. The Cogent CSB337 development board The Cogent CSB337 development board is a complete microcomputer by itself. It plugs into a CSB300 base board which provides interface, communication and power ports. The Cogent CSB337 provides the following features:

Core 180Mhz ARM920T, 16K I-Cache, 16K D-Cache SDRAM 32Mbyte 32-Bit Wide SDRAM FLASH 8Mbyte 16-Bit Wide StrataFLASH NAND FLASH Secure Digital Card via 4-Bit SDIO Controller

LCD Controller Epson S1D13706 with 80KByte SRAM supports up to 320x240 TFT, HR-TFT and STN Displays

USB V1.1 Device Port - Two USB V1.1 Host ports available via GPIO Expansion Connector

Serial RS232 x 2, Master/Slave SPI x 1 - Two additional UARTS (TTL only) available via the GPIO Expansion Connector

CAN Infineon SAK82C900 Dual CAN Controller via SPI Ethernet On-Chip 10/100 Mbit Controller with DMA Real Time Clock Dallas DS1307 or DS1338 With Battery Bus Expansion Full CPU Bus and GPIO available via 40-Pin stackable headers Audio I2S Interface via GPIO Expansion Connector (requires external Codec)

Compact Flash Compact Flash Interface via GPIO, Address and Data Bus Expansion Connectors (Compatible with CSB301 Compact Flash Socket)

JTAG 20-Pin Header (Abatron BDI2000, Macraigor OCDemon and Nohau EMUL-ARM compatible)

Embedded Trace 38-Pin, High-Speed, Embedded Trace Module Connector, 16-Bit (Nohau EMUL-ARM compatible)

Figure 2-2, The Cogent CSB337 Block Diagram

5

http://www.dalsemi.com/

http://www.dalsemi.com/


2.3. The Cogent CSB300 base board The Cogent CSB300 converts any CSB3xx CPU Module into a stand alone development board. The Cogent CSB300 provides the following features: RS-232 Dual DB9 Male Connectors USB USB Type B Connector CAN Dual DB9 Male Connectors Ethernet RJ45 Connector with Speed (Green) and Link/Activity (Yellow) LED’s LED’s 3 User LED’s, 1 Power LED Switches 3 Pushbutton Switches Power 5V Only Connection with 3A Polyfuse

Figure 2-3, The CSB300 Block Diagram

Figure 2-4, The CSB337 Figure 2-5, The CSB300

6


2.4. JTAG debugger We used the Macraigor Raven (see Figure 2.6) which is a JTAG debugger and connects directly to the CSB337’s 20-pin ARM JTAG interface. The Raven also connects to the parallel port of the Windows PC and allows the Visual GDB debugger (provided with the MicroCross toolchain) access to the Atmel AT91RM9200’s CPU on the CSB337. Visual GDB doesn’t support directly Raven JTAG debuggers. Macraigor distribute an adaptation layer, OCDLibRemote that enables communication between Visual GDB using a Remote/TCP connection and the JTAG debugger. See section 3.1 for more details about GDB and JTAG configuration.

Figure 2.6, Macraigor’s Raven

www.Macraigor.com

7

http://www.macraigor.com/


3. Software environment

3.1. Setup your development environment Here are some steps to successfully setup your development environment for working on the Cogent CSB337.

• Install Visual X-Tools and Cygwin (if you are in Windows environment) • Install GNU X-Tools, arm-elf and arm-elf-gdbtk targets. We strongly recommend installing GNU

X-Tools 3.0. Detailed installation instructions are on a file named README.rtf in the root path of the CD. Warning: Installation of Visual X-Tools and GNU X-Tools 3.0 may take up to 1.6GBytes on your hard disk.

• Install OCDLibRemote. OCDLibRemote is an adaptation layer between GDB and the JTAG debugger. Download it from: www.ocdemon.com. OCDLibRemote installs itself in the Cygwin path.

• You may need OCD Commander to run OCDLibRemote. OCD Commander is a free OEM debugger from Macraigor. Download it from the Macraigor web site: Click Here.

• Unzip the µC/OS-II port for CSB337 zip file from Micriµm. Use the version 2.70 or better. Files should be unzipped in D:\ to create D:\Micrium\Software\... tree. If your D:\ drive is not a harddrive, choose C:\.

• Unpack your CSB337 and CSB300 boards. Insert the CSB337 carefully into the CSB300. • Unpack your Macraigor JTAG, power supplies, parallel and serial cables. • Plug the JTAG flat-cable into the CSB337. • Plug the parallel cable to the JTAG and then to your PC. Use a straight DB25 male-female cable. • Plug the serial cable to the CSB300 (serial 0) and then to your PC. Use a null-modem DB9

female-female cable. • Plug the power to the JTAG, then to the CSB300. The “power” led of the JTAG should be on.

The power LED of the CSB300 should be on. • ALWAYS remove power to the CSB300 BEFORE plugging or unplugging the JTAG header.

3.2. GNU X-Tools GNU X-Tools are the MicroCross’ distribution of standard GNU tools (C compiler, assembler, linker, locator, debugger). MicroCross distributes the GNU toolchain for about 20 target architectures. In this application note, we use the arm-elf distribution. GNU tools are an open source project from the Free Software Foundation (FSF). Modification and distribution of the GNU tools source code is governed by the General Public License (GPL). The GPL says that you can modify the source code of the tools and rebuild them, but modifications remain the property of the FSF. Of course, the executables made with GNU tools from your code are yours. Also, you should read the Lesser General Public License (LGPL) which applies on some standard librairies. Tools settings (C Compiler, Assembler, Linker and Debugger) A workspace file (Project.vxw) and project file (Project.vxp) are provided in the sample code. Project.vxp contains compiler, assembler, linker and debugger settings as explained in section 3.4.

8

http://www.ocdemon.com/

http://www.ocdemon.net/Merchant2/merchant.mv?Screen=CTGY&Store_Code=MTS&Category_Code=FS


Figure 3-1, Project Tree Two script files, debug-gdb and debug-gdbtk are provided with the example code to start the OCDLibRemote adaptation layer before GDB of Visual GDB. A GDB script file is also provided to connect automatically to the CSB337 via the JTAG. The script also download the object code and execute startup code until main(). In the Project Properties / Tool, we have replaced the command line for Visual GDB to call the debug-gdbtk script.

Figure 3-2, Tools Options

9


To have the project correctly executed into the CSB337 memory, we have modified the default linker script to create a new one, RAM.lds. The linker script is a language that controls the format and organization of the final executable file. The default ARM startup files have been disabled because they are built to use the ARM Angel Monitor instead of the Micromonitor (µMon) distributed with the Cogent boards.

Figure 3-3, Linker options

10


4. CBS337 port of µC/OS-II

4.1. Directories and files The code and documentation of the port are placed in a directory structure according to “AN-2002, µC/OS-II Directory Structure”. Specifically, the files are placed in the following directories: \Micrium\Software\uCOS-II\Source

This directory contains the processor independent code for µC/OS-II. The version used is 2.70 or better.

\Micrium\Software\uCOS-II\Ports\ARM9

This directory is the main directory for GNU ports for ARM9 processors. \Micrium\Software\uCOS-II\Ports\ARM9\AT91RM9200\ARM\GNU-XTools

This directory is the main directory for the GNU port using GNU-XTools and for the AT91RM9200, an ARM9 compatible processor. The ‘ARM’ directory specifies that the port assumes ARM mode as opposed to Thumb mode.

\Micrium\Software\uCOS-II\Ports\ARM9\AT91RM9200\ARM\GNU-XTools\Source

This directory contains the standard processor specific files for a µC/OS-II port. Specifically, this directory contains the following files: os_cpu.h os_cpu_a.s os_cpu_c.c os_dbg_GNU.c Although not needed, os_dbg.c is included for completeness. Note that os_cpu.c was added in V2.6x to support kernel aware debuggers.

\Micrium\Software\CPU\Atmel\AT91RM9200 This directory contains the AT91RM9200 microcontroller specific definition files. These files were provided by Cogent.

\Micrium\Software\EvalBoards\Cogent\CSB337\GNU-XTools\OS\Ex1 This directory is the directory that contains the source code for Example #1 running on a CSB337 board. This directory contains: .gdbinit app.c bsp.c bsp.h bsp_a.s debug_gdb.cmd debug_gdbtk.cmd includes.h os_cfg.h Project.* RAM.lds

\Micrium\Software\EvalBoards\Cogent\CSB337\GNU-XTools\OS\Ex1\Micromonitor This directory is the directory that contains the micromonitor API source. Micromonitor is a resident monitor that comes with the CSB337 board.

\Micrium\Software\EvalBoards\Cogent\CSB337\GNU-XTools\OS\Doc

This directory is the directory that contains the documentation for the CSB337 port using the MicroCross GNU XTools.

11


4.2. Port files OS_CPU.H OS_CPU.H contains processor and implementation specific #defines constants, macros, and typedefs. This file is identical to the os_cpu.h provided as part of AN-1011 (the Micriµm version of the ARM7 port). OS_CPU.C os_cpu_c.c contains processor specific functions. This file is identical to the os_cpu_c.c provided as part of AN-1011, except that for OSTaskStkInit(), we force the task address to be on an even boundary. Listing 4-1, OS_CPU_C.C, OSTaskStkInit() OS_STK *OSTaskStkInit (void (*task)(void *pd), void *pdata, OS_STK *ptos, INT16U opt) { OS_STK *stk; opt = opt; /* 'opt' is not used, prevent warning */ stk = ptos; /* Load stack pointer */ *(--stk) = ((INT32U)task & ~0x01); /* PC */ *(--stk) = (INT32U)0x14141414L; /* LR */ *(--stk) = (INT32U)0x12121212L; /* R12 */ *(--stk) = (INT32U)0x11111111L; /* R11 */ *(--stk) = (INT32U)0x10101010L; /* R10 */ *(--stk) = (INT32U)0x09090909L; /* R9 */ *(--stk) = (INT32U)0x08080808L; /* R8 */ *(--stk) = (INT32U)0x07070707L; /* R7 */ *(--stk) = (INT32U)0x06060606L; /* R6 */ *(--stk) = (INT32U)0x05050505L; /* R5 */ *(--stk) = (INT32U)0x04040404L; /* R4 */ *(--stk) = (INT32U)0x03030303L; /* R3 */ *(--stk) = (INT32U)0x02020202L; /* R2 */ *(--stk) = (INT32U)0x01010101L; /* R1 */ *(--stk) = (INT32U)p_arg; /* R0 : argument */ *(--stk) = (INT32U)ARM_SVC_MODE; /* CPSR (Enable both IRQ and FIQ interrupts) *(--stk) = (INT32U)ARM_SVC_MODE; /* SPSR return (stk); }

OS_CPU_A.S and OS_DBG.C These files have been converted to work with the GNU tools, but the functionality remains the same as their equivalent files (os_cpu_a.s and os_dbg.c) provided in AN-1011.

12


4.3. Configuration files BSP*.* BSP stands for Board Support Package and Micrium places ‘services’ that the board provides in such a file. In our case, bsp.c contains I/O and timer initialization code, LED control code, switches control code and code to initialize the micromonitor API. All board I/Os are initialized when BSP_Init() is called. BSP_Init() is responsible for setting up the CPU, I/O ports Timers, AIC (Advanced Interrupt Controller), etc. BSP_Init() doesn’t do all the work directly but calls other initialization functions as required. The concept of a BSP is to hide the hardware details from the application code. It is important that functions in a BSP reflect the function and does not make references to any CPU specifics. For example, the code to turn on an LED is called LED_On() and not csb337_led(). If you use LED_On() in your code, you can easily port your code to another processor simply by rewriting LED_On() to control the LEDs on another board. The same is true for other services. You will also notice that BSP functions are prefixed with the function’s group. LED services start with LED_, Timer services start with Tmr_, etc. .gdbinit .gdbinit is the GDB and GDBTK startup script file. In our case, the script initializes communication with the CSB337 board via the OCDLibRemote adaptation layer and the JTAG. It also loads the code and execute until main(). debug_gdb.cmd and debug_gbdtk.cmd These files enable starting the OCDLibRemote adaptation layer before GDB or GDBTK. Project setting are modified to use them. Project.* These are the project files for Visual X-Tools. RAM.lds This is the linker script. It is very similar to the GNU default. We have modified the entry point and the startup address to reflect the memory mapping of the CSB337.

13


5. Example application

5.1. APP.C APP.C contains test code that runs on the CSB337. The two important functions are main() (listing 5-1) and AppStartTask() (listing 5-2). Listing 5-1, main() int main (void) { INT8U err; BSP_Init(); /* Initialize CSB337 BSP */ mon_printf("\r\nInitialize uC/OS-II..."); OSInit(); /* Initialize uC/OS-II */ /* Create start task */ OSTaskCreateExt(AppStartTask, NULL, (OS_STK *)&AppStartTaskStk[TASK_STK_SIZE - 1], TASK_START_APP_PRIO, TASK_START_APP_PRIO, (OS_STK *)&AppStartTaskStk[0], TASK_STK_SIZE, NULL, OS_TASK_OPT_STK_CHK | OS_TASK_OPT_STK_CLR); /* Give a name to tasks */ #if OS_TASK_NAME_SIZE > 10 OSTaskNameSet(OS_IDLE_PRIO, "Idle task", &err); OSTaskNameSet(OS_STAT_PRIO, "Stat task", &err); OSTaskNameSet(TASK_START_APP_PRIO, "Start task", &err); #endif mon_printf("\r\nStart uC/OS-II..."); OSStart(); /* Start uC/OS-II */ } BSP_Init() is called to initialize the processor, interrupt controller and other hardware. LEDs are turned off. OSInit() is called to initialize µC/OS-II. OSInit() must be called before you can actually use any of the other services (i.e. functions) provided by µC/OS-II. OSTaskCreateExt() creates a single application task called AppStartTask(). This task will be described later. OSTaskNameSet() allows us to assign a name to each task in the application. Names can only be assigned to tasks that have been created with OSTaskCreateExt(). OSStart() is called to give control to µC/OS-II and start multitasking. OSStart() finds the highest priority task of all the tasks created (in this case, it’s AppStartTask()) and starts executing that task.

14


Listing 5-2, AppStartTask() static void AppStartTask (void *p_arg) { p_arg = p_arg; /* Prevent compiler warning */ mon_printf("\r\nStart timer tick..."); Tmr_TickInit(); /* Start timer tick */ #if OS_TASK_STAT_EN > 0 mon_printf("\r\nStart statistics..."); OSStatInit(); /* Start stats task */ #endif OSTaskCreate(AppTask1, (void *)0, (void *)&AppTask1Stk[TASK_STK_SIZE],TASK_APP_1_PRIO); OSTaskCreate(AppTask2, (void *)0, (void *)&AppTask2Stk[TASK_STK_SIZE],TASK_APP_2_PRIO); mon_printf("\r\nStarting uC/OS-II demo...\n"); mon_printf("Press user switch 0 to toggle between the two tasks\n"); mon_printf("Task 1 : Green LED\n"); AppTask1LedStatus = 1; AppTask2LedStatus = 0; Switch0Pressed = 0; TaskSelected = 1; while (TRUE) { /* Task body, always written as an infinite loop.*/ if (GetPushButtonStatus(1)) { /* Switch pressed */ if (Switch0Pressed == 0) { Switch0Pressed = 1; /* Record switch change of status*/ switch (TaskSelected) { case 1: TaskSelected = 2; LED_Off(2); /* Turn off LED 1 */ mon_printf("Task 2 : Yellow LED\n"); break; case 2: TaskSelected = 1; LED_Off(3); /* Turn off LED 2 */ mon_printf("Task 1 : Green LED\n"); break; } } } else { /* Switch unpressed */ if (Switch0Pressed == 1) { Switch0Pressed = 0; /* Record switch change of status*/ } } /* Delay task execution for 250 ms*/ OSTimeDly(250 * OS_TICKS_PER_SEC / 1000); } } Tmr_TickInit() is called to start generation of an interrupt every 10 milliseconds. If you enabled OS_TASK_STAT_EN (i.e. set to 1) in os_cfg.h, µC/OS-II’s statistic task will be initialized and µC/OS-II will obtain some information about the processor. Two new tasks are created. Each task blink one LED (Light Emitting Diode) depending on the value of TaskSelected. AppTask1() blinks the green LED and AppTask2() blinks the orange LED.

15


We then enter an infinite loop waiting for someone to press the button #0 switch. When this event occurs, TaskSelected changes value, and the blinking LED also changes.

5.2. Micromonitor (µMon) µMon is a public domain resident monitor written by Mr. Ed Sutter. This monitor provides many functions usable by your application like a library. To use µMon in your application, you must, first, ensure you will not overwrite µMon when you will load your code. The example application loads itself at 0x20020000, leaving 128Kb of RAM for µMon. Then, you must call an initialization routine of µMon. To do this, you have to know the entry point of µMon (called «well known address»). To obtain this «well known address», enter the command «mstat» at the µMon prompt. You will have an output that looks like this:

uMON>mstat MICRO MONITOR CPU: AT91RM9200 ARM920T Platform: Cogent CSB337 - AT91RM9200 SBC Built: Sep_24,2003 @ 10:34:07 Monitor RAM: 0x20000000-0x2001a044 Application RAM Base: 0x20100000 MAC: 00:23:31:37:00:49 IP: 192.168.254.111 Ptrs: moncom: 0x10000050, etheradd: 0x10000038, ipadd: 0x10000020 App-assigned functions... getchar: 0x0 putchar: 0x0 dcacheFlush: 0x0 icacheInvalidate: 0x0 Current: SP: 0x20015da0 CPSR: 0x600000d3 Monitor STATE: 48 uMON>

Listing 5-3, MSTAT command output from micromonitor

The µMon entry point is the address following «Ptrs: moncom:». In bsp.c, you will see a call to µMon’s initialization routine at line 92. After this call to monConnect, you can use the µMon API in your application. Warning: The example code does not provide reentrancy protection for µMon. You must provide your own if needed.

16


6. Handling interrupts The ARM contains an interrupt vector table (IVT) starting at address 0x0000,0000 (note that the comma separating the hexadecimal number DOES NOT represent a fraction but is used to make the 32-bit number easier to read). There are only seven (7) entries in the interrupt vector table. Each entry has enough room to hold a single 32-bit instruction. The instruction placed in the IVT is generally a branch instruction with a signed 26-bit destination address. In other words, the ARM can branch to an address that is roughly +/- 0x0020,0000 from the vector location. The code that you branch to has to determine the interrupt source because there is only one address for all devices that can interrupt the ARM. The interrupt vector table for the ARM is shown in table 6-1:

Exception Mode Vector Address Reset SVC 0x0000,0000

Undefined Instruction UND 0x0000,0004 Software Interrupt (SWI) SVC 0x0000,0008

Prefetch abort Abort 0x0000,000C Data abort Abort 0x0000,0010

- - 0x0000,0014 IRQ (Normal Interrupt) IRQ 0x0000,0018

FIQ (Fast Interrupt) FIQ 0x0000,001C

Table 6-1, ARM Interrupt Vector Table Some ARM implementations such as the Atmel AT91RM9200 actually contain a ‘smart’ interrupt controller that supplies a vector (i.e. an address) for each interrupt source. This allows the proper interrupt handler to be called directly instead of having to figure out (through code) what the actual source of the interrupt was. The IVT entries for both the IRQ and FIQ (assuming the AT91RM9200) are shown in the code below. The interrupt controller (called the AIC) on the AT91RM9200 is mapped in high memory and contains 2 registers that indicate what the current interrupt is (if any) asserting the IRQ (or FIQ) line. In fact, those registers contain the address of the ISR associated with each interrupt source. The code below simply loads the PC with the address of the ISR and thus causes a direct branch to the corresponding ISR. Of course, other interrupt controllers (if any) may work differently so you will have to consult the documentation for the processor you are actually using. To correctly handle timer interrupts for the clock tick, bsp.c initialize the AIC. First, in bsp.c, line 88, you will see: AT91C_MC_RCR = 1; /* Remap SRAM to 0x00000000 */

This line maps SRAM to 0x0000,0000. By default, the FLASH is mapped at this address. This modification of the memory map allows us to modify the IRQ vector. Second, in bsp.c, line 112, you will see:

/* 0xE51FFF20L is opcode of (ldr pc,[pc,#-0xf20]) */ *(INT32U *)0x00000018L = 0xE51FFF20L; /* IRQ exception vector - install redirection to AIC */

This line place the assembly instruction « ldr pc,[pc,#-0xf20] » at address 0x0000,0018. When an IRQ occurs, the CPU executes this instruction, loading PC with the interrupt handler provided by the AIC. To add a new interrupt handler, you should inspire yourself from OS_CPU_Tick_ISR(), the timer tick handler and function Tmr_TickInit() in bsp.c which installs this handler.

17


7. Building and running example code To load the project files, start Visual X-Tools. In project menu, choose “Open Workspace”, then select “Project.vxw”. To build the project, select “build” in the “build” menu. You will find here all the standard commands for building and debugging. To debug your project, select “Debug with GDB” or “Debug with Visual GDB” in the “build” menu. Remember, we have modified the default invocation of GDB and Visual GDB to use a script which starts OCDLibRemote, the GDB adaptation layer, before starting GDB or Visual GDB. Then, the script .gdbinit will connect, download the object file into the CSB337 and execute until you reach main(). If you use Visual GDB, you will see this dialog box:

Figure 7-1, Visual GDB connection dialog Always answer “yes”. This enable faster downloads. If you use Visual GDB, never use any commands in the “run” menu. The .gdbinit script does all the work. If you use any of the command, OCDLibRemote will disconnect and the debugging session will stop.

Figure 7-2, Visual GDB debugging session

18


To execute your project without a JTAG interface, first ensure that the CSB337 TCP/IP configuration is correctly configured for your environment. Use the “dhcp” command if needed. Second, open a DOS command window, and enter the following commands:

Then, return to µMon prompt and enter: call 0x20020000. The example should start. What have done done? First, we have converted the executable file “Project.x” which is in ELF format to a flat binary format with the tool objcopy. Then, using the tftp server feature of µMon, we sent the binary file to the CSB337 directly in RAM at the load address. Finally, we jumped to the program entry point, 0x20020000. To get the load address of your application, see your linker script. The example is linked to be loaded at 0x20020000. To get the entry point, use the command arm-elf-objdump –f <elf_file>. The example entry point is 0x20020000.

19


8. Conclusion This application note presented a port for the ARM processor using the MicroCross Visual XTools. The port should be easily adapted to different compilers (the code itself should be identical). Of course, if you use µC/OS-II and use the port on actual hardware, you will need to initialize and properly handle hardware interrupts.

20


References µC/OS-II, The Real-Time Kernel, 2nd Edition Jean J. Labrosse CMP Technical Books, 2002 ISBN 1-5782-0103-9

Contacts Cogent Computer Systems, Inc. 1130 Ten Rod Road, Suite A-201 North Kingstown, RI 02852 USA USA +1 401 295 6505 +1 401 295 6507 (Fax) WEB: www.CogComp.com Micriµm, Inc. 949 Crestview Circle Weston, FL 33327 USA +1 954 217 2036 +1 954 217 2037 (FAX) WEB: www.Micrium.come-mail: [email protected] CMP Books, Inc. 1601 W. 23rd St., Suite 200 Lawrence, KS 66046-9950 USA +1 785 841 1631 +1 785 841 2624 (FAX) WEB: http://www.rdbooks.come-mail: [email protected]

Microcross, Inc. 151 Osigian Blvd., Suite 154 Warner Robins, GA 31088 USA +1 478 953 1907 +1 478 953 7661 (Fax) WEB: http://www.MicroCross.com

21

http://www.cogcomp.com/

http://www.micrium.com/

mailto:[email protected]

http://www.rdbooks.com/

mailto:[email protected]

http://www.microcross.com/

Documents

uC/OS-II and the Cogent CSB337 - pudn.comread.pudn.com/downloads64/sourcecode/others/227959/Micrium/... · µC/OS-II and the Cogent CSB337 Figure 2-1, The Atmel AT91RM9200 Block Diagram