• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 731 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TDA4VM: Multiple CPU(R5F) Debugging using Trace32(Lauterbach)

kishore B
Intellectual 360 points
Part Number: TDA4VM
Other Parts Discussed in Thread: DRA829

Hello TI,

Currently we are using TRACE32 for debugging, we are using the CMM scripts given in the below link. 

https://www.ti.com/lit/zip/spracy5

We are following sequence of j7es_m3.cmm -> J721E.cmm -> j7es_r5.cmm and then Load ELF.

But with the above steps we are able to load any one R5 CPU(Either MCU_R5 or MAIN_R5). 

We wanted to load and debug MCU_R5 and MAIN_R5_0 parallelly.

Our Intention is to load ETHFW on MAIN_R5_0 and Autosar Remote client on MCU_R5.

Could you let us know how to achieve this?

Thanks in advance!

Regards,

Kishore B

  • 0
    TI__Mastermind 23605 points

    Hello Kishore,

    The practical amount of  'useful' mutli-core debug will depend a lot on what layer of code needs debugging.  Single core debug for early code is mostly independent. Multi-core gains a lot of dependencies when resources need to be split across cores. The scripts are focused on early single core independent development (bare metal) and later stage multi-core (where a bootloader launches cores). What you are asking about debugging is a 'bare metal' + multi-core + shared-resources.  To do this via JTAG will be come very custom for your application.  You likely will have to consult your AutoSAR vendor for help.  The vendor might not productize this option.  Most anything is possible but the amount of custom work can become high.

    The above said, I have expanded some the debug examples for the R5 cores for baremetal. Take a look at the updates in the attached files.  You might be able to follow the AutoSAR SMP example flow at ./cmm-tda4_dra829/x_gel_to_cmm_public/pdk_rtos_test/pdk_launch_vect_autosar.cmm or one of the other examples at that level.  You will have to fix up firmware image paths in the scripts to match what you use.  See the readme's in that structure for pointers.

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/1004.cmm_2D00_tda4_5F00_dra829.7z

    Regards,

    Richard W.

  • 0 in reply to Richard Woodruff
    Intellectual 360 points

    Hello Richard,

    In our current implementation FREERTOS is used for MCU2_0(Main Domain) and MCU1_0. We are not running any Autosar OS here.

    To debug MCU1_0(Remote Client), we need to have MCU2_0 up and running(ETHFW server).

    hence we are looking how this can be done using Lauterbach.

    Thanks and Regards,

    Kishore B

  • 0 in reply to kishore B
    TI__Mastermind 23605 points

    Hello Kishore,

    The logical flow will be the same with or without autosar.  The examples I pointed at are the pattern to follow.  If you can share some example elf files maybe I could see if they work.  As I mention if you need fuller stacks to be running you may have to regen the firmware resources file to route interrupts to the correct cores.

    Regards,

    Richard W.