Advanced ARM Programming Part 3: Bare Metal Hardware Control Methods and Routines

So far, we have been able to write more complex ARM assembly programs. Unfortunately, these programs are run on the virtual development board ARMUL that comes with ads. (In the axd interface, click options->configure target, and you can see the target board configuration interface as follows)

Our ultimate goal is to make the program run on actual hardware products and control the hardware. This article will initially introduce how to establish a development and debugging environment for real hardware and how to write programs to control the hardware.

Part 1: How to set up a real hardware development and debugging environment

Since there are many types of embedded development boards based on ARM, there are also many types of hardware emulators and debugging agent software, and the methods of use are different, which makes it difficult to learn to write ARM bare metal programs to control hardware. In order to facilitate beginners to get started quickly, it is necessary to choose a mature, easy-to-learn and practice software and hardware environment. After comparison, this article (including all articles related to ARM hardware in this series) uses the qq2440 (or mini2440) embedded development board with NOR flash (with a simple JTAG debugging emulator board) and h-jtag debugger agent software provided by Friendly Arm. The following construction of the development and debugging environment is all from the qq2440 user manual provided by Friendly Arm (slightly modified), and I would like to express my respect here.

1. Install and set up H-JTAG

(1) Install H-JTAG

The H-JTAG installation file is located in the "Windows Platform Tools\H-JTAG" directory. Double-click it to run and follow the prompts to install it.

After the installation is complete, H-JTAG and H-Flasher shortcuts will be generated on the desktop. Double-click to run H-JTAG. The program will automatically detect whether the JTAG device is connected. Because we have not made any settings before, a prompt window will pop up:

Click OK to enter the main interface of the program. Since no target device is connected, the display is as shown below:

(2) Set up the JTAG port

In the menu of the H-JTAG main interface, click Setting->Jtag Settings, make the settings as shown below, and click OK to return to the main interface.

(3) Set up the initialization script

Copy the qq2440_yangzhu.his and H-Flasher_QQ2440_yangzhu.hfc files ( click to download ) provided in this article to the installation directory of H-JTAG, as shown in the figure:

Note: Please consider FriendlyARM2440.his in the subsequent figures and documents as qq2440_yangzhu.his, and H-Flasher_QQ2440.hfc as H-Flasher_QQ2440_yangzhu.hfc

In the main interface of H-JTAG, click Script->Init Script, the Init Script window will pop up, click the Load button below the window, find and open the FriendlyARM2440.his file just copied, as shown in the figure:

At this time, the Init Script window will be filled with the loaded script, as shown in the figure. Note that you must click "Enable Auto Init".

Click OK to return to the H-JTAG main interface:

(4) Detection of target device

Use the JTAG board attached to the development board to connect to the JTAG interface of the development board, and then turn on the power. Click Operations->Detect Target in the main menu, or click the corresponding icon in the toolbar, and you can see that the target device has been detected.

Tip: If the initialization script is not set, the CPU can be detected, but the following single-step debugging cannot be performed.

(5) Set up automatic download of programs to NOR flash

Click Flasher and select "Auto Download"

2. Configure AXD DEBUGGER for H-JTAG

(1) Run AXD Debugger

As shown in the figure, open the debugging software - AXD Debugger which runs the ADS1.2 software:

AXD Debugger main interface:

(2) Setting up AXD Debugger

Click the menu Options->Configuration Target…, and the following window will appear:

Click the Add button in this window, a file selection dialog box pops up, find the H-JTAG installation directory, select and open the H-JTAG.dll file in it, as shown in the figure.

At this time, there will be an additional H-JTAG item in the Choose Target window, as shown in the figure. Click OK to return to the AXD Debugger main interface.

(3) Use H-JTAG to perform simulation debugging in ADS1.2 environment

