This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TDA4VH-Q1: IPC Could Not Work After Running SDL_runMPUSelfTest

Part Number: TDA4VH-Q1
Other Parts Discussed in Thread: TDA4VH

Hi TI Experts,

Customer is working on TDA4VH SDK9.1.

They have integrated the SDL_runMPUSelfTest in sdl/test/mpu/func_test/sdl_mpu_funcTest.c to their applications.

Before running this test, everything seems ok and the IPC is working normally.

They found that after running this test, all the R5f cores will become abnormal, and the IPC could not work anymore.

Please see the below log printing for the details.

This is testing on MCU1_1 with freertos system and SD card booting image.

Could you help provide some ideas on this please?

Thanks a lot!

Kevin

  • Hi Kevin,
    Due to upcoming holiday, please expect a 1~2 business day delay in responses.

    Apologies for the delay, and thank you for your patience.

    Regards,
    Takuma

  • Hi Kevin,

    Could you clarify what you mean by IPC does not work anymore? Is some IPC test application failing?

    Could you also try running the standalone SDL mpu_func_test_app and check if this issue occurs? I am trying to identify if it is due to integration or the standalone test application causes the issue.

    Regards,

    Josiitaa

  • 1. NO, IPC does not work anymore.   I use  IPC to communicate between MCU1_1 and MCU4_0. 

    2. In our j784S4_board, the image is linux.  And linux can not run  SDL mpu_func_test_app independently,  it caused linux run to  exception

  • Hi,

    What IPC firmware are you running on the MCU1_1 and MCU4_0?

    At what boot stage are you testing the MPU selftest? Is it run before any IPC functions at the beginning of the boot flow?

    Regards,

    Josiitaa

  • 1.ipc firmware is ipc_echo_test_freertos.

    2.After freertos has started up,  and  I created new task  to do  mpu selftest. It is after ipc functions.

  • Hi,

    I am trying to reproduce the issue with the standalone test. I will get back to you in a couple of days,

    Regards,

    Josiitaa

  • Hi,

    1. Are your MCU1_0 MCU1_1 cores running in lockstep?

    2. It might be that the MPU_selftest application on MCU1_0 is affecting IPC on MCU1_1. Could you try testing IPC on MCU2_0 or MCU2_1?

    Regards,

    Josiitaa

  • Hi, Josiitaa. 

    1. not in lockstep, we use independent mode.

    2. mcu1_0 don't run MPU_selftest.

  • Hi Josiitaa,

    Let me explain the steps with more details.

    Customer firstly run the IPC test on MCU2-0, and it is working normally.

    Then they run the MPU_selftest on MCU1-1, this test is also working fine.

    After that when they rerun the IPC test on MCU2-0 it will fail. They also try run the IPC test on MCU1-1 at this time, it will also fail.

    Thanks,

    Kevin

  • Hi,

    This seems to be because of conflicting memory initialization issues. The MPU_selftest and IPC must be run as independent applications. In this case you would have to perform the MPU_selftest first then do the MPU memory init and only then initialize IPC for all the cores.

    Regards,

    Josiitaa

  • Hi Josiitaa,

    Thanks for your reply!

    As customer is using spl but not sbl, it would be hard to do mpu memory init after the mpu_selftest. Because the configuration of memory init is before the main function. Do you have any idea on how could we do the mpu memory init after the mpu_selftest using SPL?

    Thanks,

    Kevin

  • Hi Kevin,

    Since these are applications that have to tested independently, you could try the following methods to avoid conflict -

    1. The /r5f_mpu_j784s4_default.c file present in PDK/packages/ti/drv/ipc/examples/common/src has the MPU region configurations that IPC requires to pass. You can compare that configuartion to the SDL_ArmR5MpuRegionCfg and avoid any overlap that might be present while testing MPU_selftest.

    OR

    2. You could stop the MCU1_1 core after running MPU_selftest and stop and restart the other cores like MCU2_0 MCU4_0 where IPC has to be tested. This should reconfigure the MPU region as that is done as a part of the core startup code.

    These are the commands to stop and start the MCU2_0 core. You can follow the same approach for the other cores as well while running at Linux prompt.

    echo stop > /sys/class/remoteproc/remoteproc4/state" and "echo start > /sys/class/remoteproc/remoteproc4/state"

    Regards,

    Josiitaa