TDA4VH-Q1: Does DSP C71 support the timer function?

Part Number: TDA4VH-Q1
Other Parts Discussed in Thread: TDA4VH

Tool/software:

Hi,

Platform:TDA4VH J784s4-evm  C71x(1 GHz)

SDK:ti-processor-sdk-rtos-j784s4-evm-09_02_00_05

We want to use the timer function on the DSP. I see that the csl library has some related functions. When I looked at its test program(csl\test\dmTimerUt\dmTimer_funcTest.c), I found that some macro definitions are related to the mcu. I wonder if I can use these on DSP.

Thanks,

  • Hi,

    Yes, you can use an available MAIN domain dmTimer for C7x (see details in section 5.5.8 DMTIMER in the TRM). I assume you are asking this in a baremetal context, otherwise there are options using freeRTOS. 

    Could you expand on what you would need to use the timer for? Then I could provide further help.

    Best,

    Asha

  • Hi,

      Yes,we are running  in a baremetal context. We're going to use it for a scheduled task, one call per ms on DSP.Are there test cases in the SDK?

    Thanks,

  • Hi,

    You can look at pdk/packages/ti/osal/src/nonos/timer/v1/TimerP_nonos.c for the API functions in this case. You can also see the default timer allocation that is typically done for C7x for FreeRTOS/SafeRTOS in pdk/packages/ti/osal/soc/j784s4/osal_soc.h

    Best,

    Asha

  • Hi,

      I used the library \ti\osal\lib\nonos\j784s4\c7x\release\ti.osal.ae71. After configuring the timer, the program cannot enter the interrupt function.

      My configuration code:

      

    void T_func(void *arg){
        timerIsrCount++;
        //printf("INFO: this is T_func timerIsrCount = %d\n",timerIsrCount);
        return;
    }
    int32_t  id    = 0;
    TimerP_Params_init(&timerParams);
       timerParams.runMode    = TimerP_RunMode_CONTINUOUS;// 0 Timer is periodic and runs continuously
       timerParams.startMode  = TimerP_StartMode_USER;    //1 Timer will be started by the user
       timerParams.period     = 5000U;
       timerParams.periodType = TimerP_PeriodType_MICROSECS; //0 Timer period unit is in micro seconds
    
       timerParams.intNum     = 15;
       timerParams.eventId    = 0x4e1;
    
       handle = TimerP_create(id,(TimerP_Fxn)&T_func,&timerParams);
       if (NULL_PTR == handle)
       {
           printf("ERR: Timer Create error \n");
       }else{
           printf("INFO: TimerP_create() success.\n");
           timer = (TimerP_Struct *)handle;
           printf("INFO: timerId = %d\n",timer->timerId);
           printf("INFO: runMode = %d\n",timer->runMode);
           printf("INFO: startMode = %d\n",timer->startMode);
           printf("INFO: period = %d\n",timer->period);
           printf("INFO: periodType = %d\n",timer->periodType);
           printf("INFO: freqHi = %d\n",timer->freqHi);
           printf("INFO: freqLo = %d\n",timer->freqLo);
           printf("INFO: intNum = %d\n",timer->intNum);
           printf("INFO: eventId = 0x%x\n",timer->eventId);
           printf("INFO: hwi = 0x%x\n",timer->hwi);
           printf("INFO: tickFxn = 0x%x\n",timer->tickFxn);
       }
       
       timerStatus = TimerP_start(handle);
       if (TimerP_OK != timerStatus) {
           printf("Err: Coult not start the timer %d \n", id);
       }else{
           printf("INFO: TimerP_start() success.\n", id);
       }

    log:

    INFO: TimerP_create() success.
    INFO: timerId = 0
    INFO: runMode = 0
    INFO: startMode = 1
    INFO: period = 95999
    INFO: periodType = 1
    INFO: freqHi = 0
    INFO: freqLo = 19200000
    INFO: intNum = 15
    INFO: eventId = 0x4e1
    INFO: hwi = 0x7041f1e8
    INFO: tickFxn = 0x70416bdc
    INFO: TimerP_start() success.

    I found that the variables period and periodType are not consistent with my configuration.May I ask what causes this.

    timer->tickFxn points to the same address as the interrupt function I set up.timer-> The hwi address points to a value of 1.But the program doesn't seem to enter T_func().Please help to analyze the reason.

    Thanks,

  • Hi,

    Thank you for posting the details. I will look further tomorrow into the APIs of the timer function to see where the issue might be coming from and give you an update. One possible step forward for you right now, is trying to step through the code of the TimerP_create function and seeing for the period and periodType issue, why those are not updating. 

    Best,

    Asha

  • Hi,

       Instead of linking the osal library, I tried to open timer by compiling source files. I want to know what macro definitions I should add when I compile through CCS. Where can I get this information? So far I have analyzed the source code and added two macro definitions: SOC_J784S4 and BUILD_C7X. I don't know if I'm missing any macro definitions. The compiled program runs as before, without entering the interrupt function.
       The values returned by the program are all correct. Is there any way to view timer status and interrupt vector table. I suspect there is something wrong with the initialization of the interrupt.

       

    Thanks

  • Hi,

      timer->period, timer->periodType is modified:

      Modified in this function TimerP_dmTimerSetMicroSeconds(timer, timer->period)(TimerP_nonos.c 236).

    timer->period = prdCounts;      249
    timer->periodType = TimerP_PeriodType_COUNTS;   250

    counts are calculated based on clock frequency and then assigned to period.There seems to be no problem here.It is not this modification that prevents access to the interrupt function

    Thanks,

  • Hi,

    So to clarify, is the issue now solely that the interrupt function is not being called? The issue where your values were not being correctly updated is now resolved?

    Let me consult with my colleagues to see what the most straightforward way to debug this would be. I will provide an update on this on 6/18

    Best,

    Asha

  • Hi,

      Values are not updated correctly. Above I just want to express where this value has been modified. The TimerP_dmTimerSetMicroSeconds() function updates a new value with a formula based on the value given by the user. I'm not sure if this update is correct.

    Thanks,

  • Hi,

     May I ask how to debug this problem?

    Thanks,

  • Hi,

    After I start the RTOS and then initialize the timer, it can be used normally.Next I did a test. After OS_init() is used, the timer cannot enter the interrupt function. When OS_start() is called, the timer starts working and I can also enter the interrupt function.Is there a step in OS_start() that enables the timer? If so, how do I do this step without using an RTOS?

    I also wonder if bare metal is missing the configuration of Hwi_vector_table.c's hardware interrupt.

    Thanks,

  • Hi,

    I apologize for not being able to get to your questions in a timely manner. Due to bandwidth issues, I will need to look at this next week.

    Best,

    Asha

  • Hi,

      After initializing the timer, you need to call Hwi_enable() to use the timer. But for now the library I linked to is freertos/ti.osal.ae71. Direct link nonos/ti.osal.ae71 still does not enter interrupt function.I guess there's a difference in interrupt initialization between the two libraries, but I'm not sure what that difference is.At the same time, please ask if there is a way to test the accuracy of the timer.

       I hope you can provide a baremetal timer use case.

    Thanks,

  • Hi

      When can you provide a demo about the use of timers in DSP bare metal environment?

    Thanks,

  • Hi Chen Chen,

    I do apologize for not getting your thread in a timely manner due to my bandwidth issues. 

    I discussed this issue with our development team. We would recommend going forward with running FreeRTOS on the C7x core, as this is what we directly support - our current PDK examples (listed here) do not have baremetal examples for C7x. Trying to run the timer APIs in baremetal context on C7x has likely not been tested on our end due to this, which would explain the difficulties you have had. At the higher application level our vision apps demos and TIDL framework will use FreeRTOS running on the C7x core so this can be another point of reference. I see that you have validated the timer interrupt with FreeRTOS and this has worked - can this be a path forward then?

    Again I apologize for not responding to your thread - let me know if you have follow ups regarding this and I will respond. 

    Best,

    Asha

  • Hi,

      We can use a timer. And I have done tests, we can use DMTIMER0~DMTIMER7. But now the problem is that I have to rely on some libraries (lib\freertos\ti.osal.ae71, lib\c7x\ti.kernel.freertos.ae71). I don't know what parameters are configured for interrupts in these libraries.

    Thanks

  • Hi Asha, 

    Since it is implemented under FreeRTOS, it should be more easy to implement in baremetal, as C71x DSP documents is not detail, I did not find find interrupt chapter in C71x_Corepac_spruiq3.pdf, we don't know the interrupt event map logic, interrupt status, interrupt vector, register etc,  it is not possible for user to implement by themselves.

    I think there should be someone is familiar with it. if there is block diagram, flow chart, and instruct which document to refer to should help.

    Also I think if provide a simple baremetal demo should not be very time consuming. a interrupt vector .asm, interrupt event map,  vector address init, timer registers init, core pack interrupt register enable/disable, should be enough for that.

    How do you think?

  • Hi Chen Chen,

    I don't know what parameters are configured for interrupts in these libraries.

    Looking at the FreeRTOS port for C7x, the timer initialization is done within PDK at kernel/freertos/portable/TI_CGT/c7x/port.c 

    prvPortInitTickTimer(void) has this TimerP initialization, and there are some differences in this compared to what you have posted above. I would recommend looking into this if you proceed with this route. The libraries that you mention earlier would include the functionality in this port.c file. 

    Tony -

    For interrupt behavior, the document that I would point you to would be C71x DSP CPU, Instruction Set, and Matrix Multiply Accelerator User Guide, rather than the Corepac document. Unfortunately, there is not a diagram flow in this, but there is some information regarding interrupt handling here.

    In terms of a baremetal demo, we are not supporting baremetal development for C7x. I have pointed out some of the implementation of the FreeRTOS port that can serve as a reference.

    Best,

    Asha