Kinetis Design StudioのトピックBUG: KDS debug call-stack fails with Segger JLink

BUG: KDS debug call-stack fails with Segger JLink

davenadler — Tue, 06 Dec 2016 23:25:44 GMT

K64F Freedom board, KDS 3.2.0 with all available updates installed, Windows 8 64-bit host.

Latest J-link updates are installed: JLink_V612a dated 2-December (KDS and J-link firmware both updated).
While KDS mostly works for an LED blinky application we're having serious problems with anything non-trivial (like our application).

We gave up on the NXP-provided OpenSDA SWD interface as it was too slow and buggy.
Purchased a couple of Segger J-Link Base units, cut the required traces on the Freedom board, and gave it a try...

Many things work for my C/C++ application; with J-Link I can:

- download into flash (15x faster than NXP-provided programming),
- start a debug session,
- operate breakpoints
- examine variables (both stack and static)
- pause and continue execution
- single step

Unfortunately I cannot:
- see a stack call trace when the program is paused (though it shows the current routine)

Here's a snapshot of an assert infinite loop I paused showing missing stack call trace

Segger reproduced the problem and suggested adding the following option in the debugger configuration "other options" field: -RTOS GDBserver/RTOSPlugin_FreeRTOS

Unfortunately that results in the debugger crashing first time it hits a breakpoint:

Is there any hope of getting this fixed?

Would you recommend using a different development environment for non-trivial applications on K64F?

Thanks,
Best Regards, Dave

Re: BUG: KDS debug call-stack fails with Segger JLink

BlackNight — Wed, 07 Dec 2016 07:31:00 GMT

Hi Dave,

I have not faced such an issue, and I'm using that functionality on a daily base with complex projects.

I'm using

SEGGER J-Link GDB Server V6.12a Command Line Version

JLinkARM.dll V6.12a (DLL compiled Dec 2 2016 16:44:26)

with the original GDB of KDS V3.2.0:

GNU gdb (GNU Tools for ARM Embedded Processors) 7.6.0.20140731-cvs

(you get the above information in the console view).

One thing you could check is the output of the console for Segger and the FreeRTOS plugin, see Adding FreeRTOS Thread Awareness to GDB and Eclipse | MCU on Eclipse

