TDA4VH-Q1: Main R5 Peripheral Access

Hi Suman,

Thanks for the help.

This is for an R5F application that will be running on the first main R5 (mcu2_0).  The timer will be used for our FreeRTOS application.  We aren't using any application provided in the PDK.  We don't have any C7x_0 things running, but could in the future.  I do see how TI allocates the timers in the comments under FreeRTOSConfig_mcu2_0.h.  We can always change which timer we use, but I think the same issue will persist.

1 and 2 ) Yes, this is what i was thinking but was confused when the other forum post indicated nothing needed to be done.

Do you have specific examples on how to power and open up the firewall for a timer?  I also don't see timer listed in J784S4 Firewall Desciption.  Is there a sub-page that has the timers?

Our next peripheral we will be accessing from a R5F is one of the CAN devices.  I'm guessing we will need to power it and unlock it?

Thanks,

Jason

Suman,

Thanks, I appreciate the detailed response!

I will start looking into Sciclient_pmSetModuleState() and how its used.

I still don't fully understand how you can tell from J784S4_Appendix_Public_20250628.xlsx that a firewall is not enabled for a peripheral.  Can you go into more details on how to read this spreadsheet?

Thanks,

Jason

Hi Jason,

Jason White said:

I still don't fully understand how you can tell from J784S4_Appendix_Public_20250628.xlsx that a firewall is not enabled for a peripheral.

No, this does not tell whether a firewall is enabled or not. But rather, it provides the Firewall Id details in the H/W. The Firewall Id and/or Address can be cross-checked against the J784S4 Firewall Descriptions section to see if TIFS firmware is configuring them.

Jason White said:

Can you go into more details on how to read this spreadsheet?

This sheet is considered part of the TRM Collateral for reading Firewalls Information (this is one of the sheets in the Appendix document). The Excel sheet format allows you to filter on keywords, addresses for easier searchability.

The main columns that are of interest for identifying a peripheral firewall would be the following:

• Target (Col. B) / Instance (Col. G)
• Firewall Id (Col. C)
• Number of Priv IDs per Region (Col. D)
• Firewall Regions (Col. E)
• Start Address (Col. I)
• End Address (Col. J)

Please read the 3.2.4 Firewalls (FW) chapter of the TRM for an understanding of the various Firewall terminology.

regards

Suman

Hi Suman:

This is Jim from Caterpillar. The table from J784S4_Appendix_Public_20250628.xlsx (you pasted above)  does not provide the firewall owner info for the timer, and the TISI website does not have the info either. Could you please provide the owner info?

We are using TI HSFS soc, not GP soc. Is the ownership same for HSFS soc and GP soc?

Also when I tried to access the register, the exception is permission denied access, not something related to power failure. We don't have this issue for GP soc, but have issue for HSFS soc. Why we don't need turn on the power on GP soc, but need turn on the power for HS/FS chip ? Your explanation is not convincible for me.

Thanks

Hi Jim,

Jim Zhang said:

The table from J784S4_Appendix_Public_20250628.xlsx (you pasted above)  does not provide the firewall owner info for the timer, and the TISI website does not have the info either.

The Excel document provides only the h/w details on Firewall Ids for various peripherals. The latter showcases all the Firewalls that are configured by TIFS firmware on boot. It does not configure Firewalls for Timer or CAN peripherals, so there are no entries for any of Timer or CAN peripherals. This means they are not owned by any s/w component.

Jim Zhang said:

We are using TI HSFS soc, not GP soc. Is the ownership same for HSFS soc and GP soc?

Yes, the Firewall concepts are the same across GP, HS-FS or HS-SE devices.

Please see the Firewall FAQ for a list of common questions on Firewalls.

regards

Suman

Suman:

Thank you so much for the quick answer!

Do you have example app for using TISCI_MSG_SET_FWL_REGION to reconfigure the firewall?

Hi Jim,

Jim Zhang said:

Do you have example app for using TISCI_MSG_SET_FWL_REGION to reconfigure the firewall?

I have provided the reference for this earlier, the sciclient_fw_testapp is an example application dealing with Firewalls.

Suman Anna said:

You can also look up the Sciclient unit test references in <RTOS SDK>/<PDK>/packages/ti/drv/sciclient/examples/sciclient_unit_testapp and sciclient_fw_testapp folders for reference Sciclient usage.

regards

Suman

Hi Jim, Jason,

FWIW, I don't think Firewalls is the root-cause for your issues. Please ensure the peripheral is powered up before using it.

regards

Suman

Any idea why GP does not need power up, but HSFS need?

Hi Jim,

Jim Zhang said:

Any idea why GP does not need power up, but HSFS need?

The Timer power behavior is agnostic of SoC device type, should behave the same way between GP and HS-FS, unless your software is creating a distinction. 

regards

Suman

Jim,

I agree that we need to start with the sciclient commands for powering the device first to see if that works.

Thanks,

Jason

Hi Jason,

Jason White said:

I agree that we need to start with the sciclient commands for powering the device first to see if that works.

If you have JTAG access, you should be able to connect to the MCU R5F core, and inspect the PSC registers associated with TIMER, specifically the MDSTAT and MDCTL registers. The MDSTAT register should read 0x103 or 0x3 with the 3 indicating the module is powered on.

The MAIN domain PSC registers should be at 0x400000 + 0x800 or 0xA00 + (lpsc_id * 4).  

regards

Suman

Suman,

Thanks.  We do have JTAG access.  This is something that we can inspect.  We should be able to easily turn it on via JTAG as well to see if that allows us to gain access to the timer.

Thanks,

Jason

Hi Jason,

Jason White said:

We do have JTAG access.  This is something that we can inspect.  We should be able to easily turn it on via JTAG as well to see if that allows us to gain access to the timer.

Sure. 

FYI, DMTIMER8 (and other related timers) are all controlled by LPSC_PER_Spare0 (lpsc_id value = 11 in the above formula).

The PSC Register details are documented in the 221_PSC0 sheet of the J784S4_Registers_Public_20250808.xlsx document.

regards

Suman

Does this mean the lpsc_id is 70 if we were to start with dmtimer0?

If it is indeed 70, which I think it is.  Then its turned off.

Same goes for TIMER8 - TIMER19.

Hi Jason,

Jason White said:

Does this mean the lpsc_id is 70 if we were to start with dmtimer0?

Yes, correct.

Jason White said:

If it is indeed 70, which I think it is.  Then its turned off.

Indeed, this reflects the default Power-On-Reset behavior. So, you have to turn on the modules without which any register accesses will trigger a bus error/data abort.

regards

Suman

Hi Suman

I am trying to build sciclient sample app (sciclient_fw_testapp) to test the permission issue.

the rm_pm_hal lib only available for mcu1_0

./lib/j784s4/mcu1_0/release/rm_pm_hal.aer5f

I always missing basic functions like devices_init, this function is at ./sciclient/src/rm_pm_hal/pm/drivers/device/device.c, but the rm_pm_hal.aer5f is only available for mcu1_0, and I am building for mcu2_0. How could we solve this issue? 

To build an app that to run on domain main0, core 0, I need enable following MACROs in the makefile,

-DFREERTOS  -DSOC_J784S4  -DBUILD_MCU  -DDBUILD_MCU2_0

Are those MACROs enough ?

Hi Jim,

Jim Zhang said:

I am trying to build sciclient sample app (sciclient_fw_testapp) to test the permission issue.

The sciclient_fw_testapp_freertos application build is currently only supported for MCU1_0 core. You will need to add build changes to be able to build this for MCU2_0. Please take a look at sciclient_unit_testapp_freertos, which is supported to be built against multiple cores.

Alternatively, you can just invoke the desired Sciclient API in your MCU2_0 application.

Jim Zhang said:

the rm_pm_hal lib only available for mcu1_0

