To extend the information in the previous message:
The code of the hello world application is:
int main(void)
{
P4_uid_t me;
P4_timeout_t sleeptime;
me = p4_my_uid();
vm_cputs("Hello World!!!, starting up.\n");
sleeptime = P4_SEC(2);
for (;;) {
vm_cprintf("Hello World, this is task %d, thread %d\n",
P4_UID_GET_TASK(me), P4_UID_GET_THREAD(me));
p4_sleep(sleeptime);
}
}
We can see that the address of main is:
$ nm -S hello.unstripped | grep main
08017820 00000068 T main
and the binary content of main is:
$ objdump -d hello.unstripped | sed -n '/<main>:/,+5p'
08017820 <main>:
8017820: 94 21 ff e0 stwu r1,-32(r1)
8017824: 7c 08 02 a6 mflr r0
8017828: 90 01 00 24 stw r0,36(r1)
801782c: 93 a1 00 14 stw r29,20(r1)
8017830: 93 c1 00 18 stw r30,24(r1)
We create a codewarrior bareboard project(QoIQ_T2 family and T2080 processor), using board T2080RDB-PCIe with attach launch and the connection type codeWarrior TAP(over Ethernet)· The next screenshot shows the debug configuration:

We stop the execution of the program with the Multicore Suspend button:

where we can see that cores are stopped in address 0xFFFFFFFC or 0x800360E8, that are addresses out of the text range of the application. At this stage we can see that the execution is actually stopped because we don't get new hello world messages in the console.
We try to setup the memory monitor in the address 0x8017820 (the address of main) and we only can see words with the DEADBEEF value (both in Virtual and physical spaces), so we deduce that the memory monitor cannot see the actual memory.
If we try to setup a memory monitor at 0x800360e8 (the address where some of the cores are stopped) we only can see ???????? words (both in Virtual and physical spaces).
We tried a pure baremetal application (without any OS) and we were able to see the actual memory and even doing step execution, but at the moment that we have an OS we only can suspend and resume.