[SOLVED] Thread - aware RTOS support / corrupted thread records

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] Thread - aware RTOS support / corrupted thread records

    Hello,

    How can I verify that j-link thread-aware FreeRTOOS debugging works correctly?

    On some point of debugging I see corrupted thread records is "call stack"/"Debug" window.

    But after a while (several thread switches) it becomes normal.

    The other "NXP" and "Attolic" FreeRTOOS plugins have no issues to show set of threads.

    I'm using FreeRTOOS 9.0.0 on STM32F429

    Is there any known issue?
    Images
    • Thread read issue.jpg

      234.17 kB, 2,133×856, viewed 953 times
  • Hello Aseris,

    the recent version (v6.32i) uses FreeRTOSDebugConfig instead of other sources to acquire information about the tasks.
    Could you please try this version and check if it solves this issue?

    Best regards
    Arne
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • I'm already use v6.31i

    The command line for GDB server start:

    "C:\Program Files (x86)\SEGGER\JLink_V632i\JLinkGDBServerCL.exe" -port 2331 -s -CPU Cortex-M -device STM32F429VE -endian little -speed 4000 -if swd -vd -rtos "C:\Program Files (x86)\SEGGER\JLink_V632i\GDBServer\RTOSPlugin_FreeRTOS.dll"


    I'm using -Og optimization level and

    nest OS config:
    #define configMAX_TASK_NAME_LEN ( 15 )
    #define configMAX_PRIORITIES ( 7 )
    #define configUSE_TRACE_FACILITY 1
    #define configUSE_16_BIT_TICKS 0
    #define configIDLE_SHOULD_YIELD 1
    #define configUSE_MUTEXES 1
    #define configQUEUE_REGISTRY_SIZE 50
    #define configCHECK_FOR_STACK_OVERFLOW 2
    #define configUSE_RECURSIVE_MUTEXES 1
    #define configUSE_MALLOC_FAILED_HOOK 1
    #define configUSE_APPLICATION_TASK_TAG 0
    #define configUSE_COUNTING_SEMAPHORES 1
    #define configGENERATE_RUN_TIME_STATS 0
    #define configUSE_PORT_OPTIMISED_TASK_SELECTION 1
    #define configUSE_TICKLESS_IDLE 0
    #define configUSE_TASK_NOTIFICATIONS 1

    #define configUSE_TASK_FPU_SUPPORT 1

    #define configNUM_THREAD_LOCAL_STORAGE_POINTERS 5


    It seems there is an issue with Miss-aligned memory reads by plugin:

    Lost the name of thread 12


    log1.txt

    Garbage in thread 11 name as on snapshot:

    log2.txt

    After a while all ok:

    log3.txt

    The post was edited 1 time, last by Aseris ().

  • Also I see suspicious reads:

    ...Breakpoint reached @ address 0x080255A8
    WARNING: Mis-aligned memory read: Address: 0x0000002D, NumBytes: 4, Alignment: 4 (Word-aligned)
    WARNING: Failed to read memory @ address 0x4B080067
    ERROR: Error reading thread name in FreeRTOS task control block.
    Reading all registers
    Read 4 bytes @ address 0x080255A8 (Data = 0xF7ED200A)
    Removing breakpoint @ address 0x080255A2, Size = 2

    Is there any documented sequence about plugin readings?

    Why I'm asking - I try to catch very rare system hang error, and do not know if this behavior caused by Freertos plugin issue or by memory leak in program.

    Also I check TCB's of all threads, the threads names stay unchanged.
  • The important part is at the beginning of the log where it shows which symbols were loaded.

    configUSE_PORT_OPTIMISED_TASK_SELECTION caused problems, but should not be a problem in recent builds where FreeRTOSDebugConfig is evaluated.


    Could you please post the part of the GDB server log right at the beginning?


    Should be similar to this one:


    Source Code

    1. RTOS plugin (API v1.0)
    2. loaded successfully
    3. RTOS plugin initialized successfully.
    4. Received symbol: pxCurrentTCB (0x2000757C)
    5. Received symbol: pxReadyTasksLists (0x20007580)
    6. Received symbol: xDelayedTaskList1 (0x20007620)
    7. Received symbol: xDelayedTaskList2 (0x20007634)
    8. Received symbol: pxDelayedTaskList (0x20007648)
    9. Received symbol: pxOverflowDelayedTaskList (0x2000764C)
    10. Received symbol: xPendingReadyList (0x20007650)
    11. Received symbol: xTasksWaitingTermination (0x20007664)
    12. Received symbol: xSuspendedTaskList (0x2000767C)
    13. Received symbol: uxCurrentNumberOfTasks (0x20007690)
    14. Received symbol: uxTopUsedPriority (0x000057E0)
    15. Received symbol: uxTopReadyPriority (0x20007698)
    16. Received symbol: vPortEnableVFP (0x00000FA8)
    17. Received symbol: FreeRTOSDebugConfig (0x000057EC)
    18. All mandatory symbols successfully loaded.
    Display All
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Source Code

    1. Loading RTOS plugin: C:\Program Files (x86)\SEGGER\JLink_V632i\GDBServer\RTOSPlugin_FreeRTOS.dll...
    2. RTOS plugin (v1.0) loaded successfully
    3. RTOS plugin initialized successfully.
    4. Received symbol: pxCurrentTCB (0x20020F54)
    5. Received symbol: pxReadyTasksLists (0x20020F60)
    6. Received symbol: xDelayedTaskList1 (0x20021000)
    7. Received symbol: xDelayedTaskList2 (0x20021014)
    8. Received symbol: pxDelayedTaskList (0x20020F58)
    9. Received symbol: pxOverflowDelayedTaskList (0x20020F5C)
    10. Received symbol: xPendingReadyList (0x20021034)
    11. Received symbol: xTasksWaitingTermination (0x00000000)
    12. Received symbol: xSuspendedTaskList (0x2002104C)
    13. Received symbol: uxCurrentNumberOfTasks (0x20020FEC)
    14. Received symbol: uxTopUsedPriority (0x00000000)
    15. Received symbol: uxTopReadyPriority (0x20020FFC)
    16. Received symbol: vPortEnableVFP (0x08011290)
    17. All mandatory symbols successfully loaded.
    Display All
  • Also, this is my startup script.

    Coud it be an issue if I load two elf with FreeRTOS?

    Source Code

    1. # Default GDB command file (FLASH) for SEGGER J-LINK and STMicroelectronics STM32F429VE microcontroller.
    2. # Set character encoding
    3. set host-charset CP1252
    4. set target-charset CP1252
    5. # Set JTAG speed to 30 kHz
    6. monitor speed 30
    7. # Set GDBServer to little endian
    8. monitor endian little
    9. # Reset the chip to get to a known state.
    10. monitor reset
    11. # Set auto JTAG speed
    12. monitor speed auto
    13. # Setup GDB FOR FASTER DOWNLOADS
    14. set remote memory-write-packet-size 1024
    15. set remote memory-write-packet-size fixed
    16. # Enable flash download
    17. #monitor flash download = 1
    18. # Load the program executable
    19. # Load the bootloader executable
    20. load _BL.elf
    21. #setup project file
    22. file ./Release_Test/Application.elf
    23. load
    24. #stop IWDG on debug
    25. set *0xE0042008 = (*0xE0042008) | 0x00001000
    26. add-symbol-file ./Release_Test/Application.elf 0x0800c3b0
    27. # Reset the chip to get to a known state. Remove "monitor reset" command
    28. # if the code is not located at default address and does not run by reset.
    29. monitor reset
    30. # Set a breakpoint at main().
    31. tbreak main
    32. # Run to the breakpoint.
    33. t 2
    34. continue
    Display All
  • After fast tests it seems that root cause in configUSE_PORT_OPTIMISED_TASK_SELECTION 1.
    It seems that plugin incorrectly interprets data in case when configUSE_PORT_OPTIMISED_TASK_SELECTION 1 configuration.

    Simmilar issues:
    [SOLVED] J-Link FreeRTOS version 10 support (GDBServer/RTOSPlugin_FreeRTOS), priority read-out issue...
    [SOLVED] JLinkGDBServer FreeRTOS ThreadAwareness and configMAX_PRIORITIES
    [ABANDONED] WARNING: Mis-aligned memory read (J-Link V618a on re-flashed STM32F3Discovery)

    So, now question is: Is it only Plugin issue or it is bug in port realization... ?(

    Also, what does it mean "FreeRTOSDebugConfig" I cant found any info on freeertos.org neither in J-Link User guide. Just found some code MCUXpresso IDE FreeRTOSDebug Guide freertos_tasks_c_additions.h. Is that a missing part in my project?
  • Setting configUSE_PORT_OPTIMISED_TASK_SELECTION to 0 will solve the problem, because this makes it possible for the plug-in to
    gather all necessary information. The freertos_tasks_c_additions.h also contains the necessary information and is independent of
    other configuration options, so in general I would recommend to use this way.

    Obviously the change to evaluate FreeRTOSDebugConfig did not make it into the last release of our software.
    It will be part of the next release.

    Is "freertos_tasks_c_additions.h" a proprietary extension to FreeRTOS? I thought it is part of the current FreeRTOS distribution.
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Aseris wrote:

    Also, what does it mean "FreeRTOSDebugConfig" I cant found any info on freeertos.org neither in J-Link User guide. Just found some code MCUXpresso IDE FreeRTOSDebug Guide freertos_tasks_c_additions.h. Is that a missing part in my project
    freertos_tasks_c_additions.h has a BSD license, so feel free to add it to your project. Probably it will make its way into one of the next FreeRTOS distributions.
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.