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?

Setup:
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

Hi Arne,

thanks for looking into the issue and confirming the cause of the problem.
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
field.
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.

will look into it.


Thanks for your support.