The plugin needs some data structures in the FreeRTOS kernel available to work best. I have posted my log below as a reference. Other than that, because this is a crash in the Segger library (which is owned by Segger, and I'm sure they want to fix it), have you reported this on the Segger forum already? Segger is very responsive.

I hope this helps,

Erich

SEGGER J-Link GDB Server V6.12a Command Line Version

JLinkARM.dll V6.12a (DLL compiled Dec 2 2016 16:44:26)

-----GDB Server start settings-----
GDBInit file:                  none
GDB Server Listening port:     2331
SWO raw output listening port: 2332
Terminal I/O port:             2333
Accept remote connection:      localhost only
Generate logfile:              off
Verify download:               on
Init regs on start:            on
Silent mode:                   off
Single run mode:               on
Target connection timeout:     0 ms
------J-Link related settings------
J-Link Host interface:         USB
J-Link script:                 none
J-Link settings file:          none
------Target related settings------
Target device:                 MK22FX512xxx12
Target interface:              SWD
Target interface speed:        1000kHz
Target endian:                 little

Connecting to J-Link...
J-Link is connected.
Firmware: J-Link OpenSDA 2 compiled Oct 13 2015 12:10:27
Hardware: V1.00
S/N: 621000000
Checking target voltage...
Target voltage: 3.30 V
Listening on TCP/IP port 2331
Connecting to target...Connected to target
Waiting for GDB connection...Connected to 127.0.0.1
Reading all registers
Read 4 bytes @ address 0x00000000 (Data = 0x20000000)
Target interface speed set to 1000 kHz
Resetting target
Halting target CPU...
...Target halted (PC = 0x00005F78)
R0 = 00000000, R1 = 00000000, R2 = 00000000, R3 = 00000000
R4 = 00000000, R5 = 00000000, R6 = 00000000, R7 = 00000000
R8 = 00000000, R9 = 00000000, R10= 00000000, R11= 00000000
R12= 00000000, R13= 20000000, MSP= 20000000, PSP= 00000000
R14(LR) = FFFFFFFF, R15(PC) = 00005F78
XPSR 01000000, APSR 00000000, EPSR 01000000, IPSR 00000000
CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00
Reading all registers
Select auto target interface speed (1429 kHz)
Flash breakpoints enabled
Loading RTOS plugin: GDBServer/RTOSPlugin_FreeRTOS...
RTOS plugin (v1.0) loaded successfully
RTOS plugin initialized successfully.
Received symbol: pxCurrentTCB (1FFFE414)
Received symbol: pxReadyTasksLists (1FFFE418)
Received symbol: xDelayedTaskList1 (1FFFE490)
Received symbol: xDelayedTaskList2 (1FFFE4A4)
Received symbol: pxDelayedTaskList (1FFFE4B8)
Received symbol: pxOverflowDelayedTaskList (1FFFE4BC)
Received symbol: xPendingReadyList (1FFFE4C0)
Received symbol: xTasksWaitingTermination (1FFFE4D4)
Received symbol: xSuspendedTaskList (1FFFE4EC)
Received symbol: uxCurrentNumberOfTasks (1FFFE500)
Received symbol: uxTopUsedPriority (1FFF8088)
Received symbol: uxTopReadyPriority (1FFFE508)
Received symbol: vPortEnableVFP (00011ED8)
All mandatory symbols successfully loaded.
All mandatory symbols successfully loaded.
Downloading 392 bytes @ address 0x00000000 - Verified OK
Downloading 16 bytes @ address 0x00000400 - Verified OK
Downloading 16128 bytes @ address 0x00000410 - Verified OK
Downloading 16128 bytes @ address 0x00004310 - Verified OK
Downloading 16128 bytes @ address 0x00008210 - Verified OK
Downloading 16176 bytes @ address 0x0000C110 - Verified OK
Downloading 16080 bytes @ address 0x00010040 - Verified OK
Downloading 16048 bytes @ address 0x00013F10 - Verified OK
Downloading 11232 bytes @ address 0x00017DC0 - Verified OK
Downloading 8 bytes @ address 0x0001A9A0 - Verified OK
Downloading 4 bytes @ address 0x0001A9A8 - Verified OK
Downloading 4 bytes @ address 0x0001A9AC - Verified OK
Downloading 472 bytes @ address 0x0001A9B0 - Verified OK
Downloading 36 bytes @ address 0x0001AB88 - Verified OK
Resetting target
Halting target CPU...
...Target halted (PC = 0x00005F78)
Sleep 500ms
Read 4 bytes @ address 0x00005F78 (Data = 0x46204C0B)
Read 2 bytes @ address 0x00005DBC (Data = 0xF002)
Read 2 bytes @ address 0x00005DBC (Data = 0xF002)
Read 2 bytes @ address 0x00005DBC (Data = 0xF002)
R0 = 00000000, R1 = 00000000, R2 = 00000000, R3 = 00000000
R4 = 00000000, R5 = 00000000, R6 = 00000000, R7 = 00000000
R8 = 00000000, R9 = 00000000, R10= 00000000, R11= 00000000
R12= 00000000, R13= 20000000, MSP= 20000000, PSP= 00000000
R14(LR) = FFFFFFFF, R15(PC) = 00005F78
XPSR 01000000, APSR 00000000, EPSR 01000000, IPSR 00000000
CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00
Reading all registers
ERROR: Task not found.
Reading all registers
Read 4 bytes @ address 0x00005F78 (Data = 0x46204C0B)
Setting breakpoint @ address 0x00005DBC, Size = 2, BPHandle = 0x0001
Starting target CPU...
...Breakpoint reached @ address 0x00005DBC
Reading all registers
Removing breakpoint @ address 0x00005DBC, Size = 2
Read 4 bytes @ address 0x00005DBC (Data = 0xFF98F002)
Reading 64 bytes @ address 0x1FFFFFC0
Starting target CPU...
Debugger requested to halt target...
...Target halted (PC = 0x00013BA0)
Reading all registers
Read 4 bytes @ address 0x00013BA0 (Data = 0x2B00681B)
Reading 64 bytes @ address 0x1FFFCB00
Reading all registers
Read 4 bytes @ address 0x00012044 (Data = 0xF85D46BD)
Reading all registers
Read 4 bytes @ address 0x00012044 (Data = 0xF85D46BD)
Reading all registers
Read 4 bytes @ address 0x00012044 (Data = 0xF85D46BD)
Reading all registers
Read 4 bytes @ address 0x00012044 (Data = 0xF85D46BD)
Reading all registers
Read 4 bytes @ address 0x00012044 (Data = 0xF85D46BD)
Reading all registers
Read 4 bytes @ address 0x00012044 (Data = 0xF85D46BD)
Reading all registers
Read 4 bytes @ address 0x00012044 (Data = 0xF85D46BD)
Read 4 bytes @ address 0x00013BA0 (Data = 0x2B00681B)
Read 4 bytes @ address 0x00013AB0 (Data = 0x681B4B04)
Read 4 bytes @ address 0x00000000 (Data = 0x20000000)
Read 4 bytes @ address 0x00012044 (Data = 0xF85D46BD)
Read 4 bytes @ address 0x00013BA0 (Data = 0x2B00681B)
Read 4 bytes @ address 0x00012044 (Data = 0xF85D46BD)
Read 4 bytes @ address 0x00013BA0 (Data = 0x2B00681B)
Read 4 bytes @ address 0x00012044 (Data = 0xF85D46BD)
Read 4 bytes @ address 0x00013BA0 (Data = 0x2B00681B)
Read 4 bytes @ address 0x00012044 (Data = 0xF85D46BD)
Read 4 bytes @ address 0x00013BA0 (Data = 0x2B00681B)
Read 4 bytes @ address 0x00012044 (Data = 0xF85D46BD)
Read 4 bytes @ address 0x00013BA0 (Data = 0x2B00681B)
Read 4 bytes @ address 0x00012044 (Data = 0xF85D46BD)
Read 4 bytes @ address 0x00013BA0 (Data = 0x2B00681B)
Read 4 bytes @ address 0x00012044 (Data = 0xF85D46BD)
Read 4 bytes @ address 0x00013BA0 (Data = 0x2B00681B)
Read 4 bytes @ address 0x00013AB0 (Data = 0x681B4B04)
Read 4 bytes @ address 0x00000000 (Data = 0x20000000)
Starting target CPU...
Debugger requested to halt target...
...Target halted (PC = 0x000038D0)
Reading all registers
Read 4 bytes @ address 0x000038D0 (Data = 0x4A187BBB)
Reading 64 bytes @ address 0x1FFFB580
Read 4 bytes @ address 0x000039D0 (Data = 0x617B2300)
Reading 64 bytes @ address 0x1FFFB5C0
Read 4 bytes @ address 0x00003C54 (Data = 0x49094808)
Read 4 bytes @ address 0x00004304 (Data = 0x681B4B0B)
Read 4 bytes @ address 0x0000435C (Data = 0xF00E200A)
Reading 64 bytes @ address 0x1FFFB600
Read 4 bytes @ address 0x00000000 (Data = 0x20000000)
Reading all registers
Read 4 bytes @ address 0x00012044 (Data = 0xF85D46BD)
Read 4 bytes @ address 0x000038D0 (Data = 0x4A187BBB)
Reading all registers
Read 4 bytes @ address 0x00012044 (Data = 0xF85D46BD)
Read 4 bytes @ address 0x000038D0 (Data = 0x4A187BBB)
Reading all registers
Read 4 bytes @ address 0x00012044 (Data = 0xF85D46BD)
Read 4 bytes @ address 0x000038D0 (Data = 0x4A187BBB)
Reading all registers
Read 4 bytes @ address 0x00012044 (Data = 0xF85D46BD)
Read 4 bytes @ address 0x000038D0 (Data = 0x4A187BBB)
Reading all registers
Read 4 bytes @ address 0x00012044 (Data = 0xF85D46BD)
Read 4 bytes @ address 0x000038D0 (Data = 0x4A187BBB)
Reading all registers
Read 4 bytes @ address 0x00012044 (Data = 0xF85D46BD)
Read 4 bytes @ address 0x000038D0 (Data = 0x4A187BBB)
Reading all registers
Read 4 bytes @ address 0x00012044 (Data = 0xF85D46BD)
Read 4 bytes @ address 0x000038D0 (Data = 0x4A187BBB)
Read 4 bytes @ address 0x00012044 (Data = 0xF85D46BD)
Read 4 bytes @ address 0x00013ABC (Data = 0xF950F7F2)
Reading 64 bytes @ address 0x1FFFCB00
Read 4 bytes @ address 0x00000000 (Data = 0x20000000)
Read 4 bytes @ address 0x000038D0 (Data = 0x4A187BBB)
Reading 64 bytes @ address 0x1FFFB580
Read 4 bytes @ address 0x000039D0 (Data = 0x617B2300)
Reading 64 bytes @ address 0x1FFFB5C0
Read 4 bytes @ address 0x00003C54 (Data = 0x49094808)
Read 4 bytes @ address 0x00004304 (Data = 0x681B4B0B)
Read 4 bytes @ address 0x0000435C (Data = 0xF00E200A)
Reading 64 bytes @ address 0x1FFFB600
Read 4 bytes @ address 0x00000000 (Data = 0x20000000)
Read 4 bytes @ address 0x00012044 (Data = 0xF85D46BD)
Read 4 bytes @ address 0x00013ABC (Data = 0xF950F7F2)
Reading 64 bytes @ address 0x1FFFCB00
Read 4 bytes @ address 0x00000000 (Data = 0x20000000)

Re: BUG: KDS debug call-stack fails with Segger JLink

davenadler — Wed, 07 Dec 2016 14:37:11 GMT

Thanks Erich, yes reported to Segger, who have confirmed this morning they can reproduce the problem...

Re: BUG: KDS debug call-stack fails with Segger JLink

davenadler — Wed, 14 Dec 2016 19:16:53 GMT

This morning Segger confirmed this is an NXP bug; KDS call stack display for FreeRTOS tasks fails on Windows versions after version 7:

Hi Dave, after some investigation, it turned out this depends on the operating system. With windows 7, the call stack is correctly shown and using windows 10 it fails the same way as in your screenshot. I'd like to think this is display error caused by eclipse, so NXP would be in charge of fixing this bug. From our side, the GDB server is behaving correctly. Best regards, Arne

Here's an example of the FreeRTOS task viewer showing multiple threads (tasks), with no call stack information (just shows the point where the thread is blocked instead of the complete call stack):

From Segger, here's and example of a correct display on Windows 7:

NXP - Any hope of getting this fixed??

Thanks,
Best Regards, Dave

Re: BUG: KDS debug call-stack fails with Segger JLink

BlackNight — Wed, 14 Dec 2016 20:11:51 GMT

Hi Dave

interesting point about Windows 7 vs. Windows 10. It is only that I have not seen this on my end, and I'm using Windows 10. You had reported a crash above in the Segger library, so are you saying that Segger has already fixed that? This is not clear from your screenshot. Neverless, if you can upload your project I could give it a try on my side. If you don't want to share it publicly, you can send it to my email address noted on About and I'll have a look (I assume you are using a FRDM-K64F, correct?).

The other thought I have is this: have you already configured this in FreeRTOSConfig.h

#define configTASK_RETURN_ADDRESS 0 /* return address of task is zero */

Because this terminates the stack with a zero return address. Otherwise, depending on the GDB version, this can confuse GDB (still, the Segger DLL shall not crash). That setting is discussed here as well: https://community.nxp.com/thread/335076 and I always have that macro set to zero.

I hope this helps,

Erich

Re: BUG: KDS debug call-stack fails with Segger JLink

davenadler — Wed, 14 Dec 2016 20:32:28 GMT

Apologies Erich, I skipped a few steps required to avoid crashing and get FreeRTOS task viewer functioning; this from Segger. I've done all of these:

Set configUSE_PORT_OPTIMISED_TASK_SELECTION to 0
Added to the debugger options: -RTOS GDBserver/RTOSPlugin_FreeRTOS
Create a dummy symbol uxTopUsedPriority (will be preferred to uxTopReadyPriority) and set it to configMAX_PRIORITIES. Sample code: https://github.com/gnuarmeclipse/openocd/blob/gnuarmeclipse-dev/contrib/rtos-helpers/FreeRTOS-openocd.c

Note: All of the above should be done for all NXP FreeRTOS examples and NXP-wizard-generated FreeRTOS projects!!

Re: BUG: KDS debug call-stack fails with Segger JLink

davenadler — Wed, 14 Dec 2016 23:14:45 GMT

Erich Styger wrote: ... The other thought I have is this: have you already configured this in FreeRTOSConfig.h
#define configTASK_RETURN_ADDRESS 0 /* return address of task is zero */
Because this terminates the stack with a zero return address. Otherwise, depending on the GDB version, this can confuse GDB (still, the Segger DLL shall not crash).

OK, I added this configuration setting. While the call stack displays goofy "called from 0", it is finally usable:

Thanks Erich!
Again: this along with the above (1-3) should be done in all NXP FreeRTOS examples and NXP-wizard-generated FreeRTOS projects!! NXP is making hard for customers by not setting this up in the first place!