Some step pulses have much longer duration than configured in $0 (STM32F103-based board) about stm32f1xx HOT 8 CLOSED

USB or UART connection?
Was the last test run from a sender requesting real-time reports or from a simple terminal program like PuTTY?
In not from a simple terminal program can you rerun the test from one? Issue still visible? If not it is likely interrupt priority for either UART or USB comms has to be lowered.

from stm32f1xx.

I'm using G code sender with USB connection.

I either think that the root cause is in misconfig in interrupt priorities.. Looks like TIM3 interrupt delayed from time to time.

Ok, I will try putty

from stm32f1xx.

It looks much better when connecting with serial terminal.
Below is the waveform after running G0Z500 command. I still have longer pulses but the difference is much less than previously.

from stm32f1xx.

Try reducing the priority for the serial and USB interrupts:

Increasing the second parameter decreases priority, e.g:

HAL_NVIC_SetPriority(xxx_IRQn, 1, 0);

will let the step pulse off interrupt preempt these.

Priority for the systick timer should be reduced as well? IIRC I have done that for a few drivers.

I have fried my only F103 board so I cannot check myself...

from stm32f1xx.

Thanks Terje. I will test it and then update you.

from stm32f1xx.

Hi Terje.
So I lowered USB interrupt priority (USART1 and USART3 are turned off for me) and it's much better now.

diff --git a/USB_DEVICE/Target/usbd_conf.c b/USB_DEVICE/Target/usbd_conf.c
index f9587a6..1488723 100644
--- a/USB_DEVICE/Target/usbd_conf.c
+++ b/USB_DEVICE/Target/usbd_conf.c
@@ -78,7 +78,7 @@ void HAL_PCD_MspInit(PCD_HandleTypeDef* pcdHandle)
     __HAL_RCC_USB_CLK_ENABLE();
 
     /* Peripheral interrupt init */
-    HAL_NVIC_SetPriority(USB_LP_CAN1_RX0_IRQn, 0, 0);
+    HAL_NVIC_SetPriority(USB_LP_CAN1_RX0_IRQn, 1, 0);
     HAL_NVIC_EnableIRQ(USB_LP_CAN1_RX0_IRQn);
   /* USER CODE BEGIN USB_MspInit 1 */

But sometimes when I run the G code program attached previously, I see ~16us pulses (instead of 10us).

from stm32f1xx.

Try reducing priority to 2, It should not matter but who knows...
I do not know how long it takes to preempt an USB interrupt, and neither if the USB driver code disables interrupts for critical sections of code. If minimal jitter is a must using a USB <> UART breakout is IMO likely a better choice. Or switch to a faster processor, the F1xx series is pretty slow and does not have a FPU.

from stm32f1xx.

By the way I tried the previous grblHAL version before you moved to a new home:
https://github.com/terjeio/grblHAL/tree/master/drivers/STM32F1xx

and all the step pulses are good there (with USB interrupt priority 1).
So probably there's some "heavy" code on a new version.

Anyway thanks for your help Terje. The issue fixed.

from stm32f1xx.