QDK ARM-IAR STR91x - Quantum Leaps

QP state machine frameworks for STR91x 

QDK 

ST Microlectronics STR91x 

with IAR Toolset 

Document Revision D 

November 2011 

Copyright © Quantum Leaps, LLC 

www.quantum-leaps.com 

www.state-machine.com

Table of Contents 

1 Introduction..............................................................................................................1 

1.1 What’s Included in the QDK?....................................................................................2 

1.2 Licensing the QDK...................................................................................................2 

2 Getting Started.........................................................................................................3 

2.1 Installation............................................................................................................3 

2.2 Building the QP Libraries..........................................................................................4 

2.3 Building the Examples.............................................................................................4 

2.4 Running the Examples.............................................................................................5 

2.4.1 Dining Philosopher Problem (DPP) Example Application..........................................6 

3 Board Support Package.............................................................................................7 

3.1 Startup Code in Assembly........................................................................................7 

3.1.1 Interrupt Vector Table.......................................................................................8 

3.2 Linker Command File...............................................................................................8 

3.3 ARM/THUMB Compilation.........................................................................................9 

3.4 BSP Functions in C................................................................................................10 

3.4.1 The Board Initialization....................................................................................10 

3.4.2 The ISRs........................................................................................................11 

3.4.2.1 ISRs in the Vanilla Port..............................................................................11 

3.4.2.2 ISRs in the QK Port...................................................................................14 

4 The Quantum Spy (QS) Instrumentation.................................................................15 

4.1 QS Time Stamp Callback QS_onGetTime()...............................................................17 

4.2 Invoking the QSpy Host Application.........................................................................18 

5 Related Documents and References........................................................................19 

6 Contact Information................................................................................................20 

Copyright © Quantum Leaps, LLC. All Rights Reserved. 

i

1 Introduction 

This QP Development Kit (QDK) describes how to use QP state machine frameworks with the 

ST Microelectronics STR91x ARM9 microcontrollers. The actual hardware/software used in this QDK 

is described below (see also Figure 1): 

J-Link USB 

Debugger 

QS trace data 

(UART0) 

LED/Peripheral 

Jumpers 

STR912F 

Target Device 

Two groups 

of user LEDs 

8 LEDs each 

USB to PC 

External 

power 

Power source 

selection Jumper 

Figure 1 IAR STR912-SK evaluation board with the J-Link JTAG pod. 


1 of 20


ST Microelectronics STR91x 

www.state-machine.com/arm 

1. IAR STR912-SK board with STR912F device (ARM966E-S core, 96KB RAM, 512KB ROM) 

2. The J-Link J-Tag pod from Segger (www.segger.com). NOTE: IAR Embedded Workbench supports 

also several other J-Tag pods 

3. IAR Embedded Workbench for ARM (EWARM) KickStart edition version 6.30 

4. QP/C/C++ v4.3.00 or higher 

As shown in Figure 1, the STR912-SK board is connected via a 20-pin ribbon cable to the J-Link 

USB debugger. Additionally, the UART0 connector of the STR912-SK board is used in this QDK for 

QS (“Spy”) software tracing of the live QP applications. You need a straight serial cable with DB9 

connectors to connect UART0 to the COM port of your PC. 

1.1 What’s Included in the QDK? 

This QDK provides the Board Support Package (BSP) and two versions of the Dining Philosopher 

Problem (DPP) example application described in the Application Note “Dining Philosopher Problem 

Example” [AN DPP]. 

1. DPP with the cooperative “Vanilla” kernel 

2. DPP with the preemptive run-to-completion QK kernel 

3. Application Note “QP and ARM7/ARM9” [AN QP and ARM] 

4. Application Note “Dining Philosopher Problem Example” [AN DPP] 

NOTE: This QDK covers both the C and C++ version of QP. The concrete code examples are 

taken from the C version, but the C++ version is essentially identical except for some trivial 

syntax differences. 

1.2 Licensing the QDK 

The Generally Available (GA) distribution of this QDK available for download from the 

www.state-machine.com/arm website is offered with the following two licensing options: 

• The GNU General Public License version 2 (GPL) as published by the Free 

Software Foundation and appearing in the file GPL.TXT included in the packaging 

of every Quantum Leaps software distribution. The GPL open source license 

allows you to use the software at no charge under the condition that if 

you redistribute the original software or applications derived from it, the complete 

source code for your application must be also available under the conditions 

of the GPL (GPL Section 2[b]). 

• One of several Quantum Leaps commercial licenses, which are designed for customers 

who wish to retain the proprietary status of their code and therefore 

cannot use the GNU General Public License. The customers who license 

Quantum Leaps software under the commercial licenses do not use the software 

under the GPL and therefore are not subject to any of its terms. 

For more information, please visit the licensing section of our website at: 

www.state-machine.com/licensing. 


2 of 20




2 Getting Started 

This section describes how to install, build, and use the QDK. This information is intentionally included 

early in this document, so that you could start using the QDK as soon as possible. 

NOTE: This QDK assumes that the standard QP distribution, consisting of QEP, QF, QK, and 

QS, has been installed, before installing this QDK. It is also strongly recommended that you 

read the QP Tutorial (www.quantum-leaps.com/doxygen/qpc/tutorial_page.html) before you 

start experimenting with this QDK. 

