RM44L520: Strange Behaviour After Using RTI to Create a Hardware Timer

Andrew Mercer said:

the hardware delay function all of the LEDs turn on as expected.

Does hardware delay function use RTI compare 0 or compare 1?

It uses RTI compare 1. 

When I run the program I have been watching the RTI registers and everything with the timers seems to be working as expected. I have tried disabling RTI channel 1 at the end of the hardware delay function and reenabling it at the top and the FRC1 register does stop counting up as expected. When I do this the LED on function still doesn't run when called after the delay function has returned but does run when placed on the last line of the delay function. 

The RTI is configured in prvSetupTimerInterrupt(), and prvSetupTimerInterrupt() is only called after vTaskStartScheduler() is executed.

Have you programmed the address of hpiTimer_DelayInMicroSeconds() to VIM table? You can do it using the ways below:

1. Change the VIM table defined in HL_sys_vim.c

static const t_isrFuncPTR s_vim_init[128U] =
{
    &phantomInterrupt,
    &esmHighInterrupt, /* Channel 0 */
    &phantomInterrupt, /* Channel 1 */
    &vPortPreemptiveTick, /* Channel 2 */
    &hpiTimer_DelayInMicroSeconds, /* Channel 3 */

2. Change the VIM table in your main()

    vimRAM->ISR[3] = &hpiTimer_DelayInMicroSeconds;

The compare 1 interrupt is not enabled in your RTI setting in prvSetupTimerInterrupt():

Is it enabled somewhere else?

Thank you for the replay. Right now I have channel 3 set to &rtiCompare1Interrupt. If I have the interrupt initially configured by the prvSetupTimerInterrupt() at the RTOS start time and I modify the registers during run time in the hpiTimer_DelayInMicroSeconds() function why would that function need to going into the VIM table? Wouldn't the hpiTimer_DelayInMicroSeconds() function just be used to set the registered and the rtiCompare1Interrupt be used in the background to create the interrupt. Sorry if I have a misunderstanding here 

The compare 1 interrupt is enabled at the beginning of the hardware delay function 

I did this so I can enable the interrupts on channel 1 while the delay function is in use and disable it when it is no longer needed 

I might misunderstood your question. 

rtiCompare1Interrupt() is the ISR for RTI compare 1. The hpiTimer_DelayInMicroSeconds() is not a ISR and is called in a task or in rtiCompare1Interrupt(), right? 

Andrew Mercer said:

If I place the LED on function under the hpiTimer_DelayInMicroSeconds() function call the LEDs do not turn on.

Can I assume the hpiTimer_DelayInMicroSeconds() is not called?

Sorry about that I'll try and make my explanation a bit more clear. The hpiTimer_DelayInMicroSeconds() is a function that is called in a task. When I put the LED on function call at the end of the hpiTimer_DelayInMicroSeconds() function all of the LEDs turn on as expected, so the hpiTimer_DelayInMicroSeconds() function is being called properly. If I then remove the LED on function call from the hpiTimer_DelayInMicroSeconds() function and put the LED on function call in the task itself one line below the hpiTimer_DelayInMicroSeconds() function the LEDs do not turn on. For some reason, after the hpiTimer_DelayInMicroSeconds() function has been fully executed it never returns to the tasks main function. 

Both compare 0 and compare 1 use counter 0, and compare 2 uses counter 1. 

But your code reads the counter 1 free-running register, and compare the compare 1 register who uses the counter 0 and counter 1 free-running register. 

Can you change portRTI_COMPCTRL_REG = 0x00000010U | 0x00000000U;  --> let compare 1 use counter 1?

I modified the line and I am still having the same issue as before. 

What does your rtiCompare1Interrupt() do? The code execution jumps to the RTI ISR when the free running counter reaches the value in compare register.

If  hpiTimer_DelayInMicroSeconds() is only to insert a delay, you don't need to enable the interrupt for compare 1.

How about change this line to:

portRTI_SETINIENA_REG &= 0xFFFFFFFD; //disable the interrupt for compare 1

That seems to fix the issue. I'm a bit confused about what the issue was.