[BUG] SKR v1.3 (or any other LPC1768): problem with servo signals that cause issues with bltouch #16171

mlehnhoff · 2019-12-09T20:31:14Z

Bug Description

Recently i have upgraded my 3d printer to a Bigtreetech SKR v1.3. Unfortunatly i had some troubles with my bltouch clone (an older version of triaglelab 3d touch).
Every now and than on a G28 or G29, the bltouch does not trigger and the printhead continues to drive down into the bed.
At first i tried to find a solution in the inernet, but only found a forum article where someone said, that the SKR v1.3 has a bad 5V supply. Some additional Capacitors or an external 5V Supply should help. I tried both, but nothing helped! The 5V supply was not the problem!
I did some investigations myself and with the help of an Oscilloscope i found the actual issue:
It seems there is problem in the HAL of the LPC1768 (and maybe others) which can produce a wrong signal on the servo output. When the servo pulse should change from 1472µs (M280 P0 S90; stowed bltouch pin) to 647µs (M280 P0 S10;deployed pin) sometimes for one cycle the pulse is 20650µs long instead.
This long pulse seems to confuse the bltouch (clone) and even though the pin is deployed, under these circumstances the sensor will not trigger the endstop when it touches the bed.
I believe this happens every time, when the "M280 P0 S10" command is issued right in the small window where the servo pin is high for more than 647µs, but less than 1472µs. Than the falling edge for this cycle is already over and it is not executed until the next 20ms cylce (Just a guess, i have no evidence...).
But I found a quick and dirty solution that work's for me:

diff --git a/Marlin/src/HAL/HAL_LPC1768/Servo.h b/Marlin/src/HAL/HAL_LPC1768/Servo.h
index 1bbf84c73..97a7bcb54 100644
--- a/Marlin/src/HAL/HAL_LPC1768/Servo.h
+++ b/Marlin/src/HAL/HAL_LPC1768/Servo.h
@@ -58,6 +58,12 @@ class libServo: public Servo {
     static_assert(COUNT(servo_delay) == NUM_SERVOS, "SERVO_DELAY must be an array NUM_SERVOS long.");
 
     if (attach(servo_info[servoIndex].Pin.nbr) >= 0) {    // try to reattach
+      /* workaround for too long pulse on the servo pin */
+      if ( (servoIndex == 0) && ( extDigitalRead(SERVO0_PIN) == 1 ) ) {
+        safe_delay(3);
+      }
       write(value);
       safe_delay(servo_delay[servoIndex]); // delay to allow servo to reach position
       #if ENABLED(DEACTIVATE_SERVOS_AFTER_MOVE)

It simply checks the current status of the servo pin. If it is high, the change of the signal is delayed by 3ms. This ensures, that the pin is definitely low when the change is applyed, because the servo pulse can not be longer than 2.4ms.

But this is only a quick and dirty hack and it should be fixed in the HAL. And it should also be checked, if this issue can happen on other Controllers too.

My Configurations

Marlin_Configuration.zip

Steps to Reproduce

Use a SKR v1.3 board (or any other LPC1768) with a servo configured (#define NUM_SERVOS 1)
send M280 P0 S90
send M280 P0 S10
watch the servo signal (SKR v1.3: pin P2_00)

Expected behavior: [What you expect to happen]
A clean transition from signals with 1472µs pulse width to 647µs.

Actual behavior: [What actually happens]
Every now and than you will see a pulse width of more than 20ms on the first cycle after the command.

Additional Information

Maybe it is more likely to see, if you use "M280 P0 S180" and "M280 P0 S0" instead. (greater difference -> bigger window for the issue)

The text was updated successfully, but these errors were encountered:

Grogyan · 2019-12-10T00:54:22Z

Are you able to try a genuine BLTouch?

thisiskeithb · 2019-12-10T01:33:35Z

Are you able to try a genuine BLTouch?

Also, have you tried adjusting BLTouch settings in Configuration_adv.h?: You can adjust settings like BLTOUCH_DELAY, BLTOUCH_FORCE_SW_MODE, BLTOUCH_FORCE_MODE_SET, etc.

mlehnhoff · 2019-12-10T09:26:26Z

Oh, sorry, i forgot to mention. Of course i did try different combinations of BLTOUCH_DELAY, BLTOUCH_FORCE_SW_MODE and even DELAY_BEFORE_PROBING before. Without sucess.
Now, that i found out, what the problem is, it is clear, that longer delays does not help. Because the wrong 20ms pulse that brings the bltouch to this error state happens already a couple of seconds before the buildplate is touched.
BLTOUCH_FORCE_MODE_SET is not supported by this old version of bltouch clone. It is not a "smart" one.

And no, i don't have access to an genuine BLTouch. For me and my old clone the above mentioned hack works just fine, so personally i don't need a proper fix for this issu. But i think, that this issue should be fixed anyhow, because i think that even an actual servo could possibly react on this pulse with a short shake or any other weird behavior.

kockockockoc · 2019-12-10T21:32:32Z

Wow, @mlehnhoff, your patch ease my pain. SKR v1.3 + (not sure about an older version or not) triaglelab 3d touch - same troubles. My own 8/10 working condition: BLTOUCH_FORCE_SW_MODE + BLTOUCH_DELAY 1000. But your patch works 10/10 without SW_MODE and DELAY. Tnx!

boelle · 2019-12-11T02:01:16Z

i tested a servo based touch probe on a re-arm (same MCU) and i had no issues, but i used the deactivate after movement feature.

i have not tried without it, juse made logic sense to deactivate the servo when not needed

thisiskeithb · 2019-12-11T02:06:31Z

I have a handful of genuine BLTouches and they all work fine on an SKR 1.3 which is also LPC1768.

boelle · 2019-12-11T02:07:54Z

so jumping the gun here, is it most likely a hardware issue (wire, noise connection) or a user config issue?

thisiskeithb · 2019-12-11T02:09:50Z

Same reason for most of the extra BLTouch code/config options, it's a BLTouch clone issue.

Keep in mind that 3DTouch != BLTouch. There are a lot of closed issues related to these copies.

boelle · 2019-12-11T02:12:47Z

i would call it a hardware issue then,

yep i now 3dtouch (and others) are not a BLtouch

the big Q for me is whatever marlin supports the clones or if we only care about the genuine products?

boelle · 2019-12-11T02:24:01Z

giving a bit of thought personal i dont think its fair that marlin should support the clones

but i could be wrong, thoughts?

kockockockoc · 2019-12-11T06:11:16Z

My two cents, no matter what the name of XXtouch. Any of them connects to SERVOS pin (not BLtouch special pin). The SERVOS should work like a servos.

But i think, that this issue should be fixed anyhow, because i think that even an actual servo could possibly react on this pulse with a short shake or any other weird behavior.
(from @mlehnhoff comment)

sjasonsmith · 2019-12-11T07:57:07Z

This shouldn't be blamed on the probe hardware. The signal being produced from the board is incorrect, and was verified using an oscilloscope. That should be fixed.

I can also confirm that the reported behavior is very similar to genuine BLTouch hardware when I was debugging all those timer conflicts causing similar issues on SKR Mini E3 boards. Invalid pulse lengths seemed to cause the BLTouch to simply forget what it was doing and caused failures.

@mlehnhoff, did you capture any images from your oscilloscope that demonstrate the problem, that you could attach to this issue?

I don't think I like the current workaround as a complete solution, but I really appreciate the level of detail mlehnhoff provided describing the issue and the workaround demonstrating that pulse apparently is the root cause of the issue.

mlehnhoff · 2019-12-11T19:17:49Z

Sorry, that i did not provide scope screenshot immediately. I thougt i had had made some, but something went wrong. But i did not realize until i had given the scope back (it is not mine).
But now i have made a new one:

On the picture you see the transition from 1472µs to 544µ, but the first new

pulse is 20544µs.

Plus i tried an actual servo and here is the prove, that this problem is not only limited to 3dtouch or other clones.

IMG_4677.zip

The Servo should turn from 90° (lever in the middle) to 0° (lever down), but when the faulty pulse occurs, it actually turns up at first, before turning down.

By the way there are at least eight different versions of genuine bltouch (classic v1.0, v1.2, v1.3, smart v1.0, v2.0, v2.2, v3.0, v3.1) and no one knows, if all of them will work correctly ;-)

Here is another hint: When you send the M280 command manually it is very unlikely, that the issue occurs. I wrote a script to toggle the servo (used in the video) which increases the likeliness a lot:
servo_toggle.gcode.txt

ManuelMcLure · 2019-12-11T19:33:43Z

I wonder if this is related to an issue I'm seeing with my BLTouch.
I power my Re-ARM over USB and use M80 to turn on the 12V power supply. There is a 5V buck converter connected to the 12V power supply that powers the BLTouch, so the BLTouch doesn't get power until the 12V supply kicks in.
When the board powers up, the BLTouch flashes red - this is apparently somewhat normal if the BLTouch gets a signal before it powers up, so I'm not concerned about that.
However, any attempt to reset it with M280 P0 S160 has absolutely no effect. Neither does it retract the pin if it is deployed.
However, M280 P0 S60 successfully switches to SW mode and also stops the blinking.
Other than the blinking and S160 apparently being ignored, the BLTouch seems to work perfectly. Even when blinking it properly deploys, stows and probes - I've done full bed probes and have never seen a probe failure and repeatability is excellent.
This is a genuine V3.1 BLTouch - not a clone.

ManuelMcLure · 2019-12-11T19:35:31Z

I forgot to mention that I checked the pulses with both my cheap mini DSO and my big CRT oscilloscope and the pulse lengths seem fine. I've also tried different S values (from 155 to 165) without finding one that will trigger the reset.

AnHardt · 2019-12-12T00:46:35Z

I haven't looked up how the servo library for the LPC works - but:
A servo signal is a PWM. If this would be realized with a STM32 hardware timer this error would likely be caused by updating the counters compare register directly, instead of updating the new value to the preload register of the compare register. If changing the compare register from a high value to a low value while the counter is in between of the low and the high value, the (equal) compare is skipped, the pin is not changed until the counter overrun and than reaches the new value. If the preload register is used, the compare register is updated either when the counter overruns, or when the (old) compare value has a match. This has no risk of a loooong puls, only a possible delay of max about one PWM-periode (20ms).
EDIT: The chance for the error would be 5% per skipping 1ms backwards.
I suppose, here we have something similar.

p3p · 2019-12-12T06:51:41Z

This is because the lpc framework is not running the hardware pwm in latching mode, (where the pulsewidth register is shadowed and latched in on each period), it should be possible to do that with a simple mode bit .. but unfortunately I can not get it to work reliably, its a choice between a possible 1 period duration glitch, or the pulse width randomly (but quite frequently depending on how often it is updated) not changing at all.

Further research on the matter could be done, but it's really not a complicated peripheral, I wasted a long time on that glitch and in the end other things needed attention.

mlehnhoff · 2019-12-16T20:24:54Z

@mlehnhoff @kockockockoc How dp you apply the patch please?

To be honest, i am pretty new to git and i am just glad, that i could create this patch via "git diff". I am sure, there must be a different git command to apply this patch back. Maybe @kockockockoc can help out...
But for this very small code fragment, you can even do it by hand. It is just as easy as adding the four lines that begin wit a "+" to the file "Marlin/src/HAL/HAL_LPC1768/Servo.h" (of course without the "+") at the shown position...

javata70 · 2019-12-18T22:52:05Z

Hi, I have same board Bigtreetech SKR v1.3 and 3D Touch but the 3D Touch doens't work. I've tested the 3dTouch using some code in an Arduino Mega and does work perfect. So, I've tried any suggestion I found and also the @mlehnhoff patch but I'm still having the same problem = 3D Touch is freeze. When Marlin start the 3D Touch does a self-test and then the pin is stow and stays in this state forever without any change (throught M43 S or from the Marlin menu)
I'm really concern about that because I dont know what I have to do in order to solve this issue. Any suggestion is wellcome.

Reywas62 · 2019-12-19T22:15:37Z

I suspect that this bug is the same one I reported here: #15370

I am still running a bugfix commit from 6/22/19 with no issues. I tried the latest bugfix commit today and the servo issue is still present.

javata70 · 2019-12-20T01:06:19Z

@Reywas62 and all, I found this article http://fightpc.blogspot.com/2019/08/testing-skr-13-board-with-marlin-20x.html that could solve the problem. Aparently some SKR boards could have an output signal that has a low impedance (around 200 ohms) that would require a significant amount of current to work properly (and it not happens on Arduino boards, that is the reason why my 3D touch probe works propertly on the Arduino) So, apparently it is not related to firmware.

Reywas62 · 2019-12-20T03:49:03Z

Well I'd buy that explanation except that my board works fine with an earlier commit of Marlin bugfix 2.0.x (6/22/19).

dermigoe · 2019-12-20T08:37:28Z

I can confirm that the "quick an dirty" solution from mlehnhoff is working. I probing a 9x9 UBL-Mesh with a BLTouch Clone. Normally 1 or 2 points of the 81 point mesh are failing when i run the meshgeneration. But with the "fix" everything works fine. So i will continue to use this solution. And i my case i think it is a problem with the long servo pulse because my push-pin is deployed an the sensor doesn't trigger.

javata70 · 2019-12-21T16:35:32Z

I'd like to confirm that my problem with the 3D Touch has been solved. The problem is the low current of the SKR 1.3 Servo pins. I made the circuit and test it sucessfully. Now I've received this information after running M43:
SENDING:M43 S
Servo probe test
. using index: 0, deploy angle: 10, stow angle: 90
. Probe Z_MIN_PIN: 57
. Z_MIN_ENDSTOP_INVERTING: false
. Check for BLTOUCH
= BLTouch Classic 1.2, 1.3, Smart 1.0, 2.0, 2.2, 3.0, 3.1 detected.
** Please trigger probe within 30 sec **
. Pulse width (+/- 4ms): 10
= BLTouch pre V3.1 (or compatible) detected

DarkAlaranth · 2019-12-25T01:21:38Z

Going to experiment with my setup here, but I have both a SG90 and a MG90 servo motor that intermittently moves back on disable. As it's holding the Z-Probe switch this kinda kills the machine when it crashes into the bed. Last crash totaled the Creality CR10 S5's wheel mounts. >_<It actually bent the x-axis roller frame! O_O

When I get a chance I'll try the circuit and see if it sorts that out. but also going to try the firmware hack. :)

DarkAlaranth · 2019-12-25T02:07:54Z

After trying the firmware hack, there was no change for me (as I suspected, as the hack fixes bl-touch clones, not necessarily servo movement). The Servo would occasionally still move backwards further after completing a move.

Considering that, I undid the hack and told marlin NOT to disable the servo and it seems the move back issue has gone. Seems as though disabling the servo triggers my issue. Fortunately the MG90 I'm using doesn't show any vibration/shaking on the angles I have selected. :)

I would definitely like to thank mlehnhoff for their gcode to test with. Every time I ran it the servo would play up 3 or 4 times, and when I told marlin to keep the servo enabled, the script ran fine 3 times in a row. Considering reports of low current, I also ran the test with the heaters on to put the PSU under load. :)