2.1 Installation 

This section describes how to install, build, and use the QDK-ARM-IAR_STR91x based on two versions 

of an example application. 

This document describes the standard QDK distribution, which must be augmented with the generic 

ARM code accompanying the Application Note “QP and ARM7/ARM with IAR Toolset” [QL 08a] and 

the standard distributions of the QP components. You need to download the following archives and 

unzip all of them into the same directory of your choice. This directory will be referred to as QP 

root directory and denoted : 

/ 

- QP root directory (qpcpp for QP/C++) 

| 

+-include/ 

- QP public include files 

| +-qassert.h – Quantum Assertions platform-independent public include 

| +-qep.h – QEP platform-independent public include 

| +-qf.h – QF platform-independent public include 

| +-qequeue.h – native QF event queue include 

| +-qmpool.h – native QF memory pool include 

| +-qpset.h – native QF priority set include 

| 

+-ports/ 

- QP ports 

| +-arm/ - ARM port 

| | +-vanilla/ - “vanilla” ports 

| | | +-iar/ - IAR compiler 

| | | | +-dbg/ - QP libraries – Debug configuration 

| | | | | +-qep_ARM966E-S.a - QEP library 

| | | | | +-qf_ARM966E-S.a - QF library 

| | | | +-rel/ - QP libraries – Release configuration 

| | | | +-spy/ - QP libraries – Spy configuration 

| | | | +-make_ARM966E-S.bat - make script for building QP libraries (ARM966E-S core) 

| | | | +-qep_port.h - QEP port 

| | | | +-qf_port.h - QF port to ARM 

| | | | +-qs_port.h - QS port 

| | | | +-qp_port.h - QP port 

| | | 

| | +-qk/ - QK ports 

| | | +-iar/ - IAR compiler 

| | | | +-dbg/ - QP libraries – Debug configuration 

| | | | | +-qep_ARM966E-S.a - QEP library 

| | | | | +-qf_ARM966E-S.a - QF library 

| | | | | +-qk_ARM966E-S.a - QK library 

| | | | +-rel/ - QP libraries – Release configuration 

| | | | +-spy/ - QP libraries – Spy configuration 

| | | | +-make_ARM966E-S.bat - make script for building QP libraries (ARM966E-S core) 

| | | | +-qep_port.h - QEP port 

| | | | +-qf_port.h - QF port to ARM 

| | | | +-qk_port.h - QK port to ARM 


3 of 20




| | | | +-qs_port.h - QS port 

| | | | +-qp_port.h - QP port 

| 

+-examples/ 

- subdirectory containing the examples 

| +-arm/ - ARM examples 

| | +-vanilla/ - “Vanilla” port 

| | | +-iar/ - IAR ARM compiler 

| | | | +-dpp-at91sam7s-ek – DPP example for the AT91SAM7S-EK evaluation board 

| | | | | +-dbg/ – Debug build (runs from RAM) 

| | | | | | +-dpp.out – executable image 

| | | | | +-rel/ – Release build (runs from Flash) 

| | | | | | +-dpp.out – executable image 

| | | | | +-spy/ – Spy build (runs from RAM) 

| | | | | | +-dpp.out – executable image (instrumented with QSpy) 

| | | | | +-at91mc_cstartup.s – AT91 startup code in assembly 

| | | | | +-at91SAM7S64.icf – IAR ARM linker command file 

| | | | | +-bsp.h - Board Support Package include file 

| | | | | +-bsp.c - Board Support Package implementation 

| | | | | +-dpp.h 

| | | | | +-main.c 

| | | | | +-philo.c 

| | | | | +-table.c 

| | | | | +-dpp.ewp – IAR project for the DPP application example 

| | | | | +-dpp.eww – IAR workspace for the DPP application example 

| | | | 

| | +-qk/ - QK (Quantum Kernel) port 

| | | +-iar/ - IAR ARM compiler 

| | | | +-dpp-at91sam7s-ek – DPP example for the AT91SAM7S-EK evaluation board 

| | | | | +-. . . – the same files as in vanilla/iar/dpp-at91sam7s 

| . . . 

Listing 1 Selected QP directories and files after installing QDK-ARM_IAR_STR91x. The 

highlighted elements are included the files included in QDK-ARM_IAR_STR91x. 

2.2 Building the QP Libraries 

All QP components are deployed as static libraries that you link to your application. The pre-built 

libraries for QEP, QF, QS, and QK are provided in the QDK code. The Application Note “QP and 

ARM7/ARM with IAR Toolset” [QL 08a] describes the process of building the QP libraries. 

2.3 Building the Examples 

The examples included in this QDK are based on the standard Dining Philosopher Problem implemented 

with active objects (see Chapter 9 in [PSiCC2]). 

The example directory contains the IAR Embedded Workbench workspace file dpp.eww that you can 

load into the IAR EW IDE (see Figure 2). The workspace contains three build configurations (Debug, 

Release, and Spy) that you can select with the drop-down list, as shown in Figure 2. 


4 of 20




Select build 

configuration 

Figure 2 IAR Embedded Workbench with the dpp-freertos.eww workspace. 

2.4 Running the Examples 

As mentioned before, this QDK contains two example applications for the STR912-SK board. Both 

of these examples require setting up the jumpers as shown in Figure 1 and in greater detail in Figure 

3. 

