Mity CPU Platforms » MitySOM-AM57X

For the benefit of others, Stanley has also posted this question to an E2E forum at https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1369167/am5728-clock-timer-and-power-idle-questions.

1. Why the DRA7XX and not the AM572X example from TI as starting point

The DRA7XX and AM572X are very similar with respect to the type of CPUs for the DSP and the ARM. The difference seems to be in how many cores and the exact set of peripherals. These differences don't really matter for this example. The AM572X_bios example is different from the DRA7XX_linux example with respect to which CPU is the server and which is the client.

In the Dsp2.cfg there is a section labelled TICK excerpt below.
2. If the ti.sysbio.knl.Clock is not included here then there will no clock for timers?
3. We must create a timer to call doTick to have timeouts on call like MessageQ_get()?

It seems like all the timer creation is done in the .cfg files. There doesn't seem to be a need to create a timer or provide a function to call doTick in code external to the cfg file. There has been some experience where not having the TICK section seems to affect the ability to reliably connect to the DSP CPU for debugging with a JTAG connection. It seems like this is a good template to follow in general.

In the lines with Timer.intFreq.hi and Timer.intFreq.lo it is important to have the intFreq.lo value match the real frequency being used to source the dmTimers. This can be determined by reading CTRL_CORE_BOOTSTRAP at 0x4A00_26C4. bits[9:8] 1=20M, 3=19.2M, 2=27M. If you have the wrong value, then some timers (like Task.sleep()) might be off.

4. Where is IpcPower_Idle defined? In the power management module?

Try ti/ipc_3_50_04_08/packages/ti/pm. There are source files showing what IpcPower_idle does.

5. Why is the purpose in this example of bringing in the power management module?

It is not clear what the purpose is for the power management module. We have had some experience where including these lines has apparently led to two oddities.

• When doing a timing test, after about a dozen iterations of the test, the systems seemed to be stuck in a Task_sleep() call.
• When using Code Composer to connect to the dsp target via JTAG, an error 1180 indicating the target was in reset was given.

Both of these oddities went away when the IpcPower_idle lines were commented out.

Thanks for the all the info John. I posted to e2e also hoping TI could provide some more info on how dmtimer and clock modules work. Probably a tutorial somewhere on there. Seems like plenty of reference material but light on user manual type stuff.

It seems like all the timer creation is done in the .cfg files. There doesn't seem to be a need to create a timer or provide a function to call doTick in code external to the cfg file. There has been some experience where not having the TICK section seems to affect the ability to reliably connect to the DSP CPU for debugging with a JTAG connection. It seems like this is a good template to follow in general.

NOTE: I'm doing all this testing building from command line on a linux server and then downloading image to DSP2 so my changes may hose up someone using CCS.
FYI: For experimentation, I did build the example with no timer entries in Dsp2.cfg and MessageQ_get() with a timeout of (1000) and loop basically waited forever. Pretty much what I expected based on your statement about all timer creation done in .cfg file. I then added statements to get the clock periond and the clock tick value before and after the MessageQ_get() times out.

      UInt32 time1 = Clock_getTicks();
      Uint32 ctp = Clock_tickPeriod;
      Log_print1(Diags_ENTRY | Diags_INFO, "Clock_tickPeriod %ld", ctp);

      status = MessageQ_get(Module.slaveQue, (MessageQ_Msg *)&msg, 1000);
      if (status < 0) {
        Log_print1(Diags_ENTRY | Diags_INFO, "No message #%d", status);
        UInt32 time2 = Clock_getTicks();
        Log_print2(Diags_ENTRY | Diags_INFO, "Ticks before %ld after %ld", time1, time2);
        goto leave;
      }

After replacing all the timer related entries in Dsp2.cfg with the following:

var Clock = xdc.useModule('ti.sysbios.knl.Clock');
Clock.tickSource = Clock.TickSource_TIMER;

I got a value of 0 before timeout and 1 after timeout

[ 0.000] [t=0x000f3cbc] Server: DBG> starting main loop, running = 1, initializing = 0xd
[ 0.000] [t=0x000f95f6] Server: Clock_tickPeriod 1000
[ 0.001] [t=0x00179c28] Server: No message #-6
[ 0.001] [t=0x00180b17] Server: Ticks before 0 after 1
[ 0.001] [t=0x0018611b] Server: <-- Server_exec: -6

When I try to build the application, I am getting the error "error #10056: symbol "ti_ipc_remoteproc_ResourceTable" redefined: first defined in "./rsc_table_vayu_dsp.obj"; redefined in "/home/xxx/workspace_v10/rtos_template_app_am572x_c66_ipc/Debug/configPkg/package/cfg/main_pe66.oe66"
error #10010: errors encountered during linking; "rtos_template_app_am572x_c66_ipc.xe66" not built"

How to solve this?

Solved the error by adding botton lines to to the ipc.cfg
var Resource = xdc.useModule('ti.ipc.remoteproc.Resource');
Resource.customTable = true;

Arun Krishnan wrote in RE: Clock, Timer and Power Idle:

Solved the error by adding botton lines to to the ipc.cfg
var Resource = xdc.useModule('ti.ipc.remoteproc.Resource');
Resource.customTable = true;

This was not mentioned in the wiki page

Please note that the wiki page Memory_Overview does have a link to Customizing Multicore Applications which does mention the need for the Resource.customTable.