This seems to happen to me frequently - I'll pause the debugger and the call stack will show up with a bunch of invisible entries. You can see that I've expanded the invisible list and highlighted one. If I use the 'copy stack' context menu item, it copies everything to the clipboard, so I know it's there. Is this a known bug? Is there a fix?
Also, no idea if it's related, but Peripherals+ only works sporadically. You can see that nothing is showing up in the Peripherals+ pane.
I'm running MCUX 10.1.1_606, and my debug interface is a P&E Cyclone ACP.
So from the Debug view in your screenshot, it looks like something is going wrong with the FreeRTOS thread awareness being provided from the P&E Micro debug plugin. Do you see this same behaviour if you debug other FreeRTOS projects, such as those provided in the SDK for your MCU?
The blank Peripherals view suggests that the peripherals information taken from the SDK has not been picked up by the debugger for some reason. Again do you see this with other projects, like the standard examples?
Can you confirm what exact SDK you are using? [look at the info in the "Installed SDKs" view]
Also can you tell us something about your project and the way it was created and is configured? The fact that the executable has the extension .elf suggests that this it may not be not a "standard" MCUXpresso IDE project (as the IDE uses ".axf" as its file extension for the executable).
MCUXpresso IDE Support
The problem is intermittent. I've only run a few demo projects, usually for the sake of troubleshooting development tools, and I can't spare a lot of hours to keep retrying with the demos. If I can figure out some condition that triggers it, I'd be happy to try to reproduce it with a demo project. I just ran a quick test with a demo on a FRDM-K22F and the Peripherals+ view came up there. I switched back to my project and Peripherals+ is still dead.
The NXP FreeRTOS views, at least the queue list and task list, usually work on my projects but they never populate on the first pause, only the second pause. With the demo project they seemed to come up the first time.
Something I've run into before with the P&E hardware was a problem handling the WFI instruction in the idle loop. I took that out now to check if that problem had come back but it doesn't seem to make any difference.
The project isn't using the SDK. It was originally created on CodeWarrior 10 - actually the ColdFire version was originally on CW 6.3, but the Kinetis port started on CW 10, and used Processor Expert. The project was re-created in MCUX and most of the PEx components were removed, but it still uses Erich's FreeRTOS component, the CPU component, and some peripheral initialization.
I've had to reinstall MCUX so many times in the course of dealing with various problems that I at least have my install procedure documented:
Install MCUXpresso (currently 10.1.1_606)
Install GNU ARM Embedded Toolchain (gcc-arm-none-eabi-6-2017-q2-update-win32.exe)
Install GNU ARM Eclipse Windows build tools (2.9-20170629-1013)
Install GNU ARM Eclipse 3.4.1 (3.4.1-201704251808, newer doesn't work with old CDT)
Install PEx for Kinetis 3.0.0
Install PEx for Kinetis 3.0.2
Install MCU on Eclipse PEx components, parts 1 and 2
EmbSysRegView - install from local repository, marketplace download is broken
Debugging with the Cyclone ACP under MCUX has been a little flaky from the start. It loses its gdb connection constantly and I have to kill the process to start another session. The same Cyclone was fine under CW 10. To try to take P&E out of the equation I tried to use an LPC-Link2 yesterday and couldn't get it to do more than reset the target after creating a LinkServer debug configuration manually. Pressing the blue debug button in my project only shows the P&E devices. I tried it just now with the demo project and the LPC-Link2 comes up as an option there.
I believe the reason for switching from .axf to .elf was that P&E's standalone programming software doesn't support .axf. Though now that I say that, I don't see where to change it back to test.
If I had the time, I'd start over with a fresh, vanilla install and rewrite everything to use the SDK (and probably get a new Segger J-Link just to have the more widely used debug interface) but I'm already working 10-12 hour days and can only afford so much time fighting with my tools.