LEDs connected to GPIO6 

Peripherals (e.g., UARTs ) connected to GPIO3 

LED 16 

LED 15 

LED 14 

LED 13 

LED 12 

LED 11 

LED 10 

LED 9 

LED 8 

LED 7 

LED 6 

LED 5 

LED 4 

LED 3 

LED 2 

LED 1 

Figure 3 LED/Peripheral jumper setting on the STR912-SK board. 


5 of 20

2.4.1 Dining Philosopher Problem (DPP) Example Application 




The DPP application blinks the user LEDs 9-13 (see Figure 1) to indicate the changing status of the 

Dining Philosophers. Additionally LED 15 should blink once per second with 50% duty cycle. LED 16 

is toggled from the idle processing and its intensity is proportional to the frequency of idle task. 

If you downloaded the Spy build configuration to the target board and connected the UAR0 of the 

STR912-SK board to the COM port on your PC, you could launch the QSPY host utility to observe 

the output in the human-readable format. You launch the QSPY utility on a Windows PC as follows. 

Change the directory to the QSPY host utility \tools\qspy\win32\mingw\rel and execute: 

qspy –c COM1 –b 115200 

This will start the QSPY host application to listen on COM1 serial port with baud rate 115200. 

(Please use the actual COM port number on your PC.) The following screen shot shows the QSPY 

output from the DPP run: 

command-line 

options used 

timestamp 

QS trace record 

Figure 4 Screen shot from the QSPY output. 


6 of 20




3 Board Support Package 

The Board Support Package (BSP) for the STR912-SK board is co-located with the DPP example applications 

and consists of the following files: 

• s91x_init.s — startup code in assembly provided by ST Microelectronics 

• 91x_vect_qp.s — interrupt vector table for QP 

• STR91xlibrary\ — directory with code for peripherals of the ST91x microcontroller family 

provided by ST Microelectronics 

• 91x_conf.h — configuration for the STR91xlibrary used in the DPP example (you need to customize 

for your application) 

• 91x_it.c — dummy definitions of all interrupt handlers for ST91x (you need to re-define interrupts 

that you use in your application) 

• STR91x_FLASH.icf — linker command file to link the code to Flash (default) 

• STR91x_RAM.icf — alternative linker command file to link the code to RAM (for debugging only) 

• bsp.c — BSP functions and ISRs in C 

• bsp.h — BSP header file 

The BSP does not initialize all STR91x peripherals. However, it should be fairly complete in that it 

supports code downloading to Flash, software tracing with Quantum Spy (QS), fine-tuning of the 

release version, and more. 

3.1 Startup Code in Assembly 

The customized startup sequence for the STR91x is implemented in the assembly file s91x_init.s 

co-located with the DPP example application. This file is provided by ST Microelectronics and includes 

the following steps: 

• Enabling the Buffered mode 

• Remapping Flash Bank 0 at address 0x0 and Bank 1 at address 0x80000, when the bank 0 is 

the boot bank, then also enabling Bank 1 

• Configuring 96K RAM, PFQBC enabled, DTCM & AHB wait-states disabled 

• Configuring 96 MHZ PLL clock as the default frequency 

• Initialization of all ARM Stack pointer registers (such as USER/SYSTEM, IRQ, FIQ, SVC, UNDEF, 

ABORT) 

NOTE: The standard QP port to ARM7/ARM9 uses only the USER/SYSTEM stack. All other 

stacks should be set to zero size for this QDK. 

You need to customize the assembly file s91x_init.s only if you want to change the basic configuration 

of the processor. Otherwise, you should have not need to touch this file. 


7 of 20




3.1.1 Interrupt Vector Table 

(1) SECTION .intvec:CODE:ROOT(2) 

PUBLIC __vector 

IMPORT __iar_program_start 

IMPORT QF_undef 

IMPORT QF_swi 

IMPORT QF_pAbort 

IMPORT QF_dAbort 

IMPORT QF_reserved 

IMPORT QF_irq 

IMPORT QF_fiq 

(2) CODE32 

(3) __vector: 

(4) LDR PC,=__iar_program_start 

LDR PC,=QF_undef 

LDR PC,=QF_swi 

LDR PC,=QF_pAbort 

LDR PC,=QF_dAbort 

LDR PC,=QF_reserved 

LDR PC,=QF_irq 

LDR PC,=QF_fiq 

LTORG 

END 

Listing 2 Interrupt Vector Table defined in the 91x_vect_qp.s module. 

(1) This module defines interrupt vectors and is placed in the .intvec section. 

(2) The ARM core always starts in ARM state. 

(3) The symbol __vector denotes the beginning the primary vector table. 

(4) The primary vector table is pre-filled with direct jumps to the exception handlers defined in QP 

port to ARM (see Application Note “QP and ARM” [QP-ARM 08] included in this QDK). 

NOTE: All QP exception handlers such as QF_undef, QF_swi, … QF_irq, and QF_fiq always perform 

a mode switch to the SYSTEM mode, and call the C-level code in this mode. In particu - 

lar, the QP exception handlers never use the stack pointers of the various ARM modes and 

therefore you don’t need to setup these stacks. 

3.2 Linker Command File 

A linker command file controls where the linker will locate the code and data in memory. The BSP 

for the STR912-SK board comes with the file STR91x_FLASH.icf to place the complete application 