Don't know if it matters, but my Servo angles are 172(deployed) and 35(Stowed) and it looked like it would move the servo backwards, by the same amount each time. The servo never moved forward.

Reywas62 · 2019-12-27T23:59:49Z

The firmware hack did not fix my issue but leaving the servo enabled stops the servo from misbehaving, as it did for DarkAlaranth. Not really a fix, but an acceptable workaround.

ebraiman · 2019-12-28T23:24:03Z

A little extra background I've tried this on several platforms over the past couple of days and thought I might have broken both of my AntLab BLtouch, so I ordered a third.

Here is what I've observed for the following platforms
SKR Pro V1.1 Fails to work
SKR v1.3 Fails to work
RAMPS 1.4 Fails to work
SKR v1.4 Fails to work
RAMPS 1.6 Fails to work

The symptom before probing read on a M119
Reporting endstop status
x_min: TRIGGERED
y_min: TRIGGERED
z_min: TRIGGERED

I've adjusted the pins file as well with same results.

Here is the process I used in several video of various marlin vintage
https://www.youtube.com/watch?v=5cSzFCv7K4Q&t=14s
https://www.youtube.com/watch?v=R0HeFV9nKCM
https://www.youtube.com/watch?v=HR-zn4dv1fY&t=2s
https://www.youtube.com/watch?v=-4o6-8TgpNM

I could post more videos, but my point is it's not working on any of them with 3 genuine BL touch(s).

Has something changed in the configuration? The configuration_adv.h now has a bunch of BL touch power settings.

Lyr3x · 2021-05-09T15:09:57Z

I switched from a v2.1 (which i damaged) to a v3.1 yesterday and facing the same issue. Both are genuine BLTouch.
Hadn't any problems with my old one but facing the now and then failed deploys now.

I've read about the issue and tried to reduce XY Probing Speed, as well as the stated workaround., played with delay and switching off servo while moving etc. Nothing worked for me. Tried GRID sizes from 3x3 to 10x10 and it randomly fails.

ManIkWeet · 2021-05-09T15:15:43Z

I switched to Klipper firmware and never had a leveling issue again, if you have a raspberry pi it's very much worth it

descipher · 2021-05-14T13:31:39Z

From HardwarePWM.h of framework-arduino-lpc176x
// Set the period using channel 0 before enabling peripheral
LPC_PWM1->MR0 = (CLKPWR_GetPCLK(CLKPWR_PCLKSEL_PWM1) / frequency) - 1;
LPC_PWM1->LER = util::bit_value(0); // if only latching worked

// Enable PWM mode
// TODO: this **is very unreliable appears to randomly miss latches** thus not changing the duty cycle
// disabling PWM latch mode at least gives reliable (bit 3)
//LPC_PWM1->TCR = util::bitset_value(0, 3);      //  Turn on PWM latch mode and Enable counters
LPC_PWM1->TCR = util::bitset_value(0);

