Chapter 7: bugs, clarifications, and tips
11/3/2021
Document versions
● 10/18/2021: initial version
● 11/3/2021: added:
o Bug in the book and code (Nucleo_F767ZI_Init.c), page 158
Chapter 7: The FreeRTOS Scheduler (pg 153)
● Tip, page 155
o SEGGER_SYSVIEW_PrintfHost() has a number of bugs, and it is not documented adequately.
o The study-guide's web-page on SystemView has a section on SEGGER_SYSVIEW_PrintfHost(). It describes those bugs and provides some of the omitted documentation.
o There are no bugs in SEGGER_SYSVIEW_PrintfHost(), for the call to it here on page 155.
● Tip, page 155
o Code shown: vTaskDelay(1500/ portTICK_PERIOD_MS);
o The IDE can be used to track-down the value of portTICK_PERIOD_MS. Right-click on the variable and select "Open Declaration".
o So, portTICK_PERIOD_MS is 1 ms:
#define portTICK_PERIOD_MS ( ( TickType_t ) 1000 / configTICK_RATE_HZ )
#define configTICK_RATE_HZ ((TickType_t)1000)
o And, vTaskDelay(1500/ portTICK_PERIOD_MS) will delay for 1.5 seconds
● Tip, page 158
o The book states, "The x prefix of xTaskCreation signifies that it returns something."
o This prefix-use is from the FreeRTOS naming conventions, which are defined here:
■ https://www.freertos.org/FreeRTOS-Coding-Standard-and-Style-Guide.html#NamingConventions
● Bug in the book and code (Nucleo_F767ZI_Init.c), page 158
o Problem:
■ There is a bug in the function call:
SEGGER_SYSVIEW_PrintfHost("Assertion Failed:file %s \ ...)
■ That SystemView function does not support the format-placeholder "%s" .
■ When "%s" is used, the function will compile and run. However, no string will be displayed for it in the SystemView app, e.g., in the Terminal window.
■ Also, the function-call's line-continuation is incorrect, as it inadvertently inserts extra blanks into the output-string.
o Solution:
■ One solution is to use snprintf() to create the output-string. Then, use SEGGER_SYSVIEW_PrintfHost() to display that output-string on the SystemView app.
■ This solution is implemented here:
o Additional info:
■ SEGGER_SYSVIEW_PrintfHost() has a number of bugs, and it is not documented adequately.
■ The present study-guide has a web-page on SystemView, and it includes a section on SEGGER_SYSVIEW_PrintfHost(). That section describes those bugs, and it provides some of the omitted documentation.
● Clarification, page 159
o xTaskCreateStatic() has not yet been described. A description is on page 165.
● Bug in the book's code (Chapter_7.jdebug), page 163
o This file has the same bugs that were described for Chapters5_6.jdebug, in the web-page for Chapters 4-6.
● Clarification, page 163
o When opening the project in Ozone, there is a red-colored warning-message:
Warning (98): The symbol location decoder encountered an unsupported operand: 0xFA.
o It appears the warning can be ignored, as the system seems to work OK anyway.
o I couldn't find a posted solution on the Internet, for this warning.
o The warning message is documented in the Ozone User Guide:
■ The rightmost table-entry is just an example fix.
■ In an attempt to fix the warning, I generated 3 builds, and specified DWARF versions 2, 3, and 4, respectively, but none of those builds removed the warning.
● Bug in the book (missing info), page 163
o "After that, experiment with using Ozone to load and single-step through the program (details on how to do this were covered in Chapter 6, Debugging Tools for Real-Time Systems)."
o I could not find anything in Chapter 6, or elsewhere, that describes how to use Ozone to step through the code or set breakpoints. That info is provided below.
● Additional info, page 163
o Info on using the Ozone debugger:
o Breakpoints
■ Set breakpoints by clicking on a source or assembly instruction, then:
● Press F9, or Right click
■ A breakpoint can be removed by:
● Clicking on it, then press F9, or
● Use View to open the frame "Breakpoints and Tracepoints"
■ Breakpoint problems and trouble-shooting:
● It may be possible to inadvertently set breakpoints in library code.
o To find and remove them:
■ Use the View menu to open the frame "Breakpoints and Tracepoints"
● The maximum number of breakpoints is limited.
o Setting a breakpoint for a C instruction results in "derived breakpoints" for each of its assembly instructions.
o It may be possible to reduce the number of breakpoints by setting them for assembly instructions instead of C instructions.
o Stepping through the code:
■ Click on the Debug menu to see the options
o More info is in the Ozone User Guide
● Bug in the book (missing info), page 163
o Problem:
■ A key requirement in using SystemView appears to be omitted in the book:
● SystemView's Record feature should not be started until after the scheduler is started on the board, i.e., until after vTaskStartScheduler()runs.
■ From my testing,
● SystemView's Record feature will not record any events if it is started before the scheduler is started.
● SystemView itself can be started at anytime. However, the Record feature should not be started before the scheduler.
o Reference info:
■ The requirement is also stated at this web-page, and described:
● All SystemView events must be timestamped correctly and the usual solution is to piggy-back on the SysTick peripheral interrupt. Unfortunately the SysTick peripheral is only initialized when the FreeRTOS scheduler is started with a call to vTaskStartScheduler(). All SystemView events before this will be timestamped with a zero value and it confuses the Segger SystemView GUI.
● The timestamping mechanism must be initialized and running correctly before logging any SystemView events. Timestamps must have sequential incrementing values otherwise the GUI will be get confused.
■ The Segger forums contain corroborating info:
● The Segger SystemView GUI is not able to cope with events that are not timestamped properly (sequentially).
● Bug in the book (missing info) and in the code (main_taskCreation.c), page 163
o Problem:
■ The book's figure shows using SystemView to record the three tasks in main_taskCreation.c. A recording like that does not seem possible, with the code and instructions provided.
■ SystemView's Record feature would have to be started after the scheduler is started, but before GreenTask() runs. This is effectively impossible. (Though, there may be a technique for this that I'm not aware of.)
o Solution:
■ One solution is to make GreenTask() spin when it starts, to allow time for starting SystemView.
■ This can be done by adding the following line to the beginning of GreenTask(). The task will spin until the User button is pushed, on the board.
● while(!ReadPushButton());
■ The target program would be started via Ozone, then SystemView would be started, then its Record feature.
■ A limitation of this solution is that SystemView's Record does not show GreenTask as running when its SEGGER_SYSVIEW_PrintfHost() is run. This is shown in the figure below. The blue vertical line is where that SEGGER_SYSVIEW_PrintfHost() ran, but no task is shown as running.
■ Apparently, when SystemView's Record is first started, the currently-running task is not highlighted in the display. When the scheduler switches to another task, that task will be highlighted. In the figure below, it is BlueTask.
● Bug in the code (main_taskCreation.c), page 163
o There's a minor bug in GreenTask().
o In the call to SEGGER_SYSVIEW_PrintfHost(), the string is misformatted, with unintended spaces. In SystemView's Terminal window , the text after the line-continuation isn't visible, or it is not readily visible.
SEGGER_SYSVIEW_PrintfHost("Task1 running \
while Green LED is on\n");
o The fix is to remove the line-continuation, and put the whole string on one line.
● Tip, page 172f
o To run main_FailedStartup.c, and step through it:
■ In Chapter_7.jdebug, set File.Open() to the path for Chapter_7_FailedStartupBuild.elf, e.g.,
File.Open ("C:\projects\packtBookRTOS\Chapter_7\FailedStartupBuild\Chapter_7_FailedStartupBuild.elf");
■ In the IDE, set the active build configuration:
● Then, Clean Project and Build Project
● In Ozone, the code can be traced by setting breakpoints in:
o C:\projects\packtBookRTOS\Chapter_7\Src\main_FailedStartup.c
o C:\projects\packtBookRTOS\BSP\Nucleo_F767ZI_Init.c
■ This file contains assert_failed()
● Bug in the book and code (Nucleo_F767ZI_Init.c), page 173
o There is a bug in the function call:
SEGGER_SYSVIEW_PrintfHost("Assertion Failed:file %s \ ...)
o The same bug was described earlier, for page 158.