Yes, that's correct. rm_pm_hal library is only available for the MCU1_0 core, this library is exercised underneath the SciServer, which is designed to run only on MCU1_0.

MCU1_0 applications will link against sciclient_direct library, while all other cores link against sciclient library. The MCU2_0 applications will invoke the TI-SCI messages through the SciClient layer, which is the client-side.

regards

Suman

To test this TI-SCI lib, do I need build SciServer myself and launch it on MCU1_0 ? or the the SciServer is already part of device manager, and I don't have to build and launch it myself ?

For both client and server app, do you have the remoteproc version, that we can launch them from remoteproc ?

Hi Jim,

Jim Zhang said:

To test this TI-SCI lib, do I need build SciServer myself and launch it on MCU1_0 ? or the the SciServer is already part of device manager, and I don't have to build and launch it myself ?

SciServer and Device Manager functionality are kinda analogous, the Device Manager (rm_pm_hal library) functionality is required on all MCU1_0 firmwares, and SciServer is the Server front-end task dealing with the incoming requests and invoking the appropriate API. The SciServer task is one mandatory task on MCU1_0 in addition to the other desired functionality. This is required w/o which the other cores won't be able to boot fully.

Jim Zhang said:

For both client and server app, do you have the remoteproc version, that we can launch them from remoteproc ?

The above example firmwares are meant to be used with RTOS SDK, they cannot be used by remoteproc as they lack the Resource Table and other memory-map requirements needed by Linux.

ipc_echo_testb_freertos is the default firmware used by Linux SDKs, and this does include the SciServer functionality.

If you desire to use/test the Sciclient firewall API, it is easier to add this relevant Sciclient firewall configuration to your current MCU2_0 application firmware. Alternatively, you should be able to do this same configuration in your Bootloader as well. 

regards

Suman

Let's focus on turning on TIMER0 power feature first. I still did not get the answer:

Do I need build and launch SciServer to MCU1_0 myself to get the communication going on? My understanding is: the SciServer should already be included inside device manager, otherwise the board will not boot up. Is this true?

Do I need any sciclient firewall configuration in my MCU2_0 application to turn on the power for TIMER0?

Do you have any other example that can be launch from remoteproc?

Jim,

The device manager R5 core is already running and has support for sciserver.  There shouldn't be anything you need to do with that.  This is part of the bootloader.

sciclient_unit_testapp_freertos could be a test app that runs on mcu2_0 that we can use for testing out sciclient.  Or just call the sciclient APIs from our app.

Thanks,

Jason

Hi Jason, Jim,

Jason White said:

The device manager R5 core is already running and has support for sciserver.  There shouldn't be anything you need to do with that.  This is part of the bootloader.

Minor correction, Device Manager is not part of Bootloader, but instead is the MCU1_0 application firmware booted by Bootloader (also runs on MCU1_0) at the end of its execution.

Jason White said:

sciclient_unit_testapp_freertos could be a test app that runs on mcu2_0 that we can use for testing out sciclient.  Or just call the sciclient APIs from our app.

Indeed, thanks for clarifying for your colleague.

Jim Zhang said:

Do I need build and launch SciServer to MCU1_0 myself to get the communication going on? My understanding is: the SciServer should already be included inside device manager, otherwise the board will not boot up. Is this true?

Yes, correct. This was already stated this in my previous response "The SciServer task is one mandatory task on MCU1_0 in addition to the other desired functionality. This is required w/o which the other cores won't be able to boot fully."

Jim Zhang said:

Do I need any sciclient firewall configuration in my MCU2_0 application to turn on the power for TIMER0?

No. Firewall and Power are orthogonal terms. Power is controlled by PSC module, and Firewalls can be used to whitelist/restrict the transactions of who can access a certain peripheral. No firewalls programmed implies no cores are restricted if attempting an access.

Please let me know if any further clarifications are needed.

regards

Suman

I built the TI sample app from SDK:

