J721EXSOMXEVM: R5 freertos ipc_echo_test questions (frustrations)

Randy St. John

Part Number: J721EXSOMXEVM

Tool/software:

I have the large Common Carrier Board with a J721EXSOMXEVM processor card installed. I am loading and running the programs from a JTAG connection with a TI XDS200 jtag probe. We have built and run other code using this method.

I am trying to run a modified IPC echo example on two R5 cores only. Main MCU2_0 and Main MCU2_1. ( I won't get into the confusion naming of the MCU's at this time. )

I took the stock ipc_echo_test_freertos example and just limited it to those two cores by editing the "ipc_rtos_echo_test.c" file for those two cores to the following.

#if defined (SOC_J721E)
#define CORE_IN_TEST            1
.....

#ifdef BUILD_MCU2_0
uint32_t selfProcId = IPC_MCU2_0;
uint32_t remoteProc[] =
{
#if defined (SOC_J721E)
    IPC_MCU2_1
.....

#ifdef BUILD_MCU2_1
uint32_t selfProcId = IPC_MCU2_1;
uint32_t remoteProc[] =
{
#if defined (SOC_J721E)
    IPC_MCU2_0

I then build for both cores using the following make commands

make CORE=mcu2_0 BUILD_PROFILE=debug ipc_echo_test_freertos

make CORE=mcu2_1 BUILD_PROFILE=debug ipc_echo_test_freertos

I then load those built executables into the appropriate cores (MAIN_Cortex_R5_0_0 and MAIN_Cortex_R5_0_1)

Then I run 0_0 first and then quickly run 0_1.

Issues:

Debugger won't stop at breakpoints so I have to step through the code and place breakpoints in the assembly where only sometimes they break.

If I don't put any breakpoints in and run them they almost always end up in an abort handler or HwiP_undefined_handler method.

How can I debug these?

The reason I went back to the example is that I am trying to get these two R5 processors talking to eachother using IPC and I am having very inconsistent results. I occasionally can get the 0_0 processor to recieve the service notification but I have not been able to get the "ping" to be received.

I spend half my time fighting with Code Composer Studio and the debugger and the other half setting breakpoints in assembly becasue it refuses to let me put breakpoints in the c code.

Your direction, questions, and help would be appreciated.

3 months ago

0 Tarun Mukesh Puvvada 3 months ago

TI__Mastermind 49416 points

Hello,

Randy St. John said:
I then build for both cores using the following make commands

make CORE=mcu2_0 BUILD_PROFILE=debug ipc_echo_test_freertos

make CORE=mcu2_1 BUILD_PROFILE=debug ipc_echo_test_freertos

You are doing changes in ipc_rtos_echo_test.c file which will be built for "ipc_echo_test_freertos" but not "ipc_echo_test_freertos"

Can you please do BUILD_PROFILE=release but not debug since we are validating only release profiles ?

so it has to be

make -sj ipc_rtos_echo_test_freertos CORE=mcu2_0 BUILD_OS_TYPE=freertos

make -sj ipc_rtos_echo_test_freertos CORE=mcu2_1 BUILD_OS_TYPE=freertos

You can halt the both cores in main() and add some break points inside the code on both cores to ensure both are hit . CUrrently the prints are going to trace if you want to get prints on console or UART you can change the define of the below

#define App_printf Ipc_Trace_printf

If you start without breakpoints code will run successfully on both cores and reach abort stage .

Note:

keep sciserver running on MCU1_0 core continuously if you are using freeRTOS on MCU2_0 and MCU2_1 else you need to run

ipc_baremetal_echo_test application on both cores

RegardS

Tarun Mukesh

0 Randy St. John 3 months ago in reply to Tarun Mukesh Puvvada

Prodigy 170 points

Tarun,

Thank you for your reply. However, you must have typed something wrong in (You are doing changes in ipc_rtos_echo_test.c file which will be built for "ipc_echo_test_freertos" but not "ipc_echo_test_freertos")? Those are the same things in quotes. What did you mean?

I built the two examples as you specified. Our sciserver is running on MCU1_0 always. It is part of the debugging startup process we follow. I also noticed that during the build it is producing R5 certificates. Is that important?

I loaded the images and then ran them, starting with mcu2_0 first. I get the following output.

IPC_echo_test (core : mcu2_0) .....
IPC_echo_test (core : mcu2_1) .....
mmccuu22__10  <<---->>  mmccuu22__01,,  PPiinngg--  1100000000,,  ppoonngg  --  1100000000  ccoommpplleetteedd

Does that look correct? Looks like the Uart print is doubling the characters. Must be from both processors accessing the UART at the same time.

So it seemed to work. Besides running it in "release" mode is there something special that the build did?

The variable "BUILD_OS_TYPE" is not something I knew we would have to set. It does not show up in the "make help" command. I built without setting that variable and it seems to work the same. Maybe it is because it was set from the last run?

Finally: In CCS using the JTAG debugger, we usually reset the core before loading a program. About half the time when we load the program it just starts running and we have to pause it, reset and then load again. Then it will stop at main. Any Ideas as to why this happens?

+1 Tarun Mukesh Puvvada 3 months ago in reply to Randy St. John

TI__Mastermind 49416 points

Hello ,

There are 2 different tests in SDK

1) ipc_rtos_echo_test_freertos , this test will communicate with all rtos cores do to ipc transmission.

2) ipc_echo_test_freertos , this test will communicate with all rtos cores as well as linux cores to do ipc transmission.

You can use either of these tests but the changes you did in ipc_rtos_echo_test.c will be for ipc_rtos_echo_test_freertos test similarly there is ipc_echo_test.c file for ipc_echo_test_freertos test

Without any changes also your use case will work fine.

Randy St. John said:
Does that look correct? Looks like the Uart print is doubling the characters. Must be from both processors accessing the UART at the same time.

So it seemed to work. Besides running it in "release" mode is there something special that the build did?

Yes UART looks fine to me , since both cores accessing same UART instance at the same time there can be such issues.

and Yes as i said we validate release mode only that's why is it working fine .

Randy St. John said:
Finally: In CCS using the JTAG debugger, we usually reset the core before loading a program. About half the time when we load the program it just starts running and we have to pause it, reset and then load again. Then it will stop at main. Any Ideas as to why this happens?

Could you please raise another E2E for CCS related issue ,? it should not happen generally. After you load the program the core should be in main in paused state but not run unless you give run.

Regards

Tarun Mukesh

Processors

Processors forum

J721EXSOMXEVM: R5 freertos ipc_echo_test questions (frustrations)