image in the Flash ROM. This file is not intended for manual editing, but rather only via the IAR 

Embedded Workbench IDE, as shown in Figure 5. 


8 of 20




Browse for the 

linker file 

Select 

Linker 

Edit the linker 

configuration file 

Adjust the CSTACK 

(USER/SYSTEM stack) 

Figure 5 Adjusting the stack sizes in the IAR Embedded Workbench IDE. 

Typically, you don’t need to adjust the memory addresses for the ARM device (in the Memory Re - 

gions tab in Figure 5), because they come pre-configured when you select the specific device in the 

General Options section. However, you should adjust the Stack and Heap Sizes on the third tab of 

the “Linker configuration file editor” shown in Figure 5. Again, note that QP uses only the 

USER/SYSTEM stack and does not use any other stacks. If you don’t use the heap, which is highly 

recommended in any embedded application, you should also set the size of the heap to zero. 

3.3 ARM/THUMB Compilation 

A very important and often overlooked aspect for optimal system performance is controlling both 

the instruction set chosen to compile individual modules. This QDK gives you the freedom of choosing 

between ARM and THUMB instruction sets for most of the modules. 

Generally, the code that must frequently disable/enable interrupts runs faster when compiled to 

ARM, because the THUMB instruction set does not contain the MSR/MRS instructions necessary to 

disable interrupts at the ARM core level (so costly mode switches must occur in the THUMB code). 

On the other hand, the application-level code executes faster when compiled to THUMB, due to 

better code density. 


9 of 20




The IAR project file for the DPP application places the application code in a separate folder than the 

startup code. Therefore it is easy to override the compilation options separately for the Application 

folder and the other code. Currently, the Application folder is compiled to THUMB. 

3.4 BSP Functions in C 

The file bsp.c located in the directory \examples\arm\vanilla\iar\dpp-str912-sk contains the 

ISRs, the initialization, and the QS port to the STR912-SK board. The file bsp.c uses the facility 

provided in the subdirectory STR91xlibrary\ provided by ST Microelectronics. 

3.4.1 The Board Initialization 

The board initialization is performed in the BSP_init() function called from main(). 

void BSP_init(void) { 

GPIO_InitTypeDef GPIO_InitStruct; 

uint8_t n; 

(1) WDG_Cmd(DISABLE); 

(2) SCU_PCLKDivisorConfig(SCU_PCLK_Div2); /* peripheral bus clokdivisor = 2 */ 

/* GPIO 6 clock source enable, used by the LEDs */ 

(3) SCU_APBPeriphClockConfig(__GPIO6, ENABLE); 

/* enable VIC clock */ 

SCU_AHBPeriphClockConfig(__VIC, ENABLE); 

SCU_AHBPeriphReset(__VIC, DISABLE); 

VIC_DeInit(); 

VIC0->DVAR = (uint32_t)&ISR_spur; /* install spurious handler for VIC0 */ 

VIC1->DVAR = (uint32_t)&ISR_spur; /* install spurious handler for VIC1 */ 

for (n = 0; n < 32; ++n) { 

VIC_ITCmd(n, DISABLE); 

} 

/* configure GPIO6 to drive the LED's... */ 

(4) GPIO_DeInit(GPIO6); 

GPIO_InitStruct.GPIO_Direction = GPIO_PinOutput; 

GPIO_InitStruct.GPIO_Pin 

= GPIO_Pin_All; 

GPIO_InitStruct.GPIO_Type = GPIO_Type_PushPull; 

GPIO_InitStruct.GPIO_IPConnected = GPIO_IPConnected_Disable; 

GPIO_InitStruct.GPIO_Alternate = GPIO_OutputAlt1; 

GPIO_Init(GPIO6, &GPIO_InitStruct); 

(5) if (QS_INIT((void *)0) == 0) { /* initialize the QS software tracing */ 

Q_ERROR(); 

} 

} 

Listing 3 BSP initialization 

(1) The STR91x Watchdog is disabled – you can have a different policy in your application 

(2) The peripheral clock divisor is selected – you can use a different divisor in your application 

(3) STR91x requires explicitly enabling the clock to all used peripherals 

NOTE: If you forget to enable the clock, the peripheral won’t work! 


10 of 20




(4) The GPIO pins for the LEDs 9-16 (GPIO port 6) are configured. 

NOTE: LEDs 1-8 are not used, because the pins are needed for the UART serial port (see Figure 

3). 

(5) Initialize the QS software tracing (this code is active only when the macro Q_SPY is defined). 

3.4.2 The ISRs 

The Interrupt Service Routines and the initialization of interrupts is the only part of the BSP dependent 

on the QF port type. The following subsections discuss the ISRs for the three QF ports included 

in this QDK. 

3.4.2.1 ISRs in the Vanilla Port 

(1) typedef void (*IntVector)(void); /* IntVector pointer-to-function */ 

(2) __arm void BSP_irq(void) { 

(3) IntVector vect = (IntVector)VIC0->VAR; /* read the VAR from VIC0 */ 

(4) IntVector vect1 = (IntVector)VIC1->VAR; /* read the VAR from VIC1 */ 

(5) QF_INT_ENABLE(); /* allow nesting interrupts */ 

(6) (*vect)(); /* call the IRQ ISR via the pointer to function */ 

(7) QF_INT_DISABLE(); /* disable interrups for the exit sequence */ 

(8) VIC0->VAR = 0; /* send End-Of-Interrupt to VIC0 */ 

(9) VIC1->VAR = 0; /* send End-Of-Interrupt to VIC1 */ 

} 

