High Speed PIT generating slow heartbeat

[PMaq]

Hi, I am attempting to generate a 5MHz-10MHz heartbeat pulse using a high priority interrupt + GPIO toggle, via PIT.
I've setup S32DS PIT and IsrCtrl RTDs in such a way that I am able to trigger the notification interrupts periodically, however, I am only getting a max heartbeat of around 10kHz.
My "Clocks" tab shows my PIT Clock is set to run at 30MHz.

I have a setup using FreeRTOS, RTD v7.0.0, and programming on a S32K312MINI-EVB development board.

Is there another clock configuration in between the 30MHz Clocks tab and actually generating the interrupt notification?
How does the 30MHz PIT clock relate to the count value start function? is it simply 33ns*count?
Pit_Ip_StartChannel(uint8 instance, uint8 channel, uint32 countValue)

I tried achieving the same results using a regular GPT but similarly got slow pulses.
I noticed the PIT configuration shows GptIsrEnable and GptChannelUsed and was wondering if there is a common configuration between the two that may cause the slow behaviour?

[Julián_AragónM]

Hi @PMaq,

Most likely this is a SW overhead issue, constant PIT ISR is starving the system, not to mention you are also adding FreeRTOS and most likely toggling the pin through high level APIs: how to improve S32k3 interrupt callback execute speed?.

If your goal is to only toggle a GPIO (no communication or specific toggle patterns), I suggest using a different module, either eMIOS output compare PWM or even LCU/TRGMUX so you can toggle the pin by hardware instead of software. 

Also take care on which GPIO pad type you are using, as that will limit your switching rate. In your case, if 10MHz is the maximum spec, then it will not matter, as the GPIO-Standard types switch up to 10 MHz:

Best regards,
Julián

[PMaq]

Thanks for all the info you shared.
Unfortunately, I need to send out pulses of specific sequences/patterns (non-comms) at 10MHz, so I can only do this feature through fast interrupts.
Using Pit_Ip_ProcessCommonInterrupt also didn't help much as the delay from 10MHz->10kHz was just too wide a gap.

Some additional info that may help:
I have a separate module using emios PWM running up to the hundreds of kHz range so at least the peripheral clocks are fine (note: this emios PWM doesn't run at the same time as the 10MHz PIT pin).
Additionally, I configured one pin as clock out and confirmed that my core clocks, AIPS Fast/Slow Clocks, PLLs Clocks, etc were all as stated in the "Clocks" tab of the RTD.

May I ask if there is a way to lower the priorities of the FreeRTOS by a step so I could make this task as the highest priority?

May I also confirm with you if I wanted to have a have a 10MHz interrupt running on my 30MHz PIT clock, then I just need to set the period to "3" when I start the PIT - Pit_Ip_StartChannel(1, 0, 3)

Lastly, may I ask if you have any quick reference links to check what peripherals use what clocks? especially within an RTOS environment? Thanks!

[Julián_AragónM]

Hi @PMaq,

Sorry for the late reply.

I can help you optimize the GPIO switching. However, this will not replace or come close to switching the pin through HW. You can strip the RTD function to just switching the pin through registers:

IP_SIUL2->MSCR[29] ^= SIUL2_MSCR_OBE_MASK;

Using Pit_Ip_ProcessCommonInterrupt also didn't help much as the delay from 10MHz->10kHz was just too wide a gap.

The reason I pointed you to the community post was to explain the process when PIT enters interrupt, it does not only go through the callback, but also through the interrupt process from RTD, meaning it is significantly slower.

May I ask if there is a way to lower the priorities of the FreeRTOS by a step so I could make this task as the highest priority?

You can lower the interrupt priority for the interrupt controller inside the configuration container:

May I also confirm with you if I wanted to have a have a 10MHz interrupt running on my 30MHz PIT clock, then I just need to set the period to "3" when I start the PIT - Pit_Ip_StartChannel(1, 0, 3)

Yes, however, the PIT may not be able to process the interrupt with a period of 3.  

Lastly, may I ask if you have any quick reference links to check what peripherals use what clocks? especially within an RTOS environment? Thanks!

You can refer to S32K3XX's reference manual. Chapter 24.6 shows peripheral clocking. For example, PIT uses AIPS_SLOW_CLK:

One last thing to consider is that if you are toggling your pin inside the PIT callback, this will result in an output square-wave frequency that is half the interrupt frequency.

Best regards,
Julián

[Julián_AragónM]

Lastly, may I ask if you have any quick reference links to check what peripherals use what clocks? especially within an RTOS environment? Thanks!

You can refer to S32K3XX's reference manual. Chapter 24.6 shows peripheral clocking. For example, PIT uses AIPS_SLOW_CLK:

One last thing to consider is that if you are toggling your pin inside the PIT callback, this will result in an output square-wave frequency that is half the interrupt frequency.

Best regards,
Julián