In this tutorial we will create a basic FreeRTOS project for the STM32F4-Discovery board and will demonstrate various Live Watch views.<\/p>\n
Before you begin, install VisualGDB 5.5 and make sure you are using the Custom edition or higher.<\/p>\n
- \n
- Start Visual Studio and open the VisualGDB Embedded Project Wizard:
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/07\/01-wizard.png\")
<\/a><\/li>\n- Enter the name and location of the project you are going to create:
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/07\/02-rtosdemo.png\")
<\/a><\/li>\n- Proceed with the default settings on the first page of the VisualGDB-specific part of the wizard:
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/07\/03-msbuild-1.png\")
<\/a><\/li>\n- On the next page, select the ARM toolchain and your target device. In this tutorial we will target the STM32F4-Discovery board, so we select the STM32F407VG device:
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/07\/04-device-1.png\")
<\/a><\/li>\n- On the next page, select the LEDBlink (FreeRTOS) sample. You can adjust the LED pins to match your board schematics, or simply proceed with the default settings, as the functionality shown in this tutorial will work without LEDs as well:
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/07\/05-blink.png\")
<\/a><\/li>\n- Finally choose the debugging settings that work with your board and click Finish to create the project:
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/07\/06-stlink.png\")
<\/a><\/li>\n- Once the project is created, press Ctrl-Shift-B to build it:
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/07\/07-built.png\")
<\/a><\/li>\n- Start debugging by pressing F5. Without stopping the project, select Debug->Windows->Live Watch<\/strong> and then switch it to the FreeRTOS mode (requires Custom edition):
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/07\/08-rtos.png\")
<\/a><\/li>\n- The FreeRTOS view contains 4 main groups of nodes: Kernel statistics<\/strong>, Threads<\/strong>, Synchronization Primitives<\/strong> and Heap<\/strong>. We will demonstrate each of these items below. Expand the Kernel<\/strong> node and start plotting the Tick Count<\/strong> variable. VisualGDB will show how the tick count is increasing over time:
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/07\/09-stats.png\")
<\/a><\/li>\n- Now expand the Threads<\/strong> node and locate LED2 in the list. See how its state changes between Delayed<\/strong> and Suspended<\/strong> as the LED1 thread keeps suspending and resuming it. Note that as none of the threads is doing any heavy computation, the IDLE<\/strong> thread remains active each time VisualGDB samples the thread state:
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/07\/10-threads.png\")
<\/a><\/li>\n- Now we will show how to monitor the stack usage by FreeRTOS threads. Add a RecursionTest()<\/strong> function and modify LED_Thread2()<\/strong> to call it:\n
void RecursionTest(int level)\r\n{\r\n volatile int x[5];\r\n x[0]++;\r\n if (level > 0)\r\n RecursionTest(level - 1);\r\n else\r\n\tosDelay(200);\r\n}\r\n\r\nstatic void LED_Thread2(void const *argument)\r\n{\r\n uint32_t count;\r\n (void) argument;\r\n \r\n for (;;)\r\n {\r\n RecursionTest(1);\r\n RecursionTest(2);\r\n RecursionTest(3);\r\n RecursionTest(4);\r\n RecursionTest(5);\r\n }\r\n}<\/pre>\nThen set a breakpoint at the first call to RecursionTest()<\/strong>, start debugging and let the breakpoint trigger:
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/07\/11-usage.png\")
<\/a><\/li>\n- Locate the LED2 thread in the Live Watch view and start plotting its stack usage<\/strong> and highest stack usage<\/strong>. See how the stack usage keeps increasing together with the recursion level, and the highest stack usage reaches the maximum and remains the same:
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/07\/12-usage2.png\")
<\/a>The current stack usage is sampled based from the saved stack pointer in the thread control block, so it will not be accurate while the thread is currently running. The highest stack usage is computed by scanning the memory region allocated for the stack and checking which parts of it have overwritten the initial padding value.<\/li>\n- Now we will show how to view the state of various synchronization primitives. Add a new Plain C file to the project (e.g. SemaphoreTests.c<\/strong>) and add the following code to it:\n
#include <cmsis_os.h>\r\n#include <stm32f4xx_hal.h>\r\nstatic xSemaphoreHandle s_DemoSemaphore;\r\n\r\nstatic void SenderThreadBody()\r\n{\r\n for (;;)\r\n {\r\n for (int i = 0; i < 5; i++)\r\n xSemaphoreGive(s_DemoSemaphore);\r\n osDelay(10000);\r\n }\r\n}\r\n\r\nstatic void ReceiverThreadBody()\r\n{\r\n for (;;)\r\n {\r\n xSemaphoreTake(s_DemoSemaphore, portMAX_DELAY);\r\n osDelay(1000);\r\n }\r\n}\r\n\r\nvoid StartSemaphoreTestThreads()\r\n{\r\n TaskHandle_t task;\r\n\r\n s_DemoSemaphore = xSemaphoreCreateCounting(100, 0);\r\n xTaskCreate(SenderThreadBody, \"Sender\", 128, 0, 1, &task);\r\n xTaskCreate(ReceiverThreadBody, \"Receiver\", 128, 0, 1, &task);\r\n}<\/pre>\nThen call StartSemaphoreTestThreads()<\/strong> from the main source file just before the call to osKernelStart()<\/strong>. If you start debugging now, VisualGDB will show s_DemoSemaphore<\/strong> in the Synchronization Primitives<\/strong> view:
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/07\/13-sync.png\")
<\/a><\/li>\n- You can plot the current value of the semaphore. VisualGDB will show how it increases to 4 as the sender thread releases it 5 times (it’s immediately taken by the receiver, so the value of 5 never stays long enough to be sampled) and then slowly drops to 0:
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/07\/14-sema.png\")
<\/a>Live Watch will also show the threads waiting for a semaphore or a queue, and the mutexes owning a mutex.<\/li>\n- Finally, we will show how to observe the state of FreeRTOS heap. Modify LED_Thread1() as shown below:\n
char *test = (char *)pvPortMalloc(16);\r\n memset(test, 0x55, 16);\r\n HAL_GPIO_WritePin(GPIOD, GPIO_PIN_12, GPIO_PIN_SET);\r\n\t\tosDelay(2000);\r\n vPortFree(test);<\/pre>\n
Then start debugging and begin plotting the Heap -> Allocated Blocks<\/strong> metric:
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/07\/15-graph.png\")
<\/a>VisualGDB will show how it switches between 14 and 15, as the thread keeps allocating and releasing the memory.<\/li>\n- You can also view individual heap blocks. Expand the [Heap Blocks]<\/strong> node and go to the end of the list:
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/07\/16-blocks.png\")
<\/a><\/li>\n- The block allocated from LED_Thread1()<\/strong> will appear at the end of the list, showing the correct contents:
![\"\"](\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/07\/17-55.png\")
<\/a><\/li>\n<\/ol>\nThe FreeRTOS-specific logic of Live Watch is implemented in a separate open-source plugin<\/a>, so you can fork and extend it to support any project-specific functionality you would like to monitor.<\/p>\n
- Enter the name and location of the project you are going to create: