EK-TM4C129EXL: Getting a Fixed Period Short Delay

I found this which seemed to answer my question:

CCS/EK-TM4C129EXL: EK-TM4C129EXL : delay time - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

So using MAP_SysCtlDelay (in ROM) will avoid the prefetch issues:

"For better accuracy, the ROM version of this function may be used. This version will not suffer from flash- and prefect buffer-related timing variability but will still be delayed by interrupt service routines."

I tried this and it does not fix the issue, suggesting that prefetch is not causing what I am seeing.

I tried to ensure consistent alignment by putting the code into a function:

__attribute__ ((aligned (4))) void set_hw_timers(void)
{
set_test_pin();
TimerEnable(TIMER0_BASE, TIMER_B);
MAP_SysCtlDelay(4);
TimerEnable(TIMER0_BASE, TIMER_A);
clear_test_pin();
}

Again this does not fix it.

The variability seems to occur across builds, so adding/removing code elsewhere in the program affects the execution time of the code above. This difference is visible on a logic analyser. There is no optimisation in this program and no interrupts occurring when this code runs.

Thanks,

Matthew

Matthew Constance said:

"For better accuracy, the ROM version of this function may be used. This version will not suffer from flash- and prefect buffer-related timing variability but will still be delayed by interrupt service routines."

Hi Matthew,

  ROM_SysCtlDelay would execute code from ROM which is single cycle. There is no piplining as in flash. Flash natively has a slower single cycle access time and therefore pipelining comes into the picture to read ahead of time before CPU reads. 

Matthew Constance said:

I tried to ensure consistent alignment by putting the code into a function:

__attribute__ ((aligned (4))) void set_hw_timers(void)
{
set_test_pin();
TimerEnable(TIMER0_BASE, TIMER_B);
MAP_SysCtlDelay(4);
TimerEnable(TIMER0_BASE, TIMER_A);
clear_test_pin();
}

Again this does not fix it.

The variability seems to occur across builds, so adding/removing code elsewhere in the program affects the execution time of the code above. This difference is visible on a logic analyser. There is no optimisation in this program and no interrupts occurring when this code runs.

How many cycles are you off between set_test_pin() and clear_test_pin()? I will suggest you not call set_test_pin and clear_test_pin because these two functions will subject to pipelining when fetching code from flash. Can you directly use HWREG to set and clear the pin. Perhaps for TimerEnable as well by directly using HWREG to enable Timer_B and Timer_A. Another option is to call ROM_TimerEnable instead of TimerEnable. You will need to do the same for any API calls in set_test_pin and clear_test_pin to only use the ROM version. Hopefully you will get a better control of the cycles. 

Hi Charles,

Thank you for the advice, I will try these things and let you know how I get on.

Regards,

Matthew

Hi Charles,

I have done some testing.

Firstly I found that when switching off the prefetch using the following line as a test the variability went away:

HWREG(FLASH_CONF) = FLASH_CONF_FPFOFF;

I then changed the program as advised (below). There was still some variability until I put the function into RAM, now the cycles seem the same for all builds.

I would not attempt to do this myself, but out of curiosity, do you ever have customers who switch off prefetch permanently? It would obviously slow down applications but would make the timing more deterministic which is important in certain cases.

__attribute__ ((ramfunc)) void start_timer0_a_b(void)
{
// NOTE: Timer start needs to be offset for double edged clock to get correct phase
// between continuous clock & SSI clock.
#if 1
MAP_GPIOPinWrite(GPIO_PORTD_BASE, GPIO_PIN_2, GPIO_PIN_2);  // set test pin
MAP_TimerEnable(TIMER0_BASE, TIMER_B); // DMA

__nop();
__nop();
__nop();
__nop();

// Adjust NOPs to get desired phase shift

MAP_TimerEnable(TIMER0_BASE, TIMER_A); // PWM
MAP_GPIOPinWrite(GPIO_PORTD_BASE, GPIO_PIN_2, 0);                   // clear test pin
#endif
}

Regards,

Matthew

Matthew Constance said:

There was still some variability until I put the function into RAM, now the cycles seem the same for all builds.

Hi Matthew,

  Looks like you found a consistent solution across builds without variability. RAM access is always single cycle. Having said that, if you run the function from RAM, then I don't think you need to turn off prefetch for flash as prefetch will not affect the code execution from RAM. Is that what you are seeing?