MCUXpresso IDE中的主题 Re: FreeRTOS stack backtrace not enabling

FreeRTOS stack backtrace not enabling

Genovation — Wed, 24 Nov 2021 15:14:55 GMT

I am testing FreeRTOS on an QN9090DK6 board:

IDE: MCUXpresso IDE v11.4.1 [Build 6260] [2021-09-15]

I have verified the settings for enabling backtracing in the forum posts. I am not seeing threading enabled. I am using heart_rate_sensor_freertos example project from the SDK.

All the files have been updated and running All-Stop. I reviewed the instructions in "FreeRTOS stack backtrace is disabled". I have also went through the "MCUXpresso_IDE_FreeRTOS_Debug_Guide.

What other settings do I need to verify are correct.

GDB nonstop mode disabled (using allstop mode)
FreeRTOS stack backtrace is disabled

Thanks

Chad

Re: FreeRTOS stack backtrace not enabling

mario_castaneda — Fri, 26 Nov 2021 17:04:04 GMT

Hi @Genovation,

I hope you are doing great.

I am not sure if I am following your case.

What are you trying to achieve? What is the example that you are running?

Could you please provide more details about the issue that you have?

Regards,

Mario

Re: FreeRTOS stack backtrace not enabling

Genovation — Mon, 29 Nov 2021 14:00:02 GMT

I am running the heart rate sensor freetos monitor example. I am trying to see all the threads that are running to understand how the application functions.

Re: FreeRTOS stack backtrace not enabling

ErichStyger — Mon, 29 Nov 2021 14:20:28 GMT

what debug probe are you using? Could you share a screenshot?

Note: if using J-Link, you need to turn it on in the launch configuration settings.

And threads won't show up until you have started the scheduler.

Otherwise: does the debugger console report anything useful?

I hope this helps,

Erich

Re: FreeRTOS stack backtrace not enabling

Genovation — Mon, 29 Nov 2021 15:26:11 GMT

tasks.c: attached

freeRTOSConfig.h: attached

freertos_tasks_c_additions.h: exists

Console output:

Probe(0): Connected&Reset. DpID: 2BA01477. CpuID: 00000C24. Info: <None>

Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled.

Content of CoreSight Debug ROM(s):

RBASE E00FF000: CID B105100D PID 04000BB4C4 ROM (type 0x1)

ROM 1 E000E000: CID B105E00D PID 04000BB000 Gen SCS (type 0x0)

ROM 1 E0001000: CID B105E00D PID 04003BB002 Gen DWT (type 0x0)

ROM 1 E0002000: CID B105E00D PID 04002BB003 Gen FPB (type 0x0)

ROM 1 E0000000: CID B105E00D PID 04003BB001 Gen ITM (type 0x0)

ROM 1 E0040000: CID B105900D PID 04000BB9A1 CSt TPIU type 0x11 Trace Sink - TPIU

NXP: QN9090

DAP stride is 4096 bytes (1024 words)

Inspected v.2 On-chip Flash Memory QN9090_640K.cfx

Image 'QN9090_Internal Flash Sep 14 2021 15:10:39'

Opening flash driver QN9090_640K.cfx

Sending VECTRESET to run flash driver

Flash variant 'QN9090_Internal Flash Sep 14 2021 15:10:39' detected (646656B = 1263*512 at 0x0)

Closing flash driver QN9090_640K.cfx

Connected: was_reset=true. was_stopped=false

Awaiting telnet connection to port 3332 ...

GDB nonstop mode disabled (using allstop mode)

FreeRTOS stack backtrace is disabled

Opening flash driver QN9090_640K.cfx (already resident)

Sending VECTRESET to run flash driver

Flash variant 'QN9090_Internal Flash Sep 14 2021 15:10:39' detected (646656B = 1263*512 at 0x0)

Writing 257592 bytes to address 0x00000000 in Flash

0003E200 done 98% (254464 out of 257592)

( 98) at 0003E200: 512 bytes - 254976/257592

Sectors written: 9, unchanged: 495, total: 504

Erased/Wrote sector 0-503 with 257592 bytes in 528msec

Closing flash driver QN9090_640K.cfx

Flash Write Done

Flash Program Summary: 257592 bytes in 0.53 seconds (476.43 KB/sec)

Starting execution using system reset and halt target

Stopped (Was Reset) [Reset from Unknown]

Stopped: Breakpoint #4

Re: FreeRTOS stack backtrace not enabling

ErichStyger — Tue, 30 Nov 2021 07:19:11 GMT

I believe there are some symbols missing (maybe due optimization or because you are using the NXP FreeRTOS port). I maintain my own port which covers all optimization levels and compiler settings, anyway.

I recommend you might have a look at yet another article of mine, more specific to this problem:

https://mcuoneclipse.com/2017/07/27/troubleshooting-tips-for-freertos-thread-aware-debugging-in-eclipse/

It describes a debug level setting you can use for the LinkServer configuration. The latest IDE somehow has the GUI for it removed somehow, but you can edit the .launch and change the setting manually:

Then you should get a list of symbols found:

I hope this helps,

Erich

Re: FreeRTOS stack backtrace not enabling

Genovation — Tue, 30 Nov 2021 17:49:52 GMT

Looking the above, what do I need to update to make the peripherals supported since this is the example being provided? I am not sure if that is why the FreeRTOSDebugConfig does not have an address like your documentation shows.

Thanks

Re: FreeRTOS stack backtrace not enabling

ErichStyger — Tue, 30 Nov 2021 18:03:39 GMT

Looking the above, what do I need to update to make the peripherals supported since this is the example being provided?

Not sure, but I guess peripherals config tools is not implemented?

You might have to check this list:

https://community.nxp.com/t5/MCUXpresso-General-Knowledge/MCUXpresso-Supported-Devices-Table/ta-p/1101007

But: It would be much better if you would open a different thread for each item.

Erich

Re: FreeRTOS stack backtrace not enabling

ErichStyger — Tue, 30 Nov 2021 18:08:32 GMT

As for the FreeRTOSDebugConfig:

Check that it is indeed linked with your application (and not optimized away)

and just in case: I maintain my version here: https://github.com/ErichStyger/McuOnEclipseLibrary/blob/master/lib/FreeRTOS/Source/include/freertos_tasks_c_additions.h which has been immunized against linker and compiler optimizations.

Keep in mind that for it there are two macros required:

I hope this helps,

Erich

Re: FreeRTOS stack backtrace not enabling

Genovation — Tue, 30 Nov 2021 19:38:28 GMT

Erich,

peripherals config tools is not implemented, in the spreadsheet line 138 is the board. QN9090DK6 is the board, Cortex-M4 I would guess falls in there. If not I can create a new thread to continue and debug this issue.

Thanks

Chad