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 system components 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.
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
Refer to “The Definitive Guide to ARM Cortex-M3 and Cortex-M4 Processors”, chapter 9.5: The SysTick timer.
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
TickCount<500
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 DCD Reset_Handler
; Top of Stack ; Reset Handler ; NMI Handler
; Hard Fault Handler
; MPU Fault Handler
; Bus Fault Handler
; Usage Fault Handler
DCD NMI_Handler
DCD HardFault_Handler
DCD MemManage_Handler
DCD BusFault_Handler
DCD UsageFault_Handler
DCD 0
DCD 0
DCD 0
DCD 0
DCD SVC_Handler
DCD DebugMon_Handler
DCD 0 ; Reserved
DCD PendSV_Handler DCD SysTick_Handler
; PendSV Handler ; SysTick Handler
; External Interrupts
DCD WWDG_IRQHandler
DCD PVD_IRQHandler
DCD TAMP_STAMP_IRQHandler
DCD RTC_WKUP_IRQHandler
DCD FLASH_IRQHandler
DCD RCC_IRQHandler
DCD EXTI0_IRQHandler
DCD EXTI4_IRQHandler
DCD DMA1_Stream0_IRQHandler
DCD DMA1_Stream1_IRQHandler
DCD DMA1_Stream2_IRQHandler
DCD DMA1_Stream3_IRQHandler
DCD DMA1_Stream4_IRQHandler
DCD DMA1_Stream5_IRQHandler
DCD DMA1_Stream6_IRQHandler
DCD ADC_IRQHandler ;
; Reserved ; Reserved ; Reserved ; Reserved
; SVCall Handler
; Debug Monitor Handler
; Window WatchDog
; PVD through EXTI Line detection
; Tamper and TimeStamps through the EXTI line ; RTC Wakeup through the EXTI line
; FLASH ; RCC
; EXTI Line0 ; EXTI Line1 ; EXTI Line2 ; EXTI Line3 ; EXTI Line4
; DMA1 Stream 0 ; DMA1 Stream 1 ; DMA1 Stream 2 ; DMA1 Stream 3 ; DMA1 Stream 4 ; DMA1 Stream 5 ; DMA1 Stream 6
ADC1, ADC2 and ADC3s
DCD CAN1_TX_IRQHandler
DCD CAN1_RX0_IRQHandler
DCD CAN1_RX1_IRQHandler
DCD CAN1_SCE_IRQHandler
DCD EXTI9_5_IRQHandler
DCD TIM1_BRK_TIM9_IRQHandler
DCD TIM1_UP_TIM10_IRQHandler
DCD TIM1_TRG_COM_TIM11_IRQHandler ; TIM1 Trigger and Commutation and
TIM11
TIM14
; TIM8 Update and TIM13 DCD TIM8_CC_IRQHandler ; TIM8 Capture Compare
DCD DMA1_Stream7_IRQHandler
; DMA1 Stream7
DCD FMC_IRQHandler
DCD SDIO_IRQHandler
DCD TIM5_IRQHandler
DCD SPI3_IRQHandler
DCD UART4_IRQHandler
DCD UART5_IRQHandler
DCD TIM6_DAC_IRQHandler
DCD TIM7_IRQHandler
; FMC ; SDIO ; TIM5
; SPI3
; UART4
; UART5
; TIM6 and DAC1&2 underrun errors ; TIM7
DCD DMA2_Stream0_IRQHandler DCD DMA2_Stream1_IRQHandler DCD DMA2_Stream2_IRQHandler DCD DMA2_Stream3_IRQHandler DCD DMA2_Stream4_IRQHandler DCD ETH_IRQHandler ; DCD ETH_WKUP_IRQHandler
; DMA2 Stream 0 ; DMA2 Stream 1 ; DMA2 Stream 2 ; DMA2 Stream 3 ; DMA2 Stream 4
Ethernet
; Ethernet Wakeup through EXTI line
; CAN1 TX
; CAN1 RX0
; CAN1 RX1
DCD TIM3_IRQHandler
DCD TIM4_IRQHandler
DCD USART3_IRQHandler
DCD EXTI15_10_IRQHandler
DCD RTC_Alarm_IRQHandler
DCD OTG_FS_WKUP_IRQHandler
DCD TIM8_BRK_TIM12_IRQHandler
DCD TIM8_UP_TIM13_IRQHandler
DCD TIM8_TRG_COM_TIM14_IRQHandler ; TIM8 Trigger and Commutation and
; TIM3 ; TIM4
; SPI1 ; SPI2
; USART1 ; USART2 ; USART3
; TIM1 Break and TIM9
; TIM1 Update and TIM10
; TIM1 Capture Compare ; TIM2
; I2C1 Event ; I2C1 Error ; I2C2 Event ; I2C2 Error
; External Line[15:10]s
; RTC Alarm (A and B) through EXTI Line
; USB OTG FS Wakeup through EXTI line ; TIM8 Break and TIM12
DCD CAN2_TX_IRQHandler
DCD CAN2_RX0_IRQHandler
DCD CAN2_RX1_IRQHandler
DCD CAN2_SCE_IRQHandler
DCD OTG_FS_IRQHandler
DCD DMA2_Stream5_IRQHandler
DCD DMA2_Stream6_IRQHandler
DCD DMA2_Stream7_IRQHandler
DCD USART6_IRQHandler
DCD I2C3_EV_IRQHandler
DCD I2C3_ER_IRQHandler
DCD OTG_HS_EP1_OUT_IRQHandler
DCD OTG_HS_EP1_IN_IRQHandler
DCD OTG_HS_WKUP_IRQHandler
DCD OTG_HS_IRQHandler
DCD DCMI_IRQHandler
DCD CRYP_IRQHandler
DCD HASH_RNG_IRQHandler
DCD FPU_IRQHandler
__Vectors_End
; CAN2 TX
; CAN2 RX0
; CAN2 RX1; DCMI
; CRYPTO
; Hash and Rng ; FPU
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 c- like 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 ARMED0 0 0 0 ALARMED 0 0 0 0
Report
Make sure that all the above highlighted States & Transitions have non-zero coverage.
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.