Study Notes-semihosting

How to Understand semihosting? (The old post has been resending For A Long Time)

Semihosting, as its name implies, is the "semi-master", which means that the program running on the target board uses the facilities of the host to debug the program, use the input and output devices of the host. For example, print the debugging information on the axd console or use the host's keyboard to input the corresponding characters as the program input on the target.
C/C ++ code can use the console by default. For example, if a program containing only C/C ++ is simulated using armulater, the console can be directly used as the output device of the program; if the package contains assembly code, you must use the semihosting SWI method to use the host device. Semihosing SWI, for example, to print or accept characters, such agents include:
1) armulater
2) debug monitor (Angel)
3) multiice
When debugging a bare board or a target board without Angel, it is necessary to use the simulator for debugging. Therefore, the third method is most commonly used. The following describes this method. Of course, UART is also the most common debugging interface. However, with semihosting, You can debug the logic functions of each hardware module independently to ensure that each part of the code is correct before integration, correspondingly, You need to configure UART each time and enable another HyperTerminal to observe the debugging information. Therefore, I tend to use semihosting to debug relevant code during development. These codes are written in C or C ++, which means they are not closely related to hardware configuration.

================================== Below from ads help ==== ======================================
Multi-ice
When using multi-ice in default configuration, semihosting is implemented as follows:
1. on ARM7 processors:
A) a breakpoint is set on the SWI vector.
B) when this breakpoint is hit, multi-ice examines the SWI number.
C) if the SWI is recognized as a semihosting SWI, multi-ice emulates it and transparently restarts execution of the application.
If the SWI is not recognized as a semihosting SWI, multi-ice halts the processor and reports an error.
2. On other processors:
A) vector-catch logic traps SWIS.
B) if the SWI is recognized as a semihosting SWI, multi-ice emulates it and transparently restarts execution of the application.
If the SWI is not recognized as a semihosting SWI, multi-ice halts the processor and reports an error.
This semihosting mechanic can be disabled or changed by the following debugger internal variables:
$ Semihosting_enabled
Set this variable to 0 to disable semihosting. If you are debugging an application running from Rom, this allows you to use an additional watchpoint unit.
Set this variable to 1 to enable semihosting. This is the default.
Set this variable to 2 to enable debug communications channel semihosting.
The S bit in $ vector_catch has no effect unless semihosting is disabled.
$ Semihosting_vector
This variable controls the location of the breakpoint set by multi-ice to detect a semihosted SWI. It is set to the SWI entry in the exception vector table (0x8) by default.
If your application requires semihosting as well as having its own SWI handler, set $ semihosting_vector to an address in your SWI handler. this address must point to an instruction that is only executed if your SWI Handler has identified a call to a semihosting SWI. all registers must already have been restored to whatever values they had on entry to your SWI handler.
Multi-ice handles the semihosted SWI and then examines the contents of LR and returns to the instruction following the SWI instruction in your code.
Regardless of the value of $ vector_catch, all exceptions and interrupts are trapped and reported as an error condition.
For details of how to modify debugger internal variables, see the appropriate debugger documentation.

 

Last modification 2006.3.14