TDA4VH-Q1: Lauterbach - No Boot Mode

Thanks for the response, 

Just a confirmation, in Normal SD card boot mode. After booting, if I try to load the C7x firmware using a cmm file from lauterbach, will replace the existing firmware?? 

The scripts which you have shared ,it's for which SDK ??

The scripts have had a basic check with SDK8/9/10.  In any case the paths have to be updated.  Most SDK users don't use JTAG that often, basic internal usage with CCS is in the SDK documentation itself, TRACE32 here just has ported the launch.js into CMM form.  The logical usage is identical.  The SDK usage is compatible with JTAG debug but its not an attribute which is part of matrix testing.

I am able to run scripts now.

But the C7x1 breaks at  and not moving further.

I remember when doing these same in ccs setup , we need to start the r5f core as well?

Is it possible here. 

yes the sci service needs to be built into your R5-mcu.  the script ./cmm-tda4vh_j784s4/x_gel_to_cmm/pdk_rtos_test/pdk_launch_js_common.cmm does this.  If you look at that script and compare to the ./gel/sdk9_launch.js you will see they do the same things.

the message you are showing generally happens if the firmware and the pdk objects are not from the same SDK bundle.   You should use the all the pieces from the same bundle and not mix and match.  If you are trying to use an app built in say sdk11 you should use firmware that was bundled with it.

Hi, 

Thanks for the response

I saw this in ccs setup documentation,

My question is if I want to load my own firmware (that runs on FREE RTOS) do we need this SMS and MCU1_0 to be loaded? Can I directly load my own firmware without this mcu1_0 and system firmware getting loaded from launch.js or cmm files?

Hello,

What is written here is the TI firmware MUST be running on the Cotex-M core (TIFS) in order to execute any PSDK applications on other cores.   The flow is the .js file loads up the firmware on the M4-TIFS, the R5-MCU1_0 starts an application which initializes the firmware on the M4 with an init message (kind of like start w/config), then other cores can run PDK examples which make service calls to the MCU1_0.   The MCU1_0 can only handle a subset of service calls and sometimes has to make a call into the M4-firmware.   If you want to run an application on MCU1_0, you can create a build which skips loading the ~dummy-service-provider (loadSciserverFlag=0 and execute it directly. 

I want to run my application on C7000, that is my own application, which runs on FREE RTOS. For that do we need the M4, MCU1_0 to be running? Can I run without loading the firmware for M4-TIFS and MCU1_0 running. Is this flow applicable only for running sample applications from PSDK? If I want to run my own application on C7000 is this necessary? If it's necessary what does this TIFS do? 

Yes, the psdk script flow as written requires M4-TIFS running along with an R5 to run C7x code from the SDK.

Few queries, I went through few docs and scripts that was shared, from my understanding,

TIFS owns PM/RM/DDR/firewalls.

1.  pdk_launch_js_common.cmm attaches to M4 core and loads this firmware ti-fs-firmware-j784s4-gp.bin. what the role of ccs_init_mcu1_0_release.xer5f?
2. Does TIFS only makes DDR to be alive? and what's the role of r5f here ? Does it help in booting the firmware to M4 and gives a signal to setup the DDR part?
3. And My application (C7x, FREERTOS) has few dependencies in DDR, so for that I need TIFS - M4 to be loaded? we cannot remove this r5f core dependency if I want my application to access DDR , since few parts of my firmware(.bss,.data) is in DDR_C7x1 memory region?

TIFS (M4 code) is needed for secure resource management.  TIFS's role is not central for DDR, the SBL has the DDR setup code, the PM (R5 side) will provide services for needed power/clock/reset.   As I mention, the bare metal flow will setup all that is needed (to include DDR) for bare metal operation.   I've not gone through the internals fully for each piece.  There has been an evolution of everything being inside the M4, to it being split between the M4 and the R5MCU0.  As I recall, the initial board config and firmware init were in the cc_init_mcu1, (for legacy and current), and when the R5 proxy was added the testapp was added to provide that server.

The common development path is to 'late attach' jtag to your application image (c7-freertos) and not try to connect so early.  You can boot the standard images, then put a while(1) in the init of your C7 startup.  From there you can attach and debug into it.  This is the most easy way to work.  You would only setup a 'fake other core' startup if its not ready and you want to start working ahead of those components completion. 

thanks for the explanation. 

 'Late attach' jtag -> this flow you are mentioning related to a normal SD card boot mode, not in No Boot mode?

So, in No Boot Mode.

SMS (M4 Code) -> runs SysFW (TIFS + DM)

MCU/R5F (MCU Domain) -> runs ccs_init(or SBL in production).

• This code first requests PM/RM services (DDR power/clock/reset) from SysFW.
• Then it executes the DDR initialization sequense(Controller + PHY Training).

And only MCU R5F can communicate to SysFW , other cores have to go via R5F core for any PM/RM request.

After these steps DDR will be alive and usable by all cores

Question) If I only want DDR initialized once using ccs_init, can I skip loading sciserver to be running on MCU r5f and directly load my own custom firmware C7x FREERTOS instead?

My use case is C7x FreeRTOS unit testing in No Boot mode using Lauterbach, with firmware sections in DDR, I only need DDR alive, no runtime PM/RM request.

Your summary seems correct.   If you have your own C7 FreeRTOS driver (not one from TI) then likely a basic image which just does PIO may be able to run with out the R5.  Most (if not all) of the TI support libraries expect the sciclient interface to be initialized (even if not many services are given).   One possible issue is some watchdogs might be active (on M4 and R5) which don't get handled.   If your image needs to use complex IO (say DMAs like PSI or UDMA) there may be issues as those will require service calls for their inits.