Close AXD Debugger. Click the menu Project->Debug in CodeWarrior, it will automatically start AXD Debugger, AXD Debugger will start the target image, and download it to the target board through Jtag. At this time, the status bar at the bottom of AXD Debugger will show the download process prompt. After the download is completed, you can perform single-step or full-speed debugging. During the debugging process, you can see the values ​​of each CPU register and set breakpoints. For detailed usage, please refer to the English manual attached to ADS, which is basically similar to common integrated development environments such as VisualC++.

Part 2: Writing methods and routines to control bare metal hardware

1. Programming principles of program-controlled hardware

Each type of hardware will have physical registers on its controller chip (note that the registers here do not refer to the register R1 inside the CPU, etc., but to the storage units on the hardware chip. Under the ARM system, these storage units are uniformly addressed with the memory and can be accessed by the CPU through memory access instructions, just like accessing memory). These registers are usually divided into three types: command registers, status registers, and data registers. The way the program controls the hardware is usually: the program writes appropriate content to the command register through the str instruction, which can complete the operation of configuring the hardware or require the hardware to perform some physical operation. So far, the software has completed all it should do, and then the hardware will automatically complete the corresponding operation. After the hardware completes the operation, the program can obtain the desired data from the data register through the ldr instruction, or obtain the status of the hardware from the status register. It can be seen that program control of hardware, in simple terms, is actually the program reading and writing operations on the hardware registers, commanding the hardware to complete the operation, and obtaining the hardware status and data, that's all. The key here is: what is the memory address of a certain hardware register? In order for the hardware to perform a certain operation, what value should be written to which register? These are all problems that programmers need to solve, and the key to solving these problems is that programmers can: a) understand the operating mechanism of the hardware to be controlled; b) be proficient in consulting the hardware manual (the manual will indicate the memory address of the register and the meaning of the various register values); c) be able to understand the wiring schematics of the hardware

2. The simplest bare metal hardware control program (control the on and off of the LED light, click to download the sample code )

How to light up the LED light? First, you must look at the hardware connection diagram

Obviously, to light up LED1, a low level must be output on the nLED_1 connection line.

To output a low level on the nLED_1 connection line, the GPB5 of the CPU must be at a low level.

How can we make the GPB5 of the CPU low? According to Chapter 9 of the S3C2440 Hardware Manual ( click to download ), we need to set bits 11 and 10 of the register at address 0x56000010 to 01, so as to configure the GPB5 pin as output, and then write bit 5 of the register at address 0x56000014 to 0, so that the GPB5 pin of the CPU will output a low level.

This corresponds to the following key code in the sample code:

#define GPBCON (*(volatile unsigned long *)0x56000010)
#define GPBDAT (*(volatile unsigned long *)0x56000014)
#define LEDS (1<<5|1<<6|1<<7|1<<8)
GPBCON = 0x00015400;
GPBDAT=(GPBDAT&(~LEDS)) | (1<<6|1<<7|1<<8);

The readme.txt in the sample code says:

for running on real board, you need do following 3 things:
1. Change Target from ARM7TDMI to ARM920t
2. Change load address from 0x8000 to 0x30000000
3. Change image layout for placing init.o(INIT2440) at the first

The reason for doing 1 is that the CPU of the development board - S3C2440 is the core of ARM920t, so the compiler must match it when compiling

The reason for step 2 is that the RAM of the development board is located at 0x30000000 - 0x34000000 (64M in total), and the program must be loaded into ARM by the debugger to run.

Special note: 0x30000000 in the configuration is called "the expected load address of the program", or "load address" for short. "Running address" and "load address" are two very important concepts, so please make sure you understand them clearly. "Running address" is for the compiler to see. By looking at the "running address", the compiler can calculate the absolute addresses of each label, variable, function, etc. in the program in memory, thereby completing the correct compilation of instructions involving addresses. "Load address" is for the debugger or operating system to see. Its function is to let the debugger or operating system load the program to the correct (expected) memory address. Normally, these two addresses of the code are equal, but not necessarily of the data.

The reason for doing 3 is that the code in the INIT2440 section of init.o is the first code to be run, so it must be placed at the very beginning of the entire binary program file.