CEG3136 – Lab3
Complex State machine (C)
Objectives
To implement a state machine for an alarm system monitoring. The system consists of the following
components: - Keypad UI - Alarm sensors
- Alarm Bells (Alarms) - Central control
Introduction
In this lab we’re going to use the architecture flow shown next. The flow start by the system and
peripheral initialization. Then it goes into a continuous loop with a background task handling mainly
the user interface (UI). At the forefront there are 3 interrupt service routines responsible for
monitoring the sensors and firing the alarms when necessary.
Hereafter is the description of the system software components – note that software components
represent low level hardware components at the low (physical) level, then more complex virtual
(software) components handle the control/processing of the system data. - Console Application: this is the main function of the c-program. It initialize the Alarm System, followed by a background task of handling user input. User input is operator login to
Arm/Disarm the system and to quit the application at the end of simulation. - Alarm System Central Control: this is a data structure (class) that include the low level systemcomponents and manages the system state machine
- Sensor: is a structure holding the state of a physical sensor component. The system supports
up to 64 sensors. Sensors can be in one of the following states: {INACTIVE, IDLE, TRIGGERED,
MALFUNCTION}
- Alarm: is a data structure holding the state of a physical alarm bell component. The system
supports up to 64 alarms. Alarms can be in one of the following states: { ALARM_OFF,
ALARM_ON} - User: represent the database record of a system user, including the name, passcode of the
user, and weather it has the privilege of a super user
- Super User: is a class extension of the user class, it contain an instance of the user class that
has the super flag set.
The high level class diagram is shown below:
The User Interface
The user interface has two components: input and output
- UI Output: provide the system logging of all interesting events taking place at all times
- UI Input: is always ready for user login, if a valid passcode is entered the login event triggers an
interrupt (EXTI1). EXTI1 interrupt handler notifies the central control of the login even to take
proper actions
During initialization 8 users are initialized and 8 super-users are initialized. The passcodes are
hardwired for simplicity as follows: - User1: passcode user123
- User2: passcode user234
- etc. - User7: passcode user789
- Super1: passcode super12
- Super2: passcode super23
- etc. - Super 7: passcode super78
State Machine
As explained earlier, the system’s behavior is described/developed using a state machine. The
behavior of the system changes based on the current system state as well as the external events that
takes place and are monitored by the system. The state diagram of the central control is shown
below.
TickCount<50
The external events are listed below: - Sensor triggering an interrupt (EXTI0), it represent an alarm sensor detecting a risk event, e.g.
window or door open, motion detected, etc. - User login: triggers user input like arming and disarming the system
- Time delay: used to adjust the system timing, e.g. in transition from Arming to Armed states
The actions performed by the system (see state diagram) are: - Set the alarm ON when switching from ARMED state to TRIGGERED state
- Set the alarm OFF when moving from TRIGGERED state to IDLE state
- Reset TickCount on exit from Idle state
The SysTick timer
Refer to “The Definitive Guide to ARM Cortex-M3 and Cortex-M4 Processors”, chapter 9.5: The
SysTick timer.
The Cortex-M processors have a small integrated timer called the SysTick (System Tick) timer. It is
integrated as part of the nested vector interrupt controller (NVIC). It can generate the SysTick
exception (#15). The SysTick timer is a simple decrement 24-bit counter and can run on either
processor clock or a reference clock. The reason for having the timer inside the processor is to help
software portability between Cortex-M processor systems. The SysTick timer can be used as a simple
timer peripheral for periodic interrupt generation, delay generation, or timing measurement.
Using the SysTick timer
If you only want to generate s periodic SysTick interrupt, the easiest way is to use a CMSIS-Core
function: uint32_t SysTick_Config (uint32_t ticks). For example for a 1 millisecond interval, you can use: SysTick_Config ( systemCoreClock / 1000 ). That
means when we divide the core clock frequency in Hz by 1000, we get the number of clocks per
millisecond. The timer interrupt handler: void SysTick_Handler(void), will be invoked every 1
millisecod.
In this lab the SysTick_Handler is used for: - Monitor the signaled sensor triggers and induce EXTI0_IRQn interrupt
- Call system_update_state function
- Induce EXTI2_IRQn periodically to print the ^beep^ message to indicate alarms when the
system is in Alarmed state
Interrupt Vector
Reference startup_stm32f417xx.s the vendor specified interrupt table is as follows. We’ll be using
external interrupt ports 0 & 1 in our development. EXTI0 is connected to the sensors and is ORed,
which means any sensor (or group of sensors) will trigger the interrupt if they are tripped. EXTI1 is
connected to the keypad, which detects a legitimate user login. EXTI2 is used to display “^beep^”
message when the system is in ALARMED state.
; Vector Table Mapped to Address 0 at Reset
AREA RESET, DATA, READONLY
EXPORT __Vectors
EXPORT __Vectors_End
EXPORT __Vectors_Size
__Vectors DCD __initial_sp ; Top of Stack
DCD Reset_Handler ; Reset Handler
DCD NMI_Handler ; NMI Handler
DCD HardFault_Handler ; Hard Fault Handler
DCD MemManage_Handler ; MPU Fault Handler
DCD BusFault_Handler ; Bus Fault Handler
DCD UsageFault_Handler ; Usage Fault Handler
DCD 0 ; Reserved
DCD 0 ; Reserved
DCD 0 ; Reserved
DCD 0 ; Reserved
DCD SVC_Handler ; SVCall Handler
DCD DebugMon_Handler ; Debug Monitor Handler
DCD 0 ; Reserved
DCD PendSV_Handler ; PendSV Handler
DCD SysTick_Handler ; SysTick Handler
; External Interrupts
DCD WWDG_IRQHandler ; Window WatchDog
DCD PVD_IRQHandler ; PVD through EXTI Line detection
DCD TAMP_STAMP_IRQHandler ; Tamper and TimeStamps through the EXTI line
DCD RTC_WKUP_IRQHandler ; RTC Wakeup through the EXTI line
DCD FLASH_IRQHandler ; FLASH
DCD RCC_IRQHandler ; RCC
DCD EXTI0_IRQHandler ; EXTI Line0
DCD EXTI1_IRQHandler ; EXTI Line1
DCD EXTI2_IRQHandler ; EXTI Line2
DCD EXTI3_IRQHandler ; EXTI Line3
DCD EXTI4_IRQHandler ; EXTI Line4
DCD DMA1_Stream0_IRQHandler ; DMA1 Stream 0
DCD DMA1_Stream1_IRQHandler ; DMA1 Stream 1
DCD DMA1_Stream2_IRQHandler ; DMA1 Stream 2
DCD DMA1_Stream3_IRQHandler ; DMA1 Stream 3
DCD DMA1_Stream4_IRQHandler ; DMA1 Stream 4
DCD DMA1_Stream5_IRQHandler ; DMA1 Stream 5
DCD DMA1_Stream6_IRQHandler ; DMA1 Stream 6
DCD ADC_IRQHandler ; ADC1, ADC2 and ADC3s
DCD CAN1_TX_IRQHandler ; CAN1 TX
DCD CAN1_RX0_IRQHandler ; CAN1 RX0
DCD CAN1_RX1_IRQHandler ; CAN1 RX1
DCD CAN1_SCE_IRQHandler ; CAN1 SCE
DCD EXTI9_5_IRQHandler ; External Line[9:5]s
DCD TIM1_BRK_TIM9_IRQHandler ; TIM1 Break and TIM9
DCD TIM1_UP_TIM10_IRQHandler ; TIM1 Update and TIM10
DCD TIM1_TRG_COM_TIM11_IRQHandler ; TIM1 Trigger and Commutation and
TIM11
DCD TIM1_CC_IRQHandler ; TIM1 Capture Compare
DCD TIM2_IRQHandler ; TIM2
DCD TIM3_IRQHandler ; TIM3
DCD TIM4_IRQHandler ; TIM4
DCD I2C1_EV_IRQHandler ; I2C1 Event
DCD I2C1_ER_IRQHandler ; I2C1 Error
DCD I2C2_EV_IRQHandler ; I2C2 Event
DCD I2C2_ER_IRQHandler ; I2C2 Error
DCD SPI1_IRQHandler ; SPI1
DCD SPI2_IRQHandler ; SPI2
DCD USART1_IRQHandler ; USART1
DCD USART2_IRQHandler ; USART2
DCD USART3_IRQHandler ; USART3
DCD EXTI15_10_IRQHandler ; External Line[15:10]s
DCD RTC_Alarm_IRQHandler ; RTC Alarm (A and B) through EXTI Line
DCD OTG_FS_WKUP_IRQHandler ; USB OTG FS Wakeup through EXTI line
DCD TIM8_BRK_TIM12_IRQHandler ; TIM8 Break and TIM12
DCD TIM8_UP_TIM13_IRQHandler ; TIM8 Update and TIM13
DCD TIM8_TRG_COM_TIM14_IRQHandler ; TIM8 Trigger and Commutation and
TIM14
DCD TIM8_CC_IRQHandler ; TIM8 Capture Compare
DCD DMA1_Stream7_IRQHandler ; DMA1 Stream7
DCD FMC_IRQHandler ; FMC
DCD SDIO_IRQHandler ; SDIO
DCD TIM5_IRQHandler ; TIM5
DCD SPI3_IRQHandler ; SPI3
DCD UART4_IRQHandler ; UART4
DCD UART5_IRQHandler ; UART5
DCD TIM6_DAC_IRQHandler ; TIM6 and DAC1&2 underrun errors
DCD TIM7_IRQHandler ; TIM7
DCD DMA2_Stream0_IRQHandler ; DMA2 Stream 0
DCD DMA2_Stream1_IRQHandler ; DMA2 Stream 1
DCD DMA2_Stream2_IRQHandler ; DMA2 Stream 2
DCD DMA2_Stream3_IRQHandler ; DMA2 Stream 3
DCD DMA2_Stream4_IRQHandler ; DMA2 Stream 4
DCD ETH_IRQHandler ; Ethernet
DCD ETH_WKUP_IRQHandler ; Ethernet Wakeup through EXTI line
DCD CAN2_TX_IRQHandler ; CAN2 TX
DCD CAN2_RX0_IRQHandler ; CAN2 RX0
DCD CAN2_RX1_IRQHandler ; CAN2 RX1
DCD CAN2_SCE_IRQHandler ; CAN2 SCE
DCD OTG_FS_IRQHandler ; USB OTG FS
DCD DMA2_Stream5_IRQHandler ; DMA2 Stream 5
DCD DMA2_Stream6_IRQHandler ; DMA2 Stream 6
DCD DMA2_Stream7_IRQHandler ; DMA2 Stream 7
DCD USART6_IRQHandler ; USART6
DCD I2C3_EV_IRQHandler ; I2C3 event
DCD I2C3_ER_IRQHandler ; I2C3 error
DCD OTG_HS_EP1_OUT_IRQHandler ; USB OTG HS End Point 1 Out
DCD OTG_HS_EP1_IN_IRQHandler ; USB OTG HS End Point 1 In
DCD OTG_HS_WKUP_IRQHandler ; USB OTG HS Wakeup through EXTI
DCD OTG_HS_IRQHandler ; USB OTG HS
DCD DCMI_IRQHandler ; DCMI
DCD CRYP_IRQHandler ; CRYPTO
DCD HASH_RNG_IRQHandler ; Hash and Rng
DCD FPU_IRQHandler ; FPU
__Vectors_End
Class Diagram
The detailed class diagram of the alarm system is shown below:
The following global (shared) variables are used to pass data from UI and Signal function (to be
discussed next) to the alarm system: - uint64_t sensor_states: represet updated sensor state, to be set from a signal function
- user_t *logged_in_user: the user object that was last sussesfuly loged in the system, used to
check if it is a super user
Signal File
ARM-Keil allows the simulation of external events using what is known as signal function. This is a clike function that is able to read/write to memory and wait on CPU clock among other things. We use
it to simulate sensor triggering during testing of the system state machine.
The source cod of the signal function is shown below:
signal void set_sensors (unsigned long status1, unsigned long
status2) {
{
printf("wait started \n");
_WDWORD(&sensor_states, status1);
_WDWORD(&sensor_states+4, status2);
twatch (0xFFFFF);
printf("wait is done \n");
_WDWORD(&sensor_states, 0);
_WDWORD(&sensor_states+4, 0);
}
}
The signal function set_sensors takes 2 arguments of unsigned long (32b) that represent the 64
sensors of the system. It writes the status arguments directly into the global uint64_t sensor_states
variable (address 0x20000000, 0x20000004). Then it waits for some time using twatch function and
then reset the sensor states back to 0 (IDLE). This way we can emulate sensor tripping during our
simulation – more details later.
Running Simulation
To run the simulation, first compile the code and then press on the debugger button (magnifier on a
d). Before you start the simulation, click on the debug menu and select “Function Editor”
Open the signal.ini file (include in zip file) and then press compile button – it should compile with no
errors. You can then close the function editor window. Later you can call the signal function during
simulation from the command line argument (at the bottom left) to induce sensor events – see
below:
Your Tasks
The provided code include the console application and all the above mentioned classes: - sensor: sensor.h, sensor.c
- alarm: alarm.h, alarm.c
- user: user.h, user.c
- super user: super_user.h, super_user.c
- alarm system: alarm_system.h, alarm_system.c
The state machine implemented in the system_update_state() function is left as skeleton, your task is
to implement the system state machine according to the state diagram provided. You should test the system behavior and make sure all states are visited and all transitions are tested.
At the end of the test if enter ‘q’ the UI loop is broken and the coverage for the FSM is displayedas
shown below.
FSM State Coverage:
UNARMED ARMING ARMED ALARMED
UNARMED 1 0 0 0
ARMING 0 0 0 0
ARMED 0 0 0 0
ALARMED 0 0 0 0
Make sure that all the above highlighted States & Transitions have non-zero coverage.
Report
The Lab report should include the following:
1) Code snip-it of the system_update_state() function. 2) You simulation log, showing all FSM cover points highlighted above covered with non-zero
coverage value.
3) The source code of the whole project (after cleaning all targets)
Zip all of the above in one zip file and submit t Bright Space.