J-Link FreeRTOS debugging with 64bit TickType_t hangs up

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

    • J-Link FreeRTOS debugging with 64bit TickType_t hangs up

      I'm using FreeRTOS on a STM32H743VI @ 400Mhz.

      My application needs a high resolution task scheduling and timing.

      So I changed the FreeRTOS GCC/ARM_CM7 port by setting TickType_t from uint32_t to uint64_t.
      I also set portTICK_TYPE_IS_ATOMIC to 0 and supplied a highres system timer.
      I have seen the ARM_CA53_64_BIT and RISC_V port of FreeRTOS also using a 64bit TickType_t.

      My Application runs fine and FreeRTOS also seems to have no problem with it.

      I can also debug the application with the TrueSTUDIO debug configuration option
      "Thread-aware RTOS Support" set to "No RTOS".

      If I set the debug support to "RTOS" the debugger hangs when I create the first FreeRTOS
      task and stepping over this location:

      prvAddNewTaskToReadyList() at tasks.c:1,055 : pxCurrentTCB = pxNewTCB;

      The debugger also has problems when I run the application with breakpoints disabled.

      I have included FreeRTOSDebugConfig as described here
      [SOLVED] SEGGER FreeRTOS plugin with FreeRTOS v10.0.0 (no thread found)
      but it seems that FreeRTOSDebugConfig only informs the plugin about relevant field offsets in the TCB_t struct.

      The FreeRTOS ListItem_t and MiniListItem_t structs also contain a TickType_t field.
      For a test I fudged the TickType_t xItemValue field in the list item structures back to uint32_t.

      With this modification the debugger no longer hangs up and I can debug my FreeRTOS tasks.
      Of course with this field size missmatch there will be logical problems on the
      application/FreeRTOS level later on when the tick counter gets bigger than 32bit.

      It seems to me the J-LINK FreeRTOS debug plugin uses additional field offsets into FreeRTOS structures not
      described/adjusted by FreeRTOSDebugConfig and they get out of sync when I change the TickType_t size.

      Any solutions?

      STM32H743VI @ 400Mhz
      FreeRTOS v10.1.1
      Atollic TrueSTUDIO for STM32 V9.3.0
      SEGGER J-Link EDU V10.1
      SEGGER J-Link GDB Server V6.48a Command Line Version
      JLinkARM.dll V6.48a (DLL compiled Jul 30 2019 15:16:09)
      Win7 Pro 64bit

      J-LINK Bug Config and Log files.txt
    • You are correct, FreeRTOSDebugConfig only specifies offsets for TCB_t and not List_t.
      For List_t the plugin only can assume the "standard offsets", so the List_t offsets need
      to be added to FreeRTOSDebugConfig.

      FreeRTOSDebugConfig is maintained by mcuoneclipse, so you might ask there for this

      extension. Alternatively, you can add your own TickType_t to the end of the list while

      leaving a dummy 32bit entry at the original location.

      An additional solution might be to use our debugger Ozone. This debugger has more

      opportunities than the GDB server, because it can directly use the elf-file to calculate
      memory locations.

      Best regards
    • Hi Arne,

      thanks for looking into the issue and confirming the cause of the problem.

      SEGGER - Arne wrote:

      you can add your own TickType_t to the end of the list whileleaving a dummy 32bit entry at the original location.
      I had already tried that but it didnt work.
      Now after taking a closer look at the FreeRTOS code I realized that
      one can only change ListItem_t as you described but must leave
      MiniListItem_t (the head list element) unchanged with a 32bit Ticktype_t xItemValue
      Otherwise one would change the offsets in List_t and in turn the offsets in Queue_t which then
      will will hangup the debugger plugin.
      I also had to make a slight change to the list.c code accessing the MiniListItem_t element.

      With these changes everything seems to be fine and I can debug with a 64bit TickType_t.

      Of course this is just a quick fix working for me.

      I guess FreeRTOS has a general problem by not supplying an debugger API that can be used
      by plug implementers. It should expose concepts not implementation internals as the
      FreeRTOSDebugConfig approach does.

      SEGGER - Arne wrote:

      FreeRTOSDebugConfig is maintained by mcuoneclipse
      An additinal solution might be the use of ouer debugger Osone
      will look into it.

      Thanks for your support.