FreeRTOS on iMX7.D M4 stuck in prvPortStartFirstTask()

Did you run compiled application as is instructed in Toradex Knowledge Base? Does’t it run? If it runs, then we back again to issues with your debugger. Isn’t it? I didn’t try all applications, just only 1 or 2 about RPMSG for quick start. RPMSG echo or something like that. It worked. It worked with some hair picking with DS-5 debugger, to make GCC ELF compatible, I had to either (load and) launch ELF using bootaux / imxfwloader, else GCC compiled ELF image had to be converted for DS-5. DS-5 ELF doesn’t agree with GCC ELF regarding, ehh, something about vma/lma. I had to use script like this, don’t remember details, please don’t ask:

LMA=`arm-none-eabi-readelf -l $1 | sed '10q;d' | cut -d " " -f 16`
arm-none-eabi-objcopy --change-section-vma .data=$LMA $1 $2

So, are you sure your debugger is compatible with your compiler?

And what PC address is it? Does disassembly agree with highlighted location in source code?

Not at all. iMX7 M4 initial address can be supplied only via vectors at 0. There are no other means, like for example on Vybrid, which has dedicated register for initial M4 PC address. This is how all iMX7 M4 launchers work, they write those locations to make initial PC value loaded from there. To put or not to put vectors table to 0 addresses is up to you and debugger, you are using. Once booted, vectors table pointer register can be moved to TCM / OCRAM /etc. So normally vectors table is “code locations” of application, which is not at 0 - addresses. Scripts with _bin in the name are imxfwloader compatible. Both _bin and non _bin should work with bootaux and remoteproc driver as launcher.

I think these are 9100f1, just byte reversed for some reason.
1 in least bit location is right bit setting for thumb mode. I see you as well noticed byte swap. What does PC point to? 91xxxx or F1xxxxxx?