// update the match register for a channel and set the latch to update on next period
static inline void set_match(const pin_t pin, const uint32_t value) {
//work around for bug if MR1 == MR0
*match_register_ptr(pin) = value == LPC_PWM1->MR0 ? value + 1 : value;
// tried to work around latch issue by always setting all bits, was unsuccessful
LPC_PWM1->LER = util::bit_value(pin_has_pwm(pin));

// At 0 duty cycle hardware pwm outputs 1 cycle pulses
// Work around it by disabling the pwm output and setting the pin low util the duty cycle is updated
if(value == 0) {
  set_idle(pin);
} else if(util::bit_test(idle_pins, get_pin_id(pin))) {
  pin_enable_function(pin, pwm_function_index(pin));
  util::bit_clear(idle_pins, get_pin_id(pin));
}

}

Obviously this is the reason we have intermittent issues with BLTouch, clones or any servo on the NXP MCU's using Arduino lib.
This needs to be worked on, I would but I do not have a board to test it on.
From the LPC176x user manual.

PWM mode causes the shadow
registers to operate in connection with the Match registers. A program write to a
Match register will not have an effect on the Match result until the corresponding bit
in PWMLER has been set, followed by the occurrence of a PWM Match 0 event.
Note that the PWM Match register that determines the PWM rate (PWM Match
Register 0 - MR0) must be set up prior to the PWM being enabled. Otherwise a
Match event will not occur to cause shadow register contents to become effective.

descipher · 2021-05-14T13:41:15Z

Each time the detach call is made the PWM is disabled. e.g. TERN_(DEACTIVATE_SERVOS_AFTER_MOVE, detach());
if(!channel_active(pin)) util::bit_clear(LPC_PWM1->PCR, 8 + pin_has_pwm(pin)); // turn off the PWM output

The issue can occur when attach is called as set_match does not reload reload LER for MR1 which is the duty match reg.

Lyr3x · 2021-05-14T13:59:30Z

Thats too low level for me, however I am more than happy to test any changes with my skr pro 1.1 👍

MangaValk · 2021-05-14T14:08:09Z

i have got an GTR here and just got myself a modern scope. if you give some instruction i can test some things.

descipher · 2021-05-14T15:55:25Z

i have got an GTR here and just got myself a modern scope. if you give some instruction i can test some things.

Thanks, Will consider that option, really hoping we see some manufacturing support for it e.g. they should send a board to work on it. Remote hands and eyes are much more time intensive.

descipher · 2021-05-14T16:02:29Z

From a code change perspective it would require using MR0 as the period and MR1 as the duty. Then it should all work with latching.

AnHardt · 2021-05-14T17:45:51Z

Nether the SKR Pro V1.1 nor the GTR have a LPC-processor. They do not use the library under discussion here! =8O

ManuelMcLure · 2021-05-14T17:59:01Z

Also, p3p indicates above that he attempted to use the latching mode and it resulted in more problems than it solved...

descipher · 2021-05-14T18:11:08Z

Also, p3p indicates above that he attempted to use the latching mode and it resulted in more problems than it solved...

Yes, the question is why was it inconsistent, I cannot see what was tried but there are elements I see that would be an issue. For example, when a reattach is done we need to reset the count to ensure the common period latch is updated and that is MR0. With multi channel there needs to be a process to update each channel MR. I don’t see one in that code.

AnHardt · 2021-05-14T18:14:36Z

When using a BL-touch 'DEACTIVATE_SERVOS_AFTER_MOVE' is unwise and switched OFF by default. Please look up the BL-touch manual.

AnHardt · 2021-05-14T18:18:01Z

'DEACTIVATE_SERVOS_AFTER_MOVE' was made to avoid servo jitter when using the AVRs software timers. For hardware times it makes absolutely NEVER any sense.

EDIT: Sorry hardware PWM

descipher · 2021-05-14T18:19:51Z

When using a BL-touch 'DEACTIVATE_SERVOS_AFTER_MOVE' is unwise and switched OFF by default. Please look up the BL-touch manual.

Do you know if this issue occurs on a BL-touch without DEACTIVATE_SERVOS_AFTER_MOVE.

descipher · 2021-05-14T18:26:03Z

Read the manual, there is no mention of DEACTIVATE_SERVOS_AFTER_MOVE.

AnHardt · 2021-05-14T18:29:38Z

https://5020dafe-17d8-4c4c-bf3b-914a8fdd5140.filesusr.com/ugd/f5a1c8_a8cd142ffd2f42089c78883f2bb172b7.pdf
Last page, last line in the box.

Later Marlin had a BLTOUCH option, automatically setting this. So they did not go into that much detail in later manuals.

descipher · 2021-05-14T18:38:59Z

Ok, thanks, that on v1.0 with Marlin 1.1.x(1.1.9), nothing in the current mentions it (v3.1), also what if you have a mega2560?
https://5020dafe-17d8-4c4c-bf3b-914a8fdd5140.filesusr.com/ugd/f5a1c8_d40d077cf5c24918bd25b6524f649f11.pdf
Do you know if this is an issue without it? That would be very useful to know.

AnHardt · 2021-05-14T18:54:42Z

See edited comment above.
Since, at that time, there was no alternative to the AVRs i expect Antclabs have tested this on AVRs only and required it by purpose.

A real check for this would only be to look up, the reaction when the signal is missing, in the BL-touch firmware - what is closed source - what is my main problem with that shit. (And the problem to make 'real' clones)

descipher · 2021-05-14T19:03:42Z

Also, p3p indicates above that he attempted to use the latching mode and it resulted in more problems than it solved

There is no other option when in PWM mode and it is using latching in the current code but only for MR0.

https://www.nxp.com/docs/en/user-guide/UM10360.pdf page 527
PWM Enable
PWM mode is enabled (counter resets to 1). PWM mode causes the shadow
registers to operate in connection with the Match registers. A program write to a
Match register will not have an effect on the Match result until the corresponding bit
in PWMLER has been set, followed by the occurrence of a PWM Match 0 event.
Note that the PWM Match register that determines the PWM rate (PWM Match
Register 0 - MR0) must be set up prior to the PWM being enabled. Otherwise a
Match event will not occur to cause shadow register contents to become effective

descipher · 2021-05-14T19:29:15Z

If you want to try adding LER for MR1 give this a go:

// update the match register for a channel and set the latch to update on next period
static inline void set_match(const pin_t pin, const uint32_t value) {
//work around for bug if MR1 == MR0
*match_register_ptr(pin) = value == LPC_PWM1->MR0 ? value + 1 : value;
LPC_PWM1->LER = util::bitset_value(0, 1); // Enable Latch for MR0 and MR1
// At 0 duty cycle hardware pwm outputs 1 cycle pulses
// Work around it by disabling the pwm output and setting the pin low util the duty cycle is updated
if(value == 0) {
set_idle(pin);
} else if(util::bit_test(idle_pins, get_pin_id(pin))) {
pin_enable_function(pin, pwm_function_index(pin));
util::bit_clear(idle_pins, get_pin_id(pin));
}
}

descipher · 2021-06-09T22:31:28Z

FYI
p3p/pio-framework-arduino-lpc176x#46 is merged

mlehnhoff · 2021-06-11T14:21:46Z

I have just tested the new Release 0.2.7 of pio-framework-arduino-lpc176x
It seems to work fine. Many thanks to @p3p and @descipher.