pdk_j784s4/packages/ti/build$ make -B sciclient_unit_testapp_freertos BOARD=j784s4_evm CORE=mcu2_0  BUILD_OS_TYPE=freertos

and load it to TI EVM board. The app is hanging on Sciclient_init(), it polls the server, but no response. The server is not working as expected?

I had same issue on my customized board, and this is why I switched to TI EVM board and check.

Hi Jim,

Jim Zhang said:

and load it to TI EVM board.

How are you doing this? What bootmode are you using for this?

Jim Zhang said:

The app is hanging on Sciclient_init(), it polls the server, but no response. The server is not working as expected?

Please combine the above MCU2_0 example image with the MCU1_0 sciserver_testapp_freertos image, and use the SBL MMCSD as your bootloader.

regards

Suman

is TI official released SBL MMCSD and Device manager downloadable ?  It looks like I need do everything from scratch.  Do you have the link to download those TI built images ?

Hi Jim,

Jim Zhang said:

is TI official released SBL MMCSD and Device manager downloadable ?  It looks like I need do everything from scratch.  Do you have the link to download those TI built images ?

They are all part of the RTOS SDK. We do package some pre-built binaries as part of the SDK, but not every example executable.

In anycase, if you need to debug the images, you need to build all the libraries and images on your image, otherwise, you will not be able to do a symbol lookup. 

regards

Suman

I thought I only need build and launch MCU2_0 app, the  MCU1_0 sciserver_testapp_freertos function  is already integrated into device manager, and I do not need build/launch  sciserver_testapp_freertos f to MCU1_0.

Need confirmation:  Do I need build and launch sciserver_testapp_freertos to MCU1_0 manually ? if yes why it is not part of device manager ?

I don't want to debug. My purpose is to find a working base for my development: using TI app without any modification, run it on a TI EVM board with TI firmware including device manager, then this app should work. 

Hi Jim,

Jim Zhang said:

I thought I only need build and launch MCU2_0 app, the  MCU1_0 sciserver_testapp_freertos function  is already integrated into device manager,

The MCU1_0 core is the application core, which needs to have a SciServer, along with whatever other application is needed (like AutoSAR MCAL, CAN application etc).

The sciserver_testapp_freertos is a Device Manager application firmware, it does not have any other functionality. So, this is the absolute minimum example firmware that you need on MCU1_0, and is mandatory, alongside any other core application firmware.

The MCU1_0 firmware is not automatically booteed. SBL will need to load and boot this firmware as part of its loading a multi-core 'app' application image. So, you need to combine a MCU1_0 firmware providing SciServer/Device Manager functionality, and any other application cores you want to run. 

Jim Zhang said:

Need confirmation:  Do I need build and launch sciserver_testapp_freertos to MCU1_0 manually ? if yes why it is not part of device manager ?

Yes. You need to build your MCU1_0 and MCU2_0 applications, combine them into an 'app' image, and have it loaded by SBL. This is what I meant in my previous response, quoting here again.

Suman Anna said:

Please combine the above MCU2_0 example image with the MCU1_0 sciserver_testapp_freertos image, and use the SBL MMCSD as your bootloader.

regards

Suman

How could you launch 2 apps (device manager and sciclient server) into mcu1_0 in the same time ?  you need build them into one app and run as 2 threads, right?

Hi Jim,

Jim Zhang said:

How could you launch 2 apps (device manager and sciclient server) into mcu1_0 in the same time ?

They are not different apps. I have already explained this terminology in my earlier response on this thread. 

Please read through the PDK 5.12. SCICLIENT module documentation to get an understanding of the Sciclient, SciServer and rm_pm_hal layering, all of this has been explained in the SDK documentation.

regards

Suman

 I am still confusing with your response: since both device manager, and sciclient server are both essential for the whole system, why TI EVM firmware does not have the server included, and I need build and load by myself? It should be included in the mmcsd card shipped with the EVM board, and now I am booting with TI mmcsd card

