Systick time missing

[SRedd.5]

I am running the motor control workbench B-G431B-ESC1 board. The systick fires at every 2K frequency as per the user manual and the waveform matches when i toggle, but the problem is sometimes it misses as shown

I want to debug and find out why it misses those timings in between. Please suggest how do i find out? I am also running CAN in parallel at 500KBPS.

[SRedd.5]

It does not solve the problem still i get some missing times.

[LCE]

What's happening if you turn of other interrupts, or at least do nothing (except setting a flag maybe) in the interrupt handlers?

[LCE]

BTW, the skipped pulse on the scope looks quite regular, maybe you show the interrupt handler where you toggle the GPIO.

And have you reduced the other interrupts' priorities?

[SRedd.5]

I have shown the code in my 2nd post. I have put the CAN interrupt lowest but unfortunately I am using the Systick as the base time for CAN as well do I need to use other timer. There is huge code in CAN and transmitting lot of messages around 9 with periodicity of 1 sec.

[LCE]

There's a lot happening in your SysTick_Handler, why that divider? 
That makes me assume that you are using a very high SysTick frequency, which again means that this interrupt handler is called too often. It should be good enough with 1 kHz for most applications.

And yes, try using another timer as base time for CAN.
You are using it for timeouts, message scheduling or what?

[LCE]

And again:
what's the time between the dropped pulses?
Maybe that might tell you something.

[SRedd.5]

Mainly for CAN message scheduling.

[Karl Yamashita]

You need to exit the systick quickly when it interrupts so other interrupts can fire, as well as the systick itself. In your systick, set a flag. In a main while loop check the flag and then call your 3 tasks

MC_RunMotorControlTasks();
CAN_Task();
HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_12);

[Johi]

, I still wonder if you have reflected on the thought of driving your I/O directly with a timer unloading your MCU and guaranteeing timing as per hardware? ARM/STM32 is designed for that approach and then you are 100% sure that timing is correct. If it takes too much time to solve the issue using interrupt priorities and the like, then for sure you risk that your final solution will not have maximal robustness as environmental conditions can vary. You can change frequency and duty cycle from your main loop but leave the heavy lifting to the hardware timer driving the I/O.

[SRedd.5]

I have to study about this i never done it before. I will give a try.