So as soon as this package is integrated to Marlin this issue should be solved.

descipher · 2021-07-10T13:51:16Z

platform_packages = framework-arduino-lpc176x@^0.2.6
lpc176x.ini needs updating ... current release is 0.2.8, fixes multiple issues with pwm and baud accuracy. Will do a PR.

thisiskeithb · 2021-07-12T02:18:23Z

Fixed in #22333

github-actions · 2021-09-10T14:02:05Z

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

boelle added the Bug: Confirmed ! label Dec 11, 2019

This comment was marked as off-topic.

Sign in to view

ellensp removed the stale-closing-soon label Feb 21, 2021

This was referenced Jul 10, 2021

Fix.lpc176x #22332

Closed

Update LPC176x platform to 0.2.8 #22333

Merged

thisiskeithb closed this as completed Jul 12, 2021

github-actions bot locked and limited conversation to collaborators Sep 10, 2021

[BUG] SKR v1.3 (or any other LPC1768): problem with servo signals that cause issues with bltouch #16171

[BUG] SKR v1.3 (or any other LPC1768): problem with servo signals that cause issues with bltouch #16171

Comments

mlehnhoff commented Dec 9, 2019

Bug Description

My Configurations

Steps to Reproduce

Additional Information

Grogyan commented Dec 10, 2019

thisiskeithb commented Dec 10, 2019

mlehnhoff commented Dec 10, 2019

kockockockoc commented Dec 10, 2019 • edited

boelle commented Dec 11, 2019

thisiskeithb commented Dec 11, 2019

boelle commented Dec 11, 2019

thisiskeithb commented Dec 11, 2019 • edited

boelle commented Dec 11, 2019

boelle commented Dec 11, 2019

kockockockoc commented Dec 11, 2019

sjasonsmith commented Dec 11, 2019

mlehnhoff commented Dec 11, 2019

ManuelMcLure commented Dec 11, 2019 • edited

ManuelMcLure commented Dec 11, 2019

AnHardt commented Dec 12, 2019 • edited

p3p commented Dec 12, 2019

This comment was marked as off-topic.

mlehnhoff commented Dec 16, 2019

javata70 commented Dec 18, 2019

Reywas62 commented Dec 19, 2019 • edited

javata70 commented Dec 20, 2019

Reywas62 commented Dec 20, 2019 • edited

dermigoe commented Dec 20, 2019

javata70 commented Dec 21, 2019

DarkAlaranth commented Dec 25, 2019 • edited

DarkAlaranth commented Dec 25, 2019

Reywas62 commented Dec 27, 2019

ebraiman commented Dec 28, 2019

Lyr3x commented May 9, 2021 • edited

ManIkWeet commented May 9, 2021

descipher commented May 14, 2021

descipher commented May 14, 2021

Lyr3x commented May 14, 2021

MangaValk commented May 14, 2021

descipher commented May 14, 2021

descipher commented May 14, 2021

AnHardt commented May 14, 2021 • edited

ManuelMcLure commented May 14, 2021

descipher commented May 14, 2021

AnHardt commented May 14, 2021

AnHardt commented May 14, 2021 • edited

descipher commented May 14, 2021

descipher commented May 14, 2021

AnHardt commented May 14, 2021 • edited

descipher commented May 14, 2021

AnHardt commented May 14, 2021

descipher commented May 14, 2021 • edited

descipher commented May 14, 2021

descipher commented Jun 9, 2021

mlehnhoff commented Jun 11, 2021 • edited

descipher commented Jul 10, 2021

thisiskeithb commented Jul 12, 2021

github-actions bot commented Sep 10, 2021

kockockockoc commented Dec 10, 2019 •

edited

thisiskeithb commented Dec 11, 2019 •

edited

ManuelMcLure commented Dec 11, 2019 •

edited

AnHardt commented Dec 12, 2019 •

edited

Reywas62 commented Dec 19, 2019 •

edited

Reywas62 commented Dec 20, 2019 •

edited

DarkAlaranth commented Dec 25, 2019 •

edited

Lyr3x commented May 9, 2021 •

edited

AnHardt commented May 14, 2021 •

edited

AnHardt commented May 14, 2021 •

edited

AnHardt commented May 14, 2021 •

edited

descipher commented May 14, 2021 •

edited

mlehnhoff commented Jun 11, 2021 •

edited