Updating Freertos source code with IEC61508 standards and showcasing the test scenarios on console/gpio-led
Test Setup:
a. console Hardware Connections You should have ttl-to-rs232 cable to use mini-uart. Connect 5v, tx, rx, gnd pins from RPI3 to ttl cable. On Ubuntu, run minicom sudo killall -9 minicom ; sudo minicom --device /dev/ttyUSB0
b. Build and Flash application Type make You need to modify the arm-non-eabi- toolchain locations in the Makefile: kernel.elf: LDFLAGS += -L"/usr/lib/gcc/arm-none-eabi/4.9.3" -lgcc kernel.elf: LDFLAGS += -L"/usr/lib/arm-none-eabi/lib" -lc On Ubuntu you can install the toolchain with: sudo apt-get install gcc-arm-none-eabi
Format your SD card as FAT32 Copy the bootcode.bin and start.elf from here https://github.com/raspberrypi/firmware/tree/master/boot
Copy the config.txt from /boot_stuff onto the SD card to fix over/underscanning
Copy the kernel7.img generated by make
Scenarios that are simulated and tested
a. Avoid running the scheduler resources when it is invoked without any tasks in the ready/pending/suspended lists
Actual Behaviour : When scheduler is invoked without any tasks in the list, it unnecessarily runs the idle_task, runs the OS timers, consumes stack/heap, measures statistics etc which takes lot of CPU cycles.
Modified Behavior : Scheduler will verify if there are any tasks present in the ready/pending/suspended lists. If the lists are empty, then scheduler returns with a warning to the user. Now, user can decide to go to low power mode.
b. Intrinsic self-verification routines
Actual Behaviour : FreeRTOS APIs returns pdPASS or pdFAIL. If there is other fault like invalid parameter or wrong priority value or insufficient stack or NULL parameters passed, user will not be knowing the exact issue.
Modified Behavior : All the failure cases are addressed properly according to SIL3 guidelines and an informative warning is returned from each function instead of True/False
Test Cases:
Test Scenario 1 for case 1 : Invoke the scheduler without creating tasks. Expected Result : Scheduler should not run and return OS_ERROR_COMPONENT_TASKS|errNO_TASKS_CREATED. Also verify if GPIO is turned ON in the Oscilloscope.
Test Scenario 2 for case 1 : Invoke the scheduler by creating tasks which toggles the GPIO. Expected Result : Scheduler should run and return pdPASS. Also verify if GPIO is toggling in the Oscilloscope.
Test Scenario 3 for case 1 : Invoke the scheduler repetitively. Expected Result : Scheduler should not create its resources again and again and should return warning. Also verify if GPIO is OFF in the Oscilloscope.
Test Scenario 1 for case 2 : Invoke the xTaskCreate() function with invalid arguments. (Pass NULL instead of task_name) Expected Result : Scheduler should not run and return OS_ERROR_COMPONENT_TASKS,errTASK_CREATE_NULL_PARAMETER_SUPPLIED. Also verify if GPIO is turned ON in the Oscilloscope.