Test Specification for ChibiOS/RT. Test suite for ChibiOS/RT. The purpose of this suite is to perform unit tests on the RT modules and to converge to 100% code coverage through successive improvements. Internal Tests System layer and port interface. The functionality of the system layer and port interface is tested. Basic RT functionality is taken for granted or this test suite could not even be executed. Errors in implementation are detected by executing this sequence with the state checker enabled (CH_DBG_STATE_CHECKER=TRUE). System integrity functionality. The system self-test functionality is invoked in order to make an initial system state assessment and for coverage. Testing Ready List integrity. Testing Virtual Timers List integrity. Testing Registry List integrity. Testing Port-defined integrity. Critical zones functionality. The critical zones API is invoked for coverage. Testing chSysGetStatusAndLockX() and chSysRestoreStatusX(), non reentrant case. Testing chSysGetStatusAndLockX() and chSysRestoreStatusX(), reentrant case. Testing chSysUnconditionalLock(). Testing chSysUnconditionalUnlock(). Testing from ISR context using a virtual timer. Interrupts handling functionality. The interrupts handling API is invoked for coverage. Testing chSysSuspend(), chSysDisable() and chSysEnable(). System Tick Counter functionality. The functionality of the API @p chVTGetSystemTimeX() is tested. A System Tick Counter increment is expected, the test simply hangs if it does not happen. Internal Tests Threads Functionality. This sequence tests the ChibiOS/RT functionalities related to threading. Thread Sleep functionality. The functionality of @p chThdSleep() and derivatives is tested. The current system time is read then a sleep is performed for 100 system ticks and on exit the system time is verified again. The current system time is read then a sleep is performed for 100000 microseconds and on exit the system time is verified again. The current system time is read then a sleep is performed for 100 milliseconds and on exit the system time is verified again. The current system time is read then a sleep is performed for 1 second and on exit the system time is verified again. Function chThdSleepUntil() is tested with a timeline of "now" + 100 ticks. Ready List functionality, threads priority order. Five threads, are enqueued in the ready list and atomically executed. The test expects the threads to perform their operations in correct priority order regardless of the initial order. Creating 5 threads with increasing priority, execution sequence is tested. Creating 5 threads with decreasing priority, execution sequence is tested. Creating 5 threads with pseudo-random priority, execution sequence is tested. Priority change test. A series of priority changes are performed on the current thread in order to verify that the priority change happens as expected. Thread priority is increased by one then a check is performed. Thread priority is returned to the previous value then a check is performed. Priority change test with Priority Inheritance. A series of priority changes are performed on the current thread in order to verify that the priority change happens as expected. CH_CFG_USE_MUTEXES Simulating a priority boost situation (prio > realprio). prio += 2; test_assert(chThdGetPriorityX() == prio + 2, "unexpected priority level");]]> Raising thread priority above original priority but below the boosted level. prio == prio + 2, "unexpected priority level"); test_assert(chThdGetSelfX()->realprio == prio + 1, "unexpected returned real priority level");]]> Raising thread priority above the boosted level. prio == prio + 3, "unexpected priority level"); test_assert(chThdGetSelfX()->realprio == prio + 3, "unexpected real priority level");]]> Restoring original conditions. prio = prio; chThdGetSelfX()->realprio = prio; chSysUnlock();]]> Internal Tests Suspend/Resume. This sequence tests the ChibiOS/RT functionalities related to threads suspend/resume. Suspend and Resume functionality. The functionality of chThdSuspendTimeoutS() and chThdResumeI() is tested. The function chThdSuspendTimeoutS() is invoked, the thread is remotely resumed with message @p MSG_OK. On return the message and the state of the reference are tested. The function chThdSuspendTimeoutS() is invoked, the thread is not resumed so a timeout must occur. On return the message and the state of the reference are tested. Internal Tests Counter and Binary Semaphores. This sequence tests the ChibiOS/RT functionalities related to counter semaphores. CH_CFG_USE_SEMAPHORES Semaphore primitives, no state change. Wait, Signal and Reset primitives are tested. The testing thread does not trigger a state change. The function chSemWait() is invoked, after return the counter and the returned message are tested. The function chSemSignal() is invoked, after return the counter is tested. The function chSemReset() is invoked, after return the counter is tested. Semaphore enqueuing test. Five threads with randomized priorities are enqueued to a semaphore then awakened one at time. The test expects that the threads reach their goal in FIFO order or priority order depending on the @p CH_CFG_USE_SEMAPHORES_PRIORITY configuration setting. Five threads are created with mixed priority levels (not increasing nor decreasing). Threads enqueue on a semaphore initialized to zero. The semaphore is signaled 5 times. The thread activation sequence is tested. Semaphore timeout test. The three possible semaphore waiting modes (do not wait, wait with timeout, wait without timeout) are explored. The test expects that the semaphore wait function returns the correct value in each of the above scenario and that the semaphore structure status is correct after each operation. Testing special case TIME_IMMEDIATE. Testing non-timeout condition. Testing timeout condition. Testing chSemAddCounterI() functionality. The functon is tested by waking up a thread then the semaphore counter value is tested. A thread is created, it goes to wait on the semaphore. The semaphore counter is increased by two, it is then tested to be one, the thread must have completed. Testing chSemWaitSignal() functionality. This test case explicitly addresses the @p chSemWaitSignal() function. A thread is created that performs a wait and a signal operations. The tester thread is awakened from an atomic wait/signal operation. The test expects that the semaphore wait function returns the correct value in each of the above scenario and that the semaphore structure status is correct after each operation. An higher priority thread is created that performs non-atomical wait and signal operations on a semaphore. The function chSemSignalWait() is invoked by specifying the same semaphore for the wait and signal phases. The counter value must be one on exit. The function chSemSignalWait() is invoked again by specifying the same semaphore for the wait and signal phases. The counter value must be one on exit. Testing Binary Semaphores special case. This test case tests the binary semaphores functionality. The test both checks the binary semaphore status and the expected status of the underlying counting semaphore. Creating a binary semaphore in "taken" state, the state is checked. Resetting the binary semaphore in "taken" state, the state must not change. Starting a signaler thread at a lower priority. Waiting for the binary semaphore to be signaled, the semaphore is expected to be taken. Signaling the binary semaphore, checking the binary semaphore state to be "not taken" and the underlying counter semaphore counter to be one. Signaling the binary semaphore again, the internal state must not change from "not taken". Internal Tests Mutexes, Condition Variables and Priority Inheritance. This sequence tests the ChibiOS/RT functionalities related to mutexes, condition variables and priority inheritance algorithm. CH_CFG_USE_MUTEXES Priority enqueuing test. Five threads, with increasing priority, are enqueued on a locked mutex then the mutex is unlocked. The test expects the threads to perform their operations in increasing priority order regardless of the initial order. Getting the initial priority. Locking the mutex. Five threads are created that try to lock and unlock the mutex then terminate. The threads are created in ascending priority order. Unlocking the mutex, the threads will wakeup in priority order because the mutext queue is an ordered one. Priority inheritance, simple case. Three threads are involved in the classic priority inversion scenario, a medium priority thread tries to starve an high priority thread by blocking a low priority thread into a mutex lock zone. The test expects the threads to reach their goal in increasing priority order by rearranging their priorities in order to avoid the priority inversion trap. Getting the system time for test duration measurement. The three contenders threads are created and let run atomically, the goals sequence is tested, the threads must complete in priority order. Testing that all threads completed within the specified time windows (100mS...100mS+ALLOWED_DELAY). Priority inheritance, complex case. Five threads are involved in the complex priority inversion scenario, the priority inheritance algorithm is tested for depths greater than one. The test expects the threads to perform their operations in increasing priority order by rearranging their priorities in order to avoid the priority inversion trap. Getting the system time for test duration measurement. The five contenders threads are created and let run atomically, the goals sequence is tested, the threads must complete in priority order. Testing that all threads completed within the specified time windows (110mS...110mS+ALLOWED_DELAY). Priority return verification. Two threads are spawned that try to lock the mutexes already locked by the tester thread with precise timing. The test expects that the priority changes caused by the priority inheritance algorithm happen at the right moment and with the right values.<br> Thread A performs wait(50), lock(m1), unlock(m1), exit. Thread B performs wait(150), lock(m2), unlock(m2), exit. Getting current thread priority P(0) and assigning to the threads A and B priorities +1 and +2. Spawning threads A and B at priorities P(A) and P(B). Locking the mutex M1 before thread A has a chance to lock it. The priority must not change because A has not yet reached chMtxLock(M1). the mutex is not locked. Waiting 100mS, this makes thread A reach chMtxLock(M1) and get the mutex. This must boost the priority of the current thread at the same level of thread A. Locking the mutex M2 before thread B has a chance to lock it. The priority must not change because B has not yet reached chMtxLock(M2). the mutex is not locked. Waiting 100mS, this makes thread B reach chMtxLock(M2) and get the mutex. This must boost the priority of the current thread at the same level of thread B. Unlocking M2, the priority should fall back to P(A). Unlocking M1, the priority should fall back to P(0). Internal Tests Mailboxes. This sequence tests the ChibiOS/RT functionalities related to mailboxes. CH_CFG_USE_MAILBOXES Mailbox normal API, non-blocking tests. The mailbox normal API is tested without triggering blocking conditions. Testing the mailbox size. Resetting the mailbox, conditions are checked, no errors expected. Filling the mailbox using chMBPost() and chMBPostAhead() once, no errors expected. Testing intermediate conditions. Data pointers must be aligned, semaphore counters are checked. Emptying the mailbox using chMBFetch(), no errors expected. Posting and then fetching one more message, no errors expected. Testing final conditions. Data pointers must be aligned to buffer start, semaphore counters are checked. Mailbox I-Class API, non-blocking tests. The mailbox I-Class API is tested without triggering blocking conditions. Testing the mailbox size. Resetting the mailbox, conditions are checked, no errors expected. Filling the mailbox using chMBPostI() and chMBPostAheadI() once, no errors expected. Testing intermediate conditions. Data pointers must be aligned, semaphore counters are checked. Emptying the mailbox using chMBFetchI(), no errors expected. Posting and then fetching one more message, no errors expected. Testing final conditions. Data pointers must be aligned to buffer start, semaphore counters are checked. Mailbox timeouts. The mailbox API is tested for timeouts. Filling the mailbox. Testing chMBPost(), chMBPostI(), chMBPostAhead() and chMBPostAheadI() timeout. Resetting the mailbox. Testing chMBFetch() and chMBFetchI() timeout. Internal Tests Memory Pools. This sequence tests the ChibiOS/RT functionalities related to memory pools. CH_CFG_USE_MEMPOOLS Loading and emptying a memory pool. The memory pool functionality is tested by loading and emptying it, all conditions are tested. Adding the objects to the pool using chPoolLoadArray(). Emptying the pool using chPoolAlloc(). Now must be empty. Adding the objects to the pool using chPoolFree(). Emptying the pool using chPoolAlloc() again. Now must be empty again. Covering the case where a provider is unable to return more memory. Loading and emptying a guarded memory pool without waiting. The memory pool functionality is tested by loading and emptying it, all conditions are tested. CH_CFG_USE_SEMAPHORES Adding the objects to the pool using chGuardedPoolLoadArray(). Emptying the pool using chGuardedPoolAllocTimeout(). Now must be empty. Adding the objects to the pool using chGuardedPoolFree(). Emptying the pool using chGuardedPoolAllocTimeout() again. Now must be empty again. Guarded Memory Pools timeout. The timeout features for the Guarded Memory Pools is tested. CH_CFG_USE_SEMAPHORES Trying to allocate with 100mS timeout, must fail because the pool is empty. Internal Tests Memory Heaps. This sequence tests the ChibiOS/RT functionalities related to memory heaps. CH_CFG_USE_HEAP Allocation and fragmentation. Series of allocations/deallocations are performed in carefully designed sequences in order to stimulate all the possible code paths inside the allocator. The test expects to find the heap back to the initial status after each sequence. Testing initial conditions, the heap must not be fragmented and one free block present. Trying to allocate an block bigger than available space, an error is expected. Single block allocation using chHeapAlloc() then the block is freed using chHeapFree(), must not fail. Using chHeapStatus() to assess the heap state. There must be at least one free block of sufficient size. = ALLOC_SIZE, "unexpected heap state"); test_assert(total_size == largest_size, "unexpected heap state");]]> Allocating then freeing in the same order. Allocating then freeing in reverse order. Small fragments handling. Checking the behavior when allocating blocks with size not multiple of alignment unit. Skipping a fragment, the first fragment in the list is too small so the allocator must pick the second one. Allocating the whole available space. Testing final conditions. The heap geometry must be the same than the one registered at beginning. Default Heap. The default heap is pre-allocated in the system. We test base functionality. Single block allocation using chHeapAlloc() then the block is freed using chHeapFree(), must not fail. Testing allocation failure.