BLE Stress Tests
QUICK TIPS:
You need 2 controllers supported by MyNewt. One will become TX device,
the other will become RX device.
1. Set role (TX=0, RX=1) for current device in syscfg.yml
BLE_STRESS_TEST_ROLE: 1
The RX has LED2 turned on.
2. Set (in syscfg.yml) number of times to repeat each tested action
in use case, e.g. do 1000 times connect/disconnect to complete use case.
RX_STRESS_REPEAT: 1000
3. To perform only specific test, go to rx_stress.c,
find definition of rx_stress_main_task_fn(void *arg) and in place of
for-loop just paste function rx_stress_start(i), where i is id of test.
1 | Stress Connect -> Connect Cancel - repeat 1000 | RX: Nothing | TX: Connect/Connect cancel | 2 | Stress Connect/Disconnect legacy - repeat 1000 | RX: Advertise legacy | TX: Connect/Disconnect | 3 | Stress Connect/Disconnect ext adv - repeat 1000 | RX: Advertise Ext | TX: Connect/Disconnect | 4 | Stress connection params update (TX) - (1000) | RX: Advertise | TX: Connect/Connect param update | 5 | Stress connection params update (RX) - (1000) | RX: Advertise/Connect param update | TX: Connect | 6 | Stress Scan | RX: Advertise a known data pattern | TX: Scan and check received data with pattern | 7 | Stress PHY Update (TX) - (1000) | RX: Advertise | TX: Connect/Phy update | 8 | Stress PHY update (RX) - (1000) | RX: Advertise/Phy update | TX: Connect | 9 | Stress multi connection | RX: Advertise Ext | TX: Establish and maintain as many instances as possible | 10 | Stress L2CAP send | RX: Send 64kB of data with L2CAP | TX: Measure bit rate and max received data MTU | 11 | Stress Advertise/Connect/Continue Adv/Disconnect | RX: Advertise Ext/Continue same advertise after connect | TX: Connect | 12 | Stress GATT indicating | RX: Indicate | TX: Receive indication. Measure average time of indicating. | 13 | Stress GATT notification | RX: Notify. Measure average time of notifying. | TX: Count the number of received notification. | 14 | Stress GATT Subscribe/Notify/Unsubscribe | RX: Notify on subscribe | TX: Measure the average time from sending a subscription request | to receiving a notification. | 15 | Stress Connect/Send/Disconnect | RX: Advertise/Send via ATT/Disconnect | TX: Receive notification. Measure time of notifying.
Concept: The RX device advertises data containing a UUID128 of test use case that should be performed. The TX device scan for known UUIDs, when it finds, adapts to the advertised use case and runs a test.
Stress Task vs Semaphore: The rx_stress_start_auto function starts main stress test task that runs all stress tests one by one. The tests are based on event handling, so to synchronize main task with events, a semaphore is used. On use case start there is 0 tokens for semaphore. After main task starts one of use cases, it comes across a semaphore and has to wait. When use case is completed, 1 token is released, so main task can use it to pass through semaphore. The tx_stress_start_auto function works analogically.
Newt target set example: rymek@rymek:/projects/bletiny_proj$ newt target show bletest_tx targets/bletest_tx app=@apache-mynewt-nimble/apps/blestress bsp=@apache-mynewt-core/hw/bsp/nordic_pca10056 build_profile=debug syscfg=BLE_STRESS_TEST_ROLE=0 rymek@rymek:/projects/bletiny_proj$ newt target show bletest_rx targets/bletest_rx app=@apache-mynewt-nimble/apps/blestress bsp=@apache-mynewt-core/hw/bsp/nordic_pca10056 build_profile=debug syscfg=BLE_STRESS_TEST_ROLE=1
Example of expected logs on TX side(LOG_LEVEL > 1): Start test num 1 >>>>>>>>>>>>>>>>>>>> Stress test 1 completed Start scan for test Start test num 2 >>>>>>>>>>>>>>>>>>>> Stress test 2 completed Start scan for test Start test num 3 >>>>>>>>>>>>>>>>>>>> Stress test 3 completed Start scan for test Start test num 4 >>>>>>>>>>>>>>>>>>>> Stress test 4 completed Start scan for test Start test num 5 >>>>>>>>>>>>>>>>>>>> Stress test 5 completed Start scan for test Start test num 6 >>>>>>>>>>>>>>>>>>>> Stress test 6 completed Start scan for test Start test num 7 >>>>>>>>>>>>>>>>>>>> Stress test 7 completed Start scan for test Start test num 8 >>>>>>>>>>>>>>>>>>>> Stress test 8 completed All tests completed Tests results: Use case 1 - Stress Connect -> Connect Cancel: Con attempts = 20 Con success = 0 Use case 2 - Stress Connect/Disconnect legacy: Con attempts = 20 Con success = 20 Use case 3 - Stress Connect/Disconnect ext adv: Con attempts = 20 Con success = 20 Use case 4 - Stress connection params update (TX): Params updates = 20 Use case 5 - Stress connection params update (RX): Params updates = 20 Use case 6 - Stress Scan: Received first packets = 20 Received all packets = 20 Use case 7 - Stress PHY Update (TX): PHY updates = 20 Use case 8 - Stress Connect -> Connect Cancel: PHY updates = 20
Example of expected logs on RX side(LOG_LEVEL > 1): Start test num 2 >>>>>>>>>>>>>>>>>>>> Stress test 2 completed Start test num 3 >>>>>>>>>>>>>>>>>>>> Stress test 3 completed Start test num 4 >>>>>>>>>>>>>>>>>>>> Stress test 4 completed Start test num 5 >>>>>>>>>>>>>>>>>>>> Stress test 5 completed Start test num 6 Received signal to switch test Start test num 7 >>>>>>>>>>>>>>>>>>>> Stress test 7 completed Start test num 8 >>>>>>>>>>>>>>>>>>>> Stress test 8 completed All tests completed Tests results: Use case 1 - Stress Connect -> Connect Cancel: Con attempts = 0 Con success = 0 Use case 2 - Stress Connect/Disconnect legacy: Con attempts = 20 Con success = 20 Use case 3 - Stress Connect/Disconnect ext adv: Con attempts = 20 Con success = 20 Use case 4 - Stress connection params update (TX): Params updates = 20 Use case 5 - Stress connection params update (RX): Params updates = 20 Use case 6 - Stress Scan: Received first packets = 0 Received all packets = 0 Use case 7 - Stress PHY Update (TX): PHY updates = 20 Use case 8 - Stress Connect -> Connect Cancel: PHY updates = 20