Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] SysTick_Callback interferes with timing critical code - causes speed jitter - LPC176x #27115

Open
1 task
mh-dm opened this issue May 21, 2024 · 1 comment · May be fixed by #27131
Open
1 task

[BUG] SysTick_Callback interferes with timing critical code - causes speed jitter - LPC176x #27115

mh-dm opened this issue May 21, 2024 · 1 comment · May be fixed by #27131

Comments

@mh-dm
Copy link
Contributor

mh-dm commented May 21, 2024

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

SysTick_Callback() should not be used as doing so causes timing jitter for all interrupts. SysTick_Callback() is an api from the pio-framework-arduino-lpc176x.

Here's the relevant section from pio-framework-arduino-lpc176x/cores/arduino/main.cpp:

 __attribute__ ((weak)) void SysTick_Callback() {}
// [..]
volatile uint64_t _millis;
// [..]
    NVIC_SetPriority(SysTick_IRQn, NVIC_EncodePriority(0, 0, 0));
// [..]
  void SysTick_Handler(void) {
    ++_millis;
    SysTick_Callback();
  }

0 is the highest priority level which means SysTick_Handler is going to run regardless of anyone. This would be absolutely fine if it was just incrementing _millis. But it's not.

SysTick_Callback() running as part of SysTick_IRQn and at the highest possible priority puts it ahead of every other interrupt: stepper isr, uart, serial, pwm, watchdog, you name it. And it runs every millisecond.

The main problematic SysTick_Callback() is from Marlin/src/HAL/LPC1768/HAL.cpp:

void SysTick_Callback() { disk_timerproc(); }

Where disk_timerproc() is actually from framework-arduino-lpc176x/system/CMSIS/lib/chanfs/mmc_ssp.c.

Issue

A logic analyzer capture of step/dir pins best shows the issue:
jitter
(Note in this capture the stepper isr was at the priority 0)

You can see speed jitter equivalent to 6000mm/s^2 or more throughout, even at a somewhat leisurely 100mm/s movement speed. In my testing, I've disabled all features I could think of incl. lcd and watchdog and increased the stepper isr priority to highest (0), but still jitter.

Root cause

To confirm that it's SysTick_Callback() I've commented it out completely, including definition and use. This is the result:
jitter_no
(Note in this capture the stepper isr was at the priority 0)

The slightly strange part is that without the disk_timerproc(); call, reading from/writing to SD card still seems to work. So It's definitely not crucial. Is it even needed? Every ms? / When is it needed?

One more

Marlin/src/lcd/extui/mks_ui/tft_lvgl_configuration.cpp (unused in my build) also defines a SysTick_Callback().

pio-framework-arduino-lpc176x

I've also opened pio-framework-arduino-lpc176x/issues/49.

Impact

It makes ADAPTIVE_STEP_SMOOTHING seem lees effective. ADAPTIVE_STEP_SMOOTHING reduces a larger source of speed jitter, namely bresenham aliasing for the minor axes.
It may interfere with communication like serial and spi, depending on timing sensitivity or implementation.

Bug Timeline

Old issue, maybe 2019. Git blame points to SysTick_Callback added in 60cb36b "(grafted)"

Expected behavior

No significant isr jitter.

Actual behavior

Interrupt jitter.

Steps to Reproduce

Run this simple/X-axis only gcode and look at the step/dir pins with a logic analyzer (at >=12Mhz sample rate).

M92 X80 Y80 ; 80 steps per mm
G92 X0 Y0
G4 P550 ; configurable delay
M205 X10 Y10
M204 S5000
G0 F7500 X60
G0 F5400 X120
G0 F5700 X180
G0 F6000 X240
G0 F6000 X0

Version of Marlin Firmware

Last sync: 06762db [cron] Bump distribution date (2024-05-18)

Printer model

Customized Ender-3

Electronics

SKR v1.4 Turbo but all LPC176x are affected

LCD/Controller

No response

Other add-ons

No response

Bed Leveling

None

Your Slicer

None

Host Software

SD Card (headless)

Don't forget to include

  • A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

(In lieu of configuration zip file I've root caused to specific lines of code.)

@InsanityAutomation
Copy link
Contributor

I believe @p3p was on vacation so we likely wont hear something until next week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants