c6678 timers for multicore

Aamir,

First of all, you should not use CSL's timer and interrupt management APIs within a SYS/BIOS application.

SYS/BIOS should manage the timers and the interrupts associated with them in order to insure proper kernel behavior.

I believe the ti.sysbios.timers.timer64.Timer module will natively provide you with precisely what you want and allow your timer interrupt handlers to safely post Semaphores (which I see you wanting to do in the C code you attached).

In order for all 8 cores to share a common timer interrupt, you must use one of the 8 shared timers. For your device, these are timers 8 through 15.

Try this:

Timer.create(8, '&TimerTick', timerParams);

I believe this will give you what you want. Every 10ms all 8 cores will be interrupted and their copy of TimerTick invoked.

The example above borrows a little from the example provided in the CDOC for the timer64 Timer module shown here:

    http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/bios/sysbios/6_33_04_39/exports/bios_6_33_04_39/docs/cdoc/ti/sysbios/timers/timer64/Timer.html

Alan

Alan,

Okay I take it then I should not call any of the CSL or INTC APIs including calling my setup_continuous_timer which has many calls to the above.

I tried what you suggested and it could not compile as it gave an "unresolved symbol TimerTick"

Aamir

Remove the 'static' from in front of your TimerTick() declaration. And also remove the CSL_intcEventClear() call:

static void TimerTick (void *arg)
{
    /* Increment the number of interrupts detected. */
    timerISRCounter++;

    timerTickCount = 1;
    //Semaphore_post(semTimerTick);

    /* Clear the event ID. */
    CSL_intcEventClear((CSL_IntcEventId)arg);
}

Thanks,

I did get it to compile but when I ran it, my output looked like the following: I would have expected the TSCL to increment by 30,000,000.

Aamir

[C66xx_1] ************************************************

[C66xx_1] ************** MS Started on Core 1 ***********

[C66xx_1] ************************************************

[C66xx_1] home addr=2

[C66xx_1] core 1 can start receiving and sending

[C66xx_1] TSCL=418873 timerISRCounter=5

[C66xx_1] after TSCL=11675677 timerISRCounter=8

[C66xx_1] **********************************************

[C66xx_1] *** MS Ended on Core 1 ***

[C66xx_1] **********************************************

[C66xx_0] ************************************************

[C66xx_0] ************** MS Started on Core 0 ***********

[C66xx_0] ************************************************

[C66xx_0] home addr=1

[C66xx_0] core 0 can start receiving and sending

[C66xx_0] TSCL=420463 timerISRCounter=5

[C66xx_0] after TSCL=19902819 timerISRCounter=8

[C66xx_0] **********************************************

[C66xx_0] *** MS Ended on Core 0 ***

[C66xx_0] **********************************************

I believe each core has its own copy of timerISRCounter.

You'll have to place timerISRCounter at a fixed shared memory space if you want all cores to operate on the same variable.

Alan

Oops. I didn't fully read your post.

The TSCL is incremented at the processor clock speed.

Based on your CPU clock speed you can calculate how many cpu clock periods occur in 30ms.

Alan

yes my clock speed is 1GHz so I expect 30ms to correspond to 30,000,000 cycles.

I actually had that all working using the CSL and intc for a single core with the PA and switch etc receiving packets together with my proprietary code. I just hit a snag when I went to multicore. Why is it that I cannot have all the cores have separate interrupts go off with separate timers and then each call the timerTick function and give control back to my main task. Basically the intent is for me to setup the switch, PA etc then go into a main while loop that receives packets form the outside, processes them and then essentially waits till 10ms has elapsed at which time, I am expecting all my processing to complete, and then an interrupt gets timerTick to be called which gives control back to the main task to read more packets and process them.

Thanks, Aamir

Alan,

Please disregard my note above about the cycle discrepancy. I needed to remove the System_printfs that were happening between the time I started the maintask and the point where I had the last system printf expecting the count to go up by 30,000,000. Once I remove them, as expected my cycle difference is right. Previously as I was setting up the timers using the CSL and intc, I could system_printf prior to starting the timer and then after the point where I was measuring the time difference elapses without any impact on the cycles measured.

Thanks, Aamir

Yes, it is working now. I will mark it as answered.

General question just to understand it better: Why could I not use the CSL, INTC calls with sysbios (what would appear to be unstable in the kernel behaviour?) as it appeared that I was able to get it all working with a single core?

Secondly, If I wanted to stagger all the cores so that they woke up for processing every 10ms, offset from one another, so as to distribute the peak core usage from a thermal perspective, could I do that with timers 0-7 as opposed to one of the common timers 8-15?

Thanks, Aamir

Aamir,

If you're opening new lines of inquiries, please start new threads.

Otherwise:

1) I think that in fact, your single-core CSL INTC usage was a ticking time bomb. The commented out call to Semaphore_post() in TimerTick() was probably removed because it did not work as expected. In order for an ISR to call Semaphore_post() (or Swi_post()) and get the desired behavior, some kernel house keeping must be performed prior to entering the ISR function and immediately after exiting the ISR function prior to returning to the interrupted thread. This house keeping is NOT performed by the CSL code.

2) I think you would get the behavior you want using timers 0-7. But you will have to configure the 'owner' for each of the Timers to match the core you want the corresponding timer interrupt to occur on.

Alan