/*..........................................................................*/ 

(10) __arm void BSP_fiq(void) { 

/* TBD: implement the FIQ handler directly right here, see NOTE02 */ 

/* NOTE: Do NOT enable interrupts throughout the whole FIQ processing. */ 

/* NOTE: Do NOT write EOI to the AIC */ 

} 

/* ISRs --------------------------------------------------------------------*/ 

(11) __arm void TIM3_IRQHandler(void) { 

(12) TIM3->OC1R += BSP_TIM3_PERIOD - 1; /* set the output compare register */ 

(13) TIM3->SR &= ~TIM_IT_OC1; /* clear interrupt source (Timer3) */ 

#ifdef Q_SPY 

{ 

uint16_t currTime16 = (uint16_t)TIM3->CNTR; 

l_currTime32 += (currTime16 - l_prevTime16) & 0xFFFF; 

l_prevTime16 = currTime16; 

} 

#endif 

(14) QF_tick(); /* process all arm time events (timers) */ 

} 

/*..........................................................................*/ 

(15) static __arm void ISR_spur(void) { 

} 

/*..........................................................................*/ 

(16) __arm void QF_onStartup(void) { 

TIM_InitTypeDef TIM_InitStruct; 

(17) SCU_APBPeriphClockConfig(__TIM23, ENABLE); 

TIM_DeInit(TIM3); 


11 of 20




TIM_StructInit(&TIM_InitStruct); 

TIM_InitStruct.TIM_Mode 

= TIM_OCM_CHANNEL_1; 

TIM_InitStruct.TIM_OC1_Modes = TIM_TIMING; 

TIM_InitStruct.TIM_Clock_Source = TIM_CLK_APB; 

TIM_InitStruct.TIM_Clock_Edge = TIM_CLK_EDGE_RISING; 

TIM_InitStruct.TIM_Prescaler = BSP_TIM3_PRESCALER - 1; 

TIM_InitStruct.TIM_Pulse_Level_1 = TIM_HIGH; 

(18) TIM_InitStruct.TIM_Pulse_Length_1 = BSP_TIM3_PERIOD - 1; 

TIM_Init(TIM3, &TIM_InitStruct); 

} 

/* configure the VIC for the TIM3 interrupt */ 

VIC_Config(TIM3_ITLine, VIC_IRQ, BSP_TICK_PRIO); 

VIC_ITCmd(TIM3_ITLine, ENABLE); 

TIM_ITConfig(TIM3, TIM_IT_OC1, ENABLE); 

TIM_CounterCmd(TIM3, TIM_CLEAR); 

TIM_CounterCmd(TIM3, TIM_START); 

Listing 4 The ISR definitions and initialization for the Vanilla port (\examples\arm\- 

vanilla\iar\dpp-at91sam7s-ek\bsp.c). 

(1) This typedef defines the pointer-to-function type for calling the interrupt handlers. 

(2) As described in Application Note “QP and ARM7/ARM with IAR Toolset” [QL 08a], the low-level 

IRQ interrupt “wrapper” in assembly calls function BSP_irq(). This function is a regular C function 

(not an __irq function!) and can be compiled to THUMB or ARM, as you like. Here, the 

function BSP_irq() is defined as an ARM function (via the __arm keyword) to be able to use the 

very efficient, unconditional interrupt disabling and enabling macros QF_INT_DISABLE()/ 

QF_INT_ENABLE(). The __ramfunc extended keyword makes the function to execute from the 

RAM, which is only done for better performance. 

(3) The current interrupt vector is always loaded from the VIC0 VAR register into a temporary variable. 

(4) The VIC1 VAR register is also read to clear the interrupt. 

NOTE: STR91x has two chained Vectored Interrupt Controllers (VIC0 and VIC1). The current 

vector address is always available from VIC0. 

(5) Interrupts are enabled unconditionally at the ARM core level by means of the macro QF_INT_EN- 

ABLE(). 

NOTE: Enabling all IRQs and FIQs is safe, because the AIC performs interrupt prioritization in 

hardware. 

(6) The interrupt handler is invoked via the pointer-to-function (vector address) extracted from the 

AIC. Please note that the vectoring capability of the AIC is actually used, even though this is 

not the traditional auto-vectoring. For the vectoring to work, the VIC VAR registers must be initialized 

with the addresses of interrupt handlers, such as the time tick ISR TIM3_IRQHandler(). 

NOTE: The ST Microelectronics library initializes the appropriate VIC VAR register with the address 

of the corresponding handler routine when you configure the interrupt. 


12 of 20




(7) After ISR function returns, the interrupts are disabled unconditionally at the ARM core level by 

means of the macro QF_INT_ENABLE(). 

(8) The EOI command is written to the VIC0, which informs the interrupt controller that the interrupt 

processing has ended. 

(9) The EOI command is written to the VIC0, which informs the interrupt controller that the interrupt 

processing has ended. 

(10) As described in Application Note “QP and ARM7/ARM with IAR Toolset” [QL 08a], the low-level 

