Home / Embedded-Systems / Study-Guide Comments

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:

      https://github.com/jimyuill/embedded-systems-projects-01/blob/main/book--Hands-On-RTOS/chapter-7--Nucleo_F767ZI_Init--fixed.c

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.

Text

Description automatically generated

      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:

      https://piconomix.com/px-fwlib/_h_e_r_o__b_o_a_r_d__e_x_a_m_p_l_e__f_r_e_e_r_t_o_s__b_l_i_n_k_i_n_g__l_e_d.html

      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:

      https://forum.segger.com/index.php/Thread/7517-SOLVED-Timeline-not-showing-SysTick-or-Scheduler-events/

      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.

Table

Description automatically generated with medium confidence

 

      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.