Datasheet

Semihosting

5.3 Adding an application SWI handler

It can be useful to have both the semihosted SWIs and your own application-specific

SWIs available. In such cases you must ensure that the two SWI mechanisms cooperate

correctly. The way to ensure this depends upon the debug agent in use.

5.3.1 ARMulator

To get your own handler and the semihosting handler to cooperate, simply install your

SWI handler into the SWI entry in the vector table. No other actions are required.

When an appropriate SWI is reached in your code, ARMulator detects that it is not a

semihosting SWI and executes the instruction in the SWI entry of the vector table

instead. This instruction must branch to your own SWI handler.

5.3.2 RealMonitor

The RealMonitor SWI handler must be integrated with your application to enable

semihosting (see the documentation supplied with RealMonitor).

5.3.3 Angel

Application SWI handlers are added by:

1. Saving the SWI vector (as installed by Angel).

2. Adjusting the contents of the SWI vector to point to the application SWI handler.

(This is called chaining.) This is described in more detail in the exception

handling section of the ADS Developer Guide.

5.3.4 Multi-ICE

To ensure that the application SWI handler will successfully cooperate with Multi-ICE

semihosting mechanism:

1. Install the application SWI handler into the vector table.

2. Modify

$semihosting_vector

to point to a location at the end of the application

handler. This point in the handler must only be reached if your handler does not

handle the SWI.

Before Multi-ICE traps the SWI, your SWI handler must restore all registers to the

values they had when your SWI handler was entered. Typically, this means that your

SWI handler must store the registers to a stack on entry and restore them before falling

through to the semihosting vector address.