FIQ interrupt “wrapper” in assembly calls function BSP_fiq(). This function is a regular C function 

(not an __fiq function!) and can be compiled to THUMB or ARM, as you like. Here, the 

function BSP_fiq() is defined as __ramfunc to execute from the RAM, which is only done for better 

performance. Because the VICs do not provide priority controller for the FIQ (see the 

“STR91xFA ARM9®-based microcontroller family”) there is really not any value added by indirecting 

via the VIC VAR register. The body of the interrupt might as well be directly implemented 

in BSP_fiq(). 

NOTE: Because the VICs does not protect the FIQ line with the priority controller, the whole 

work of FIQ should be performed with interrupts permanently locked at the ARM core level. 

In particular, the IRQ interrupt should never be unlocked during FIQ processing. 

(11) As described at Listing 4(6), the interrupt handler is a regular C function. 

(12) This BSP uses TIM3 timer as the source for the system clock tick interrupt. TIM3 is a freerunning 

counter, and consequently the output compare register is incremented to interrupt 

again in the desired period. 

(13) The interrupt source (TIM3 in this case) must be cleared. 

NOTE: Please note that the interrupt handler executes with interrupt unlocked at the ARM 

core level. However, the prioritization performed in AIC prevents the same (or any other 

lower-priority) interrupt from preempting the currently serviced interrupt. 

(14) The work of the interrupt is performed, which consists of the system clock tick processing 

QF_tick() in this case. 

(15) The spurious interrupt handler is empty. 

(16) The QF callback QF_onStartup() is called just before entering the background loop of the 

“vanilla” QF port (see Chapter 7 in [PSiCC2]). This purpose of the QF_onStartup() function is to 

configure and enable the interrupts. 

(17) The clock for the Timers 2-3 is enabled. 

(18) The TIM3 register is initialized to interrupt in the desired period. The macro BSP_TIM3_PERIOD is 

defined as follows: 

#define BSP_TIM3_PERIOD \ 

(BSP_CPU_PERIPH_HZ / BSP_TIM3_PRESCALER / BSP_TICKS_PER_SEC) 


13 of 20

3.4.2.2 ISRs in the QK Port 




The ISRs in the QK port are defined and initialization identically as in the “vanilla” port. The only 

difference is that you use the QK “wrapper” functions for interrupts and other exceptions instead of 

QF functions. The following subsections discuss the ISRs for the QK port included in this QDK. 

SECTION .intvec:CODE:ROOT(2) 

PUBLIC __vector 

IMPORT __iar_program_start 

IMPORT QF_undef 

IMPORT QF_swi 

IMPORT QF_pAbort 

IMPORT QF_dAbort 

IMPORT QF_reserved 

IMPORT QK_irq 

IMPORT QK_fiq 

CODE32 

__vector: 

LDR 

LDR 

LDR 

LDR 

LDR 

LDR 

LDR 

LDR 

PC,=__iar_program_start 

PC,=QF_undef 

PC,=QF_swi 

PC,=QF_pAbort 

PC,=QF_dAbort 

PC,=QF_reserved 

PC,=QK_irq 

PC,=QK_fiq 

LTORG 

END 

Listing 5 The Interrupt Vector Table definition for the QK port (\examples\arm\qk\- 

iar\dpp-str912-sk\91x_vect_qp.s). 


14 of 20

4 The Quantum Spy (QS) Instrumentation 




This QDK demonstrates how to use the Quantum Spy (QS) to generate real-time trace of a running 

QP application. Normally, the QS instrumentation is inactive and does not add any overhead to 

your application, but you can turn the instrumentation on by defining the Q_SPY macro and recompiling 

the code. 

Quantum Spy (QS) is a software tracing facility built into all QP components and also available to 

the Application code. QS allows you to gain unprecedented visibility into your application by selectively 

logging almost all interesting events occurring within state machines, the framework, the kernel, 

and your application code. QS software tracing is minimally intrusive, offers precise timestamping, 

sophisticated runtime filtering of events, and good data compression (see Chapter 11 in 

PSiCC2 [PSiCC2]). 

QS can be configured to send the real-time data out of the serial port of the target device. On the 

STR912F MCU, QS uses the built-in USART0 to send the trace data out (see Figure 1), so the QSPY 

host application can conveniently receive the trace data on the host PC. The complete implementation 

of the QS software-tracing output consists of several steps, which are all summarized in Listing 

6 (file bsp.c). 

(1) #ifdef Q_SPY 

(2) static uint32_t l_currTime32; 

(3) static uint16_t l_prevTime16; 

(4) enum AppRecords { /* application-specific trace records */ 

PHILO_STAT = QS_USER 

}; 

#endif 

/*--------------------------------------------------------------------------*/ 

#ifdef Q_SPY 