From the sdk, sciclient server is already part of mcu1_0, why my TI EVM board can not  get response from server? anything else could I miss ?

Hi Jim,

Jim Zhang said:

why TI EVM firmware does not have the server included, and I need build and load by myself?

The TI SDKs support multiple flavors of bootloaders, HLOS and application firmware images. So, there is no single TI EVM firmware.

Jim Zhang said:

It should be included in the mmcsd card shipped with the EVM board, and now I am booting with TI mmcsd card

The SDCard shipped with TI EVM board uses Linux U-Boot based bootloader and filesystem. The packaged binaries may also not be pointing to the latest SDK. It does use a Linux U-Boot friendly MCU1_0 application called ipc_echo_testb_freertos (which also includes a SciServer task).

AFAIU, you are trying to run a RTOS based bootloader and your own test firmwares, so you do have to build your own binaries.

Anyway, this thread has veered off quite a bit into 'SDK - Getting Started' questions from the original Timer question. Please follow the SDK documentations for this, and open a new thread if you need clarifications there.

Please summarize what you are trying to run/test w.r.t the Timer topic in this thread.

regards

Suman

It is still timer related. I am trying to use sciclient APIs to enable the power for TIMER0, and first I am trying to make sure that sciclient APIs are working. I just want to use whatever sci server the mcu1_0 app has. It does not even go through sciclient_init() yet. The test is blocked at basic sciclient lib init statge, not going to specific test yet. The  ipc_echo_testb_freertos should be able to take care of sciclient_init()  polling check request, but not.

Do you still need me to create new thread on getting sciclient APIs working topic ?

Hi Jim,

Jim Zhang said:

It is still timer related. I am trying to use sciclient APIs to enable the power for TIMER0, and first I am trying to make sure that sciclient APIs are working.

Ok.  The SDKs are well-tested, and there are no fundamental issues. And SciClient APIs are working very well.

Jim Zhang said:

I just want to use whatever sci server the mcu1_0 app has. It does not even go through sciclient_init() yet. The test is blocked at basic sciclient lib init statge, not going to specific test yet.

Please list out the exact steps that you have followed so far w.r.t running the sciclient_unit_testapp_freertos on MCU2_0 and sciserver_testapp_freertos on MCU1_0.

Jim Zhang said:

Do you still need me to create new thread on getting sciclient APIs working topic ?

We can stay on this thread if this is still related to Timer.

regards

Suman

The procedure is:

1: attach lauterbach debugger to R5 jtag

2: power on the board;

3: board is booted from mmcsd card.  (assumming that mcu1_0 is launched and running by SBL from mmcsd)

4: use the debugger to stop mcu2_0, load the sciclient_unit_testapp_freertos to mcu2_0 from debugger, and execute it

5: sciclient_unit_testapp_freertos is hanging on client/server handshaking

Hi Jim,

Jim Zhang said:

3: board is booted from mmcsd card.  (assumming that mcu1_0 is launched and running by SBL from mmcsd)

What bootmode are you using? You mentioned that board is booted from SDCard, so this implies you are using MMC BootMode.

If so, what binaries are you using on your SDCard, and how did you build them?

You need to have a tiboot3.bin (sbl_mmcsd_img), the tifs.bin and an app (that is the combined appimage of the MCU1_0 and MCU2_0 applications).

Jim Zhang said:

4: use the debugger to stop mcu2_0, load the sciclient_unit_testapp_freertos to mcu2_0 from debugger, and execute it

5: sciclient_unit_testapp_freertos is hanging on client/server handshaking

If using SDCard BootMode, then you need to boot all your firmware images using the Bootloader flow.

You cannot use a Debugger to override a previously loaded firmware with a new firmware. This flow is incorrect, as the DM firmware will have held references to resources requested from a previous firmware.

regards

Suman

I am using memory stick inside uSD CONN to boot. The memory stick came with the board, I did not touch it. the original TI firmware should be inside

If I boot all your firmware images using the Bootloader flow, how can I debug it ?

