AM6442: Debugging with Lauterbach, connection fails

I figured out I can not use the Lauterbach because programming the cores is done by DMSC on core M3, and I don't have Lauterbach License for M3.

Since I only want to use R5-0, is there any way I can bypass the M3 and directly program the R5 on RAM to be able to debug it with Lauterbach?

Thanks, 

Boshra

I'm not familiar with using Lauterbach tools. I sent your question to someone from another team that has experience with Lauterbach tools. He said, TI is working with Lauterbach trying to resolve some issues. He recommended you contact Lauterbach to get their help. They may have options or workarounds that can help resolve your problem.

Regards,
Paul

Hi, 

Thanks for your reply. 

I had already talked to them. They were not able to help me and referred me to the TI side. So would you please help me with that? I am following up on their side as well. 

It seems there is a SharePoint between Adcore and Lauterbach that is including some scripts (I saw it in other TI forums). How can I access it?

Thanks, 

Boshra

I do not have a better answer for you at this time and will be out of the office for the next two weeks. I'm going to copy someone more familiar with the Lauterbach tools issue on this thread just in case there is any new information on this topic while I'm out of the office.

Regards,
Paul

Hello Boshra,

What level of code are you first wanting to work with Lauterbach on with your AM64 system?  Working with the HS devices does require extra steps.  Some of these steps are straight forward CMM changes and others can require may require running some target software coordination.  If you are working with later software (say at the Linux or RTOS level) the number of adjustments is very low.  If you want to do board level bare metal testing the preconditions can be more involved.  I have used AM64-GP devices in the past but not yet an AM64-HS, though for other TI SOCs I have used both HS-FS and HS-SE with TRACE32.   If you are just looking to run basic code on the R5 as a starter, you are already almost there using a 1st stage loader (sbl null) to setup the system in areas which are private to the M4.  That SBL null in your flash, is actually pretty similar to the first stage loader you downloaded as part of the uniflash burn process.  In either case, some 1st stage code is presented to the M3's ROM, it runs enough to setup M3-private clocks, and now the system is opened up sufficiently to run R5 centric scripts.   The Lauterbach sieve examples today start with the Mcore then shift to the R core, 98% of their example can directly run on the R core.  The 2% which as an M core dependency is done by the SBL null (running from your flash, or in the 1st stage image download from your uart boot. 

If the scripts you want to run are small, its very easy to step them in the TRACE32 macro-debugger (click debug instead of run button from the edit-script menu).  By doing this after a 1st boot (after uart or qspi) you can get things going.  Lauterbach and TI have identified at a high level what needs to be done as far as adjustments.  Now they need to be worked through one by one.  Most of the bits are straightforward but not all the steps can be handled by Lauterbach, some needs to be done in by software. There will be some SOC+EVM specific bits which requires a per target touching.  If you share which bit you want to work first, maybe we can suggest a way to do it while things are being worked.

Richard Woodruff said:

If you want to do board level bare metal testing the preconditions can be more involved. 

I'm using a bare metal, No-RTOS. 

I programmed the SBL_NULL on the flash and I can see the bootloader version through the console at power up. If I try to load the executable through lauterbach to R5, the debug port fails. 

I understood that we program the SBL in the Flash, where the ROM code will point to it and it is loaded to M3. I have done this step with both SBL_NULL and "SBL_UART + application" in UART mode. But I don't want to program the code in the flash. I would like to program it on the RAM. Therefore instead of using SBL_NULL and then putting it in OSPI mode, I used UART boot mode used uart_bootloader.py which I THINK is loading it on RAM (instead of using UNIFLASH https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/latest/exports/docs/api_guide_am64x/TOOLS_BOOT.html). Then, I was able to attach the Latuerbach and debug it, but I'm not able to reprogram with Lauterbach. and if I want to re-program with UART, I need to do a power cycle, but the board is not accessible. 

Also, we prefer to use JTAG. It seems in OSPI boot mode, it is using Jtag for loading on FLASH (Not the RAM that we want). So instead I decided to use the DEV BOOT Mode for the HS-FS device (https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/latest/exports/docs/api_guide_am64x/HSFS_MIGRATION_GUIDE.html ), here there is no boot and  load_dmsc.hs_fs.js is used to load  sciclient_ccs_init.release.out  (SYSFW along with boardCfg)  through R5. I used DSS and modified the load_dmsc.hs_fs.js so that after loading sciclient_ccs_init.release.out it loads my application. and I added a reset at the beginning to be able to reprogram it (without a power cycle). and it worked. but there are two problems, first in that script I can not see at what address the sciclient_ccs_init.release.out is loaded and at what address my application is loaded on the RA.  And at this step when the code is running, if I plug the Lauterbach and attach connect it to R5 it works, but if I want to reprogram it with Lauterbarch I don't know at what address I should load my executable. and plus if I try to load it with an internal debugger I have to disconnect the External debugger(Lauterbach) so it switches to the internal debugger. 

Is there any possibility to set a meeting and discuss it? I had already had a meeting with Lauterbach it seems it is more a matter related to TI. 

Thanks,

Boshra

Hello Boshra,

Scanning your response and reading the MCU SDK links I have a better understanding of the environment. On GP devices where access to the M3 is possible, a person can run jtag init + bare metal code and non-TI unit tests 'without' firmeware, or a person can run jtag init + firmware init + TI included unit tests.   A Lauterbach sieve is an example of the former and TI projects are examples of the latter.  I have translated the <file>.js tests for GP to CMMs for the TDA4 series but I have not tried the same for the AM64 series as there was no firmware when I last used that board with a GP devices.  I do not have an HS device to try with at present. I took a quick look at the MCUSDK <>.js files and they could be converted to CMMs and probably that is the easiest way to run TI supplied examples via Lauterbach. The early low-level startup-boot on an HS device must use firmware services to fully open the board and also to supply services for non-trivial applications.  After this first start up runs, it should be possible to run your custom application code.  If your custom application is 'big-featured' chances are it may need to make further firmware service calls, it should be able to do this by linking to a API library which runs on the R5.  Depending on the service, the R5 library might directly satisfy the request on the R5, or it would make a call to the M3 service provider using a message api.

For your application (past the initial sbl lboot layer) you should be able to compile and load it most anywhere, but probably at first into DDR for ease. The M-core service will be running out of private resources.  Any R5 to firmware services would be part of your compiled in service api library on the R5.  I would expect a converted .js to CMM would init the M3+R5 using the TI supplied objects (if your using the EVM), then when its done, you just load your application and go.   If you have your own board, and want to use the same JTAG load based flow, you would have to adjust the board config file and rebuild the init files first loaded by the JTAG.

In the CMMs I made for TDA4 GP devices, the firmware, boardconfig and application are 3 separate files which are loaded and ran in turn using jtag.  For HS devices, since the M-core cannot be connected to, a combined firmware+boardconfig exists (like is done for SD card boot and others).  Its load addresses are embedded in the elf files as in the sdk (https://github.com/TexasInstruments/mcupsdk-core/tree/next/tools/ccs_load/am64x ).  Once that runs, you should be able to load and run your application where ever you want.

I did request an HS EVM but I am not sure when it might come, maybe Paul would provide one when he is back.  I can look at sharing with LB any converted scripts and the EVM related firmware+boardcofig file (https://github.com/TexasInstruments/mcupsdk-core/blob/next/tools/ccs_load/am64x/sciclient_ccs_init.release.out ) they could then via startup CMM, use this ahead of their sieve if the device type is HS or just use their existing flow for GP.