(5) uint8_t QS_onStartup(void const *arg) { 

(6) static uint8_t qsBuf[BSP_QS_BUF_SIZE]; /* buffer for Quantum Spy */ 

GPIO_InitTypeDef GPIO_InitStruct; 

UART_InitTypeDef UART_InitStruct; 

(7) QS_initBuf(qsBuf, sizeof(qsBuf)); 

/* configure the UART0 for QSPY output ... */ 

(8) SCU_APBPeriphClockConfig(__UART0, ENABLE); /* enable clock for UART0 */ 

(9) SCU_APBPeriphClockConfig(__GPIO3, ENABLE); /* enable clock for GPIO3 */ 

(10) SCU_APBPeriphReset(__UART0, DISABLE); /* remove UART0 from reset */ 

(11) SCU_APBPeriphReset(__GPIO3, DISABLE); /* remove GPIO3 from reset */ 

/* configure UART0_TX pin GPIO3.4 ... */ 

(12) GPIO_DeInit(GPIO3); 

GPIO_InitStruct.GPIO_Pin 

= GPIO_Pin_4; 

GPIO_InitStruct.GPIO_Direction = GPIO_PinOutput; 

GPIO_InitStruct.GPIO_Type = GPIO_Type_PushPull; 

GPIO_InitStruct.GPIO_IPConnected = GPIO_IPConnected_Disable; 

GPIO_InitStruct.GPIO_Alternate = GPIO_OutputAlt3; 

GPIO_Init(GPIO3, &GPIO_InitStruct); 

/* configure UART0... */ 

(13) UART_DeInit(UART0); /* force UART0 registers to reset values */ 

UART_InitStruct.UART_WordLength = UART_WordLength_8D; 

UART_InitStruct.UART_StopBits = UART_StopBits_1; 

UART_InitStruct.UART_Parity = UART_Parity_No; 

UART_InitStruct.UART_BaudRate = BSP_QS_BAUD_RATE; 

UART_InitStruct.UART_HardwareFlowControl = UART_HardwareFlowControl_None; 


15 of 20




UART_InitStruct.UART_Mode = UART_Mode_Tx; 

UART_InitStruct.UART_FIFO = UART_FIFO_Enable; 

UART_InitStruct.UART_TxFIFOLevel = UART_FIFOLevel_1_8; 

UART_InitStruct.UART_RxFIFOLevel = UART_FIFOLevel_1_8; 

UART_Init(UART0, &UART_InitStruct); /* initialize UART0 */ 

UART_Cmd(UART0, ENABLE); /* enable UART0 */ 

(14) QS_FILTER_ON(QS_ALL_RECORDS); 

QS_FILTER_OFF(...); 

... 

/* setup the QS filters... */ 

(15) return (uint8_t)1; /* indicate successfull QS initialization */ 

} 

/*..........................................................................*/ 

(16) void QS_onCleanup(void) { 

} 

/*..........................................................................*/ 

/* NOTE: getTime is invoked within a critical section (inetrrupts disabled) */ 

(17) uint32_t QS_onGetTime(void) { 

(18) uint16_t currTime16 = (uint16_t)TIM3->CNTR; 

(19) l_currTime32 += (currTime16 - l_prevTime16) & 0xFFFF; 

(20) l_prevTime16 = currTime16; 

(21) return l_currTime32; 

} 

/*..........................................................................*/ 

(22) void QS_onFlush(void) { 

uint16_t nBytes = BSP_UART_TX_FIFO; /* the capacity of the UART TX FIFO */ 

uint8_t const *block; 

(23) while ((block = QS_getBlock(&nBytes)) != (uint8_t *)0) { 

(24) while ((UART0->FR & 0x80) == 0) { /* TX FIFO not empty? */ 

} /* keep waiting... */ 

(25) while (nBytes-- != 0) { 

UART0->DR = *block++; /* stick the byte to the TX FIFO */ 

} 

nBytes = BSP_UART_TX_FIFO; /* for the next time around */ 

} 

} 

#endif /* Q_SPY */ 

/*--------------------------------------------------------------------------*/ 

Listing 6 QS implementation to send data out of the UART0 of the STR912 device. 

(1) The QS instrumentation is enabled only when the macro Q_SPY is defined 

(2) The static l_currTime32 variable is used to hold the 32-bit-wide timestamp. 

(3) The static l_prevTime16 variable is used to hold the last 16-bit-wide reading of the free-running 

16-bit Timer 3 (the same used to generate the system clock tick interrupt). 

(4) This enumeration defines application-specific QS trace record(s), to demonstrate how to use 

them. 

(5) You need to define the QS_onStartup() callback to initialize the QS software tracing. 

(6) You should adjust the QS buffer size (in bytes) to your particular application 

(7) You always need to call QS_initBuf() from QS_onStartup() to initialize the trace buffer. 

(8-9) The clock to the UART0 peripheral is enabled. Also, the clock to the GPIO3 peripheral is enabled. 

GPIO3 controls the UART0 transmit and receive pins. 

(10-11) The UART0 and GPIO3 peripherals are removed from reset. 


16 of 20




(12) The transmit pin GPIO3.4 is configured as output, alternative function 3 (UART0 Tx) using the 

ST driver library interface. 

(13) The UART0 is not properly configured using the ST driver library interface. 

(14) The QS filters are setup (see Chapter 11 in [PSiCC2] as well as “QP Reference Manual” 

online). 

(15) The QS_onStartup() callback returns 1, meaning that the QS initialization was successful. 

(16) The QS_onCleanup() callback is empty for MSP430 (the application never exits). 

(17-21) The QS_onGetTime() callback provides a fine-granularity timestamp. The timestamp is discussed 

in the next section. 

(22) The QS_onFlush() callback flushes the QS trace buffer to the host. Typically, the function busywaits 

for the transfer to complete. It is only used in the initialization phase for sending the QS 