I need be able to debug client app sciclient_unit_testapp_freertos with Trace32 debugger, what is the right procedure to do it?

Hi Jim,

Jim Zhang said:

I am using memory stick inside uSD CONN to boot. The memory stick came with the board, I did not touch it.

The SDCard comes pre-populated with SDK level images for a new developer to quickly try some demos that are provided in the SDK, without having to rebuild anything.

You are trying to run a different example firmware, and this requires that you build the needed firmwares and use the new binaries to copy over to the SDCard.

This is the same as if you were to run something on the EVM, when starting from a blank SDCard.

Jim Zhang said:

If I boot all your firmware images using the Bootloader flow, how can I debug it ?

You cannot run it as is, and then use a JTAG to randomly reload new firmwares.

Anyway, these are all basic Getting Started questions. I recommend that you look through the SDK Getting Started documentation on both RTOS SDK as well as PDK documentation.

regards

Suman

The SDK docs do not have how to debug sections.

I can rebuild bootloader with  sciserver_testapp_freertos and  sciclient_testapp_freertos

if I launch all those firmware from SBL, how could I hold sciclient_testapp_freertos and debug? The app is already starts, and if it has issue, it already crashes

Hi Jim,

Please read through the entire contents of 6. Bootloader (SBL) section and the 6.2.11. How to Guides sections of the PDK. Every thing that I have stated is already documented there.

Jim Zhang said:

if I launch all those firmware from SBL, how could I hold sciclient_testapp_freertos and debug? The app is already starts, and if it has issue, it already crashes

You can add a while loop in the application code at the appropriate place, so that you can connect to the application at a known point and then proceed with debug.

FYI, below is an excerpt from the SBL section of the SDK documentation.

Please also see this related [FAQ] TDA4VM: Debugging remote core firmware using CCS

regards

Suman

Hi  Jason White 

Suman Anna said:

Indeed, this reflects the default Power-On-Reset behavior. So, you have to turn on the modules without which any register accesses will trigger a bus error/data abort.

Circling back to this, were you able to resolve your Timer access issues when powering on through JTAG?

You can either power up this Timer module in your Bootloader or in your MCU2_0 application.

regards

Suman

everything is blocked by this sciclient lib. We need get this work first, then verify if we can turn on the power or not. So please don't mark "TI Thinks Resolved"

JTAG write to address 0x400918 is also denied, so we can not turn on the power through JTAG. I am able to turn on turn off the power for timer on EVM board, but not able to do the same on HS-FS board

Hi Jim,

Jim Zhang said:

everything is blocked by this sciclient lib.

I clarified that this is because of the incorrect way the JTAG is being used to load a different firmware image on an already running system.

Have you followed the SBL Boot on SDCard steps of using a tiboot3.bin, tifs.bin and the combined app?

Jim Zhang said:

We need get this work first, then verify if we can turn on the power or not. So please don't mark "TI Thinks Resolved"

The rootcause is explained previously and the solution is clear - you need to turn on the TIMER0 in your firmware application s/w or Bootloader.

regards

Suman

Hi JIm,

Jim Zhang said:

JTAG write to address 0x400918 is also denied, so we can not turn on the power through JTAG.

0x400918 is a MDSTAT register, which is a Read-Only Register. So, you cannot write it from JTAG (or from regular code either).

You need to be modifying the appropriate MDCTL and PTCMD registers to trigger a transition if trying to power this up using JTAG.

Jim Zhang said:

I am able to turn on turn off the power for timer on EVM board, but not able to do the same on HS-FS board

There should be no difference in sequence between GP and HS-FS devices. There is no HS-FS device on the TI EVM, so I am assuming this is your board.

How are you turning ON and OFF the timer on EVM board? TIMER0 is powered up by SBL on TI EVM.

regards

Suman

I used lauterbach scripts to turn on/off power with the specific module id and device id. I can check the value changed in address 0x400918 from 0x1F03 to 0xA00, and vice versa