• State TI Thinks Resolved
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 79 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

J784S4XEVM: Is there lauterbach scripts to load r5f executables to different memory ?

Jim Zhang
Prodigy 40 points
Part Number: J784S4XEVM

Tool/software:

Could you provide trace32 scripts to load elf to DDR/OCRAM/MCMS_RAM and execute on R5F cores ?  The scripts will be different for each memory type.

Thanks, 

  • 0
    TI__Mastermind 38332 points

    We have informed the expert to look into this thread; in the interim, we suggest looking into a similar thread:

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1313514/j784s4xevm-request-lauterbach-cmm-script-for-mcu-r5f-debug-and-a72-debug 

    Thanks.

  • 0 in reply to Praveen Rao
    TI__Mastermind 20265 points

    Hello,

    Loading to different memories typically is mostly about how one compiles the binary (and linker scripts used) as compared to jtag script differences. The debugger is generally capable of loading to any memory which is initialized, at that is necessary is selecting the proper R5 core so the PC of the core the binary is about to be run on is updated.

    For the R5 binary to actually run from the memory which the debugger loaded the image into, can require some entity (the R5 itself or a master core, or the debugger) to setup the R5 MPU and RAT to access a memory.  The steps to do this are dependent on how the executable was linked.

    I'll attach a jtag script I used to measure some access times. The test loop is directly assembled into R5 memory (not a loaded elf).  It would be possible to extend this to do something along the lines asked about.

    /cfs-file/__key/communityserver-discussions-components-files/791/r5_2D00_mem_2D00_cmm.7z

    Regards,
    Richard W.
  • 0 in reply to Richard Woodruff
    Prodigy 40 points

    I am using the sdk to build example; the source and linker file are from TI SDK, and test board is j784s4_evm, and lauterbach scripts is provided by TI.

    I am just repeating what TI was doing in the SDK. 

    If this process is not working, does it mean TI SDK is not tested properly ?

    Please help me to reproduce what TI is doing in the SDK for this example

  • 0 in reply to Jim Zhang
    TI__Mastermind 20265 points

    The LB scripts are used with bare metal and can be used for SDK object debug.  What needs to be done to debug some SDK object is object dependent.   Most SDK users use a 'late attach' where they have some kind of while(1) loop in their code and they use that to serve as a safe-easy attach point for a JTAG debugger.  The SDKs test vectors which validate the package are largely run outside of any JTAG debugger.  I do not understand your linkage to SDK test and the Lauterbach debugger.  The JTAG debugger is a development aid.  To debug end code it is expected the developer understand the code memory map sufficiently to employ a debugger.   Most SDK developers only use JTAG debug as needed.  The SDK does provide some CCS guidance.  Largely for Lauterbach guidance you need to ask Lauterbach support.

    If you have a specific question please ask it with details.  Your generic question is too open ended.

  • 0 in reply to Richard Woodruff
    Prodigy 40 points

    My problem is:  I followed the instruction to build the app, and I load the app to the evm board, but the code did not run the app. What is the right way to run those app on the evm board ? I am looking for a way to reliably run the app on the EVM board

  • 0 in reply to Jim Zhang
    TI__Mastermind 20265 points

    Which app did you build?  How did you try and run it?  Were any errors reported?  Probably an application domain engineer will need to be added to this thread depending on what you are trying to do.  The usage of the debugger is secondary to how to use the package.  In general I see a boot image is generated for an SD card (but it can be put in flash) this boot image boots the system then launches the application.  A build object which is the application + boot image is likely what you want to be using.  You can add an attach point in the main() of your test application if you want to look at it inside the jtag debugger.   There is a 'noboot' development flow where 'jtag' is used as the loader instead of the SD card (or flash).  In that method the launch.js (for ccs) is used to load the application (after the EVM's dip switches are in noboot mode) for Lauterbach the scripts at the cmm-tda4vh_j784s4\x_gel_to_cmm\pdk_rtos_test level can be used.

  • 0 in reply to Richard Woodruff
    Prodigy 40 points

    J784S4XEVM: gpt_app_mcu1_0_release.xer5f not working as expected after loading by Trace32 - Processors forum - Processors - TI E2E support forums

    Here is the detailed description for the issue. In the link above, I provided the app, the way I built app, and scripts I load the app, and issue I was facing.  Please help there.  Thanks