cancel
Showing results for 
Search instead for 
Did you mean: 

Systick time missing

SRedd.5
Senior III

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

SRedd5_0-1689998582490.png

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.

23 REPLIES 23

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

LCE
Principal

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

LCE
Principal

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?

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
Principal

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
Principal

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

Mainly for CAN message scheduling.

Karl Yamashita
Lead III

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);

If smoke escapes your device, put the smoke back in. It'll still work as a conversation piece. If you find my answers useful, click the Accept as Solution button so that way others can see the solution.
Johi
Senior III

, 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.

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