dictionary records to the host. 

(23) The implementation of QS for STR912 uses the block-oriented QS-buffer interface QS_getBlock(), 

which provides up to 16 bytes to fill the FIFO of the UART (see Chapter 11 in [PSiCC2]). 

(24) The QS_onFlush() callback busy-waits in-line until the transmit buffer is empty. 

(25) The data byte is inserted into the UART0 data register. 

4.1 QS Time Stamp Callback QS_onGetTime() 

The platform-specific QS port must provide function QS_onGetTime() (Listing 6(17-21)) that returns 

the current time stamp in 32-bit resolution. To provide such a fine-granularity time stamp, the BSP 

uses the free running Timer 3, which is the same timer already used for generation of the system 

clock-tick interrupt. 

NOTE: The QS_onGetTime() callback is always called with interrupts locked. 

Figure 6 shows how the Timer 3 Count Register (TIM3->CNTR) reading is extended to 32 bits. 

The drawing below shows a free running Timer 3 Count Register (TIM3->CNTR) that counts up from 

0 to 0xFFFF and rolls over to 0. If the system tick rate is faster than the rollover rate then you 

could ‘oversample’ this free-running timer by reading it in the clock tick ISR, as shown in Listing 4. 

The 32-bit variable l_currTime32 contains the sum of the 16-bit deltas from each readout of the 

free running Timer 3 Count Register. Because of unsigned 16-bit arithmetic used in Listing 6(19), 

even a ‘small’ current value minus a ‘large’ previous value still results in the proper delta. Note that 

QS_onGetTime() can actually be called at just about any time and thus, also needs to update l_currTime32 

before it returns the current value. 


17 of 20




count 

32-bit time stamp 

returned from 

QS_onGetTime() 

System 

clock tick 

period 

TIM3->CNTR 

Register 

0xFFFF 

0x0000 

System 

clock-tick 

time 

Figure 6 Using the Timer 3 Count Register to provide 32-bit QS time stamp. 

4.2 Invoking the QSpy Host Application 

The QSPY host application receives the QS trace data, parses it and displays on the host workstation 

(currently Windows or Linux). For the configuration options chosen in this port, you invoke the 

QSPY host application as follows (please refer to the QSPY section in the “QP Reference Manual”): 

qspy –c COM1 –b 115200 


18 of 20

5 Related Documents and References 




Document 

[PSiCC2] “Practical UML Statecharts in C/C+ 

+, Second Edition”, Miro Samek, Newnes, 

2008 

[QP-ARM 08] “QP and ARM7/ARM9”, 

Quantum Leaps, 2008 

[QL AN-DPP 08] “Application Note: Dining 

Philosophers Application”, Quantum Leaps, 

LLC, 2008 

[QP/C 08] “QP/C Reference Manual”, 

Quantum Leaps, LLC, 2008 

[QP/C++ 08] “QP/C++ Reference Manual”, 

Quantum Leaps, LLC, 2008 

[QL AN-Directory 07] “Application Note: QP 

Directory Structure”, Quantum Leaps, LLC, 

2007 

[IAR 08a] “ARM® IAR C/C++ Compiler Reference 

Guide”, IAR 08 

[IAR 08b] “IAR Linker and Library Tools Reference 

Guide”, IAR 08 

[IAR 08c] “ARM® Embedded Workbench® 

IDE User Guide”, IAR 08 

[ST 08] “STR91xFA ARM9®-based microcontroller 

family”, ST Microelectronics, April 2008 

Location 

http://www.state-machine.com/doc/AN_DPP.pdf 

(included in this QDK) 

http://www.state-machine.com/doxygen/qpc/ 

http://www.state-machine.com/doxygen/qpcpp/ 

Available from most online book retailers, such as 

amazon.com. See also: http://www.state-machine.com/psicc2.htm 

http://www.statemachine.com/doc/AN_QP_and_ARM.pdf 

http://www.state-machine.com/doc/AN_QP_Directory_Structure.pdf 

Available in PDF as part of the ARM KickStart kit 

in the file EWARM_CompilerReference.pdf. 



in the file EWARM_UserGuide.pdf. 

www.st.com/stonline/products/- 

literature/rm/13742.pdf 


19 of 20




6 Contact Information 

Quantum Leaps, LLC 

103 Cobble Ridge Drive 

Chapel Hill, NC 27516 

USA 

+1 866 450 LEAP (toll free, USA only) 

+1 919 869-2998 (FAX) 

e-mail: info@quantum-leaps.com 

WEB : http://www.quantum-leaps.com 

http://www.state-machine.com 

“Practical UML Statecharts 

in C/C++, 

Second Edition: Event 

Driven Programming 

for Embedded Systems”, 

by Miro Samek, 

Newnes, 2008 

ARM Ltd. 

110 Fulbourn Road 

Cambridge 

CB1 9NJ 

England 

Tel: (44) 01223 400400 

Fax: (44) 01223 400410 

WEB : www.ARM.com 

IAR Systems 

Century Plaza 

1065 E. Hillsdale Blvd 

Foster City, CA 94404 

USA 

+1 650 287 4250 

+1 650 287 4253 (FAX) 

e-mail: Info@IAR.com 

WEB : www.IAR.com 


20 of 20

QDK ARM-IAR STR91x - Quantum Leaps

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?