From 508c28e6893bd53178d6bba8b8f9733b177e8c99 Mon Sep 17 00:00:00 2001 From: JamesH1978 <87171443+JamesH1978@users.noreply.github.com> Date: Sat, 15 Feb 2025 18:04:57 +0000 Subject: [PATCH 1/7] spi_flash: Update board_defs.py - BTT Octopus Max EZ (#6817) Addition to the board_defs file for the BTT Octopus Max EZ, written and confirmed by discord user Nikki @winningfaith81 Signed-off-by: James Hartley --- scripts/spi_flash/board_defs.py | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/scripts/spi_flash/board_defs.py b/scripts/spi_flash/board_defs.py index 9924fefcd..bc0c3d577 100644 --- a/scripts/spi_flash/board_defs.py +++ b/scripts/spi_flash/board_defs.py @@ -130,6 +130,13 @@ BOARD_DEFS = { "cs_pin": "PA4", "current_firmware_path": "OLD.BIN" }, + 'btt-octopus-max-ez': { + 'mcu': "stm32h723xx", + 'spi_bus': "swspi", + 'spi_pins': "PE13,PE14,PE12", + 'cs_pin': "PB12", + 'skip_verify': True + }, 'btt-skrat': { 'mcu': "stm32g0b1xx", 'spi_bus': "spi1", From e24ea3652cace049f84759b6aac9397703f2b347 Mon Sep 17 00:00:00 2001 From: Nicholas Parry Date: Sun, 16 Feb 2025 07:06:29 +1300 Subject: [PATCH 2/7] docs: Fixed incorrect spelling in Config_Reference.md (#6819) changed spelling of single word Signed-off-by: Nicholas Parry --- docs/Config_Reference.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/Config_Reference.md b/docs/Config_Reference.md index 0035955f5..7a1f3b813 100644 --- a/docs/Config_Reference.md +++ b/docs/Config_Reference.md @@ -5061,7 +5061,7 @@ Octoprint as they will conflict, and 1 will fail to initialize properly likely aborting your print. If you use Octoprint and stream gcode over the serial port instead of -printing from virtual_sd, then remo **M1** and **M0** from *Pausing commands* +printing from virtual_sd, then remove **M1** and **M0** from *Pausing commands* in *Settings > Serial Connection > Firmware & protocol* will prevent the need to start print on the Palette 2 and unpausing in Octoprint for your print to begin. From a90110d9bab2ae1bf878fd0974fa3d8f128a38f8 Mon Sep 17 00:00:00 2001 From: Kevin O'Connor Date: Sat, 15 Feb 2025 13:54:13 -0500 Subject: [PATCH 3/7] docs: Note stealthchop_threshold doesn't impact sensorless homing Reported by @paulfertser. Signed-off-by: Kevin O'Connor --- docs/Config_Reference.md | 20 ++++++++++++-------- docs/TMC_Drivers.md | 4 ++++ 2 files changed, 16 insertions(+), 8 deletions(-) diff --git a/docs/Config_Reference.md b/docs/Config_Reference.md index 7a1f3b813..1489670e4 100644 --- a/docs/Config_Reference.md +++ b/docs/Config_Reference.md @@ -3456,8 +3456,9 @@ run_current: #stealthchop_threshold: 0 # The velocity (in mm/s) to set the "stealthChop" threshold to. When # set, "stealthChop" mode will be enabled if the stepper motor -# velocity is below this value. The default is 0, which disables -# "stealthChop" mode. +# velocity is below this value. Note that the "sensorless homing" +# code may temporarily override this setting during homing +# operations. The default is 0, which disables "stealthChop" mode. #coolstep_threshold: # The velocity (in mm/s) to set the TMC driver internal "CoolStep" # threshold to. If set, the coolstep feature will be enabled when @@ -3569,8 +3570,9 @@ run_current: #stealthchop_threshold: 0 # The velocity (in mm/s) to set the "stealthChop" threshold to. When # set, "stealthChop" mode will be enabled if the stepper motor -# velocity is below this value. The default is 0, which disables -# "stealthChop" mode. +# velocity is below this value. Note that the "sensorless homing" +# code may temporarily override this setting during homing +# operations. The default is 0, which disables "stealthChop" mode. #driver_MULTISTEP_FILT: True #driver_IHOLDDELAY: 8 #driver_TPOWERDOWN: 20 @@ -3772,8 +3774,9 @@ run_current: #stealthchop_threshold: 0 # The velocity (in mm/s) to set the "stealthChop" threshold to. When # set, "stealthChop" mode will be enabled if the stepper motor -# velocity is below this value. The default is 0, which disables -# "stealthChop" mode. +# velocity is below this value. Note that the "sensorless homing" +# code may temporarily override this setting during homing +# operations. The default is 0, which disables "stealthChop" mode. #coolstep_threshold: # The velocity (in mm/s) to set the TMC driver internal "CoolStep" # threshold to. If set, the coolstep feature will be enabled when @@ -3906,8 +3909,9 @@ run_current: #stealthchop_threshold: 0 # The velocity (in mm/s) to set the "stealthChop" threshold to. When # set, "stealthChop" mode will be enabled if the stepper motor -# velocity is below this value. The default is 0, which disables -# "stealthChop" mode. +# velocity is below this value. Note that the "sensorless homing" +# code may temporarily override this setting during homing +# operations. The default is 0, which disables "stealthChop" mode. #coolstep_threshold: # The velocity (in mm/s) to set the TMC driver internal "CoolStep" # threshold to. If set, the coolstep feature will be enabled when diff --git a/docs/TMC_Drivers.md b/docs/TMC_Drivers.md index d2a7eaa33..6326e339d 100644 --- a/docs/TMC_Drivers.md +++ b/docs/TMC_Drivers.md @@ -83,6 +83,10 @@ setting `stealthchop_threshold` to 999999). Unfortunately, the drivers often produce poor and confusing results if the mode changes while the motor is at a non-zero velocity. +Note that the `stealthchop_threshold` config option does not impact +sensorless homing as Klipper automatically switches the TMC driver to +an appropriate mode during sensorless homing operations. + ## TMC interpolate setting introduces small position deviation The TMC driver `interpolate` setting may reduce the audible noise of From 15339aec6468e9241262cc84d556eee6f77ec496 Mon Sep 17 00:00:00 2001 From: Kevin O'Connor Date: Wed, 5 Feb 2025 12:18:43 -0500 Subject: [PATCH 4/7] docs: Improve suggestions on bytes_invalid in CANBUS_Troubleshooting.md Signed-off-by: Kevin O'Connor --- docs/CANBUS_Troubleshooting.md | 38 ++++++++++++++++++++++++---------- 1 file changed, 27 insertions(+), 11 deletions(-) diff --git a/docs/CANBUS_Troubleshooting.md b/docs/CANBUS_Troubleshooting.md index de0deaf74..6b7973bae 100644 --- a/docs/CANBUS_Troubleshooting.md +++ b/docs/CANBUS_Troubleshooting.md @@ -37,20 +37,36 @@ hours or more frequently) then it is an indication of a severe problem. Incrementing `bytes_invalid` on a CAN bus connection is a symptom of -reordered messages on the CAN bus. There are two known causes of -reordered messages: -1. Old versions of the popular candlight_firmware for USB CAN adapters - had a bug that could cause reordered messages. If using a USB CAN - adapter running this firmware then make sure to update to the - latest firmware if incrementing `bytes_invalid` is observed. -2. Some Linux kernel builds for embedded devices have been known to - reorder CAN bus messages. It may be necessary to use an alternative - Linux kernel or to use alternative hardware that supports - mainstream Linux kernels that do not exhibit this problem. +reordered messages on the CAN bus. If seen, make sure to: +* Use a Linux kernel version 6.6.0 or later. +* If using a USB-to-CANBUS adapter running candlelight firmware, use + v2.0 or later of candleLight_fw. +* If using Klipper's USB-to-CANBUS bridge mode, make sure the bridge + node is flashed with Klipper v0.12.0 or later. Reordered messages is a severe problem that must be fixed. It will result in unstable behavior and can lead to confusing errors at any -part of a print. +part of a print. An incrementing `bytes_invalid` is not caused by +wiring or similar hardware issues and can only be fixed by identifying +and updating the faulty software. + +Older versions of the Linux kernel had a bug in the gs_usb canbus +driver code that could cause reordered canbus packets. The issue is +thought to be fixed in +[Linux commit 24bc41b4](https://github.com/torvalds/linux/commit/24bc41b4558347672a3db61009c339b1f5692169) +which was released in v6.6.0. In some cases, older Linux versions may +not show the problem (due to how hardware interrupts are configured), +however if problems are seen the recommended solution is to upgrade to +a newer kernel. + +Older versions of candlelight firmware could reorder canbus packets, +and the issue is thought to be fixed in +[candlelight_fw commit 8b3a7b45](https://github.com/candle-usb/candleLight_fw/commit/8b3a7b4565a3c9521b762b154c94c72c5acb2bcf). + +Older versions of Klipper's USB-to-CANBUS bridge code could +incorrectly drop canbus messages. This is not as severe as reordering +messages, but it should still be fixed. It is thought to be fixed with +[Klipper PR #6175](https://github.com/Klipper3d/klipper/pull/6175). ## Use an appropriate txqueuelen setting From ec56167032253b19bed362b25d3696f5d810633b Mon Sep 17 00:00:00 2001 From: Kevin O'Connor Date: Wed, 5 Feb 2025 19:00:28 -0500 Subject: [PATCH 5/7] usb_cdc_ep: Define endpoint sizes in usb_cdc_ep.h Move the definition of the usb endpoint sizes from usb_cdc.h to usb_cdc_ep.h . This allows individual boards to override the default endpoint sizes. Signed-off-by: Kevin O'Connor --- src/generic/usb_cdc.h | 8 -------- src/generic/usb_cdc_ep.h | 8 ++++++++ src/lpc176x/usb_cdc_ep.h | 7 +++++++ 3 files changed, 15 insertions(+), 8 deletions(-) diff --git a/src/generic/usb_cdc.h b/src/generic/usb_cdc.h index 3c92ef13f..2149c2782 100644 --- a/src/generic/usb_cdc.h +++ b/src/generic/usb_cdc.h @@ -3,14 +3,6 @@ #include // uint_fast8_t -// endpoint sizes -enum { - USB_CDC_EP0_SIZE = 16, - USB_CDC_EP_ACM_SIZE = 8, - USB_CDC_EP_BULK_OUT_SIZE = 64, - USB_CDC_EP_BULK_IN_SIZE = 64, -}; - // callbacks provided by board specific code int_fast8_t usb_read_bulk_out(void *data, uint_fast8_t max_len); int_fast8_t usb_send_bulk_in(void *data, uint_fast8_t len); diff --git a/src/generic/usb_cdc_ep.h b/src/generic/usb_cdc_ep.h index f75215802..3b0e6beb1 100644 --- a/src/generic/usb_cdc_ep.h +++ b/src/generic/usb_cdc_ep.h @@ -8,4 +8,12 @@ enum { USB_CDC_EP_ACM = 3, }; +// Default endpoint sizes +enum { + USB_CDC_EP0_SIZE = 16, + USB_CDC_EP_ACM_SIZE = 8, + USB_CDC_EP_BULK_OUT_SIZE = 64, + USB_CDC_EP_BULK_IN_SIZE = 64, +}; + #endif // usb_cdc_ep.h diff --git a/src/lpc176x/usb_cdc_ep.h b/src/lpc176x/usb_cdc_ep.h index d657f3c27..ef9649ed7 100644 --- a/src/lpc176x/usb_cdc_ep.h +++ b/src/lpc176x/usb_cdc_ep.h @@ -7,4 +7,11 @@ enum { USB_CDC_EP_BULK_IN = 5, }; +enum { + USB_CDC_EP0_SIZE = 16, + USB_CDC_EP_ACM_SIZE = 8, + USB_CDC_EP_BULK_OUT_SIZE = 64, + USB_CDC_EP_BULK_IN_SIZE = 64, +}; + #endif // usb_cdc_ep.h From bf5c4daf869c0c3c44d4dd786e71e8813fe28b12 Mon Sep 17 00:00:00 2001 From: Kevin O'Connor Date: Thu, 6 Feb 2025 01:32:05 -0500 Subject: [PATCH 6/7] usb_cdc: Avoid ending a transmission with a max size usb packet It seems the Linux kernel will consider a maximum size usb packet to be a transaction that will continue into the next usb packet. It will thus hold on to the traffic from the first packet until it gets the next packet. However, if the mcu has no further data to send after the first packet then the data could get delayed for an extended period of time. To avoid this, check for transmissions that could end on a maximum sized packet and send that data in two packets instead. This avoids this unusual corner case. Signed-off-by: Kevin O'Connor --- src/generic/usb_cdc.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/generic/usb_cdc.c b/src/generic/usb_cdc.c index 143c213f0..961c6330c 100644 --- a/src/generic/usb_cdc.c +++ b/src/generic/usb_cdc.c @@ -44,11 +44,13 @@ usb_bulk_in_task(void) { if (!sched_check_wake(&usb_bulk_in_wake)) return; - uint_fast8_t tpos = transmit_pos; + uint_fast8_t tpos = transmit_pos, max_tpos = tpos; if (!tpos) return; - uint_fast8_t max_tpos = (tpos > USB_CDC_EP_BULK_IN_SIZE - ? USB_CDC_EP_BULK_IN_SIZE : tpos); + if (max_tpos > USB_CDC_EP_BULK_IN_SIZE) + max_tpos = USB_CDC_EP_BULK_IN_SIZE; + else if (max_tpos == USB_CDC_EP_BULK_IN_SIZE) + max_tpos = USB_CDC_EP_BULK_IN_SIZE-1; // Avoid zero-length-packets int_fast8_t ret = usb_send_bulk_in(transmit_buf, max_tpos); if (ret <= 0) return; From 1fc6d214f4fab8b9e6a051fbe42f27ef4add77ef Mon Sep 17 00:00:00 2001 From: Kevin O'Connor Date: Tue, 28 Jan 2025 18:37:29 -0500 Subject: [PATCH 7/7] stm32: Add support for stm32f070x6 mcus This mcu has smaller memory and may require remapping of PA11/PA12. Signed-off-by: Kevin O'Connor --- src/stm32/Kconfig | 18 ++++++++++++------ src/stm32/stm32f0.c | 4 +--- 2 files changed, 13 insertions(+), 9 deletions(-) diff --git a/src/stm32/Kconfig b/src/stm32/Kconfig index 4112e8334..6e1daa543 100644 --- a/src/stm32/Kconfig +++ b/src/stm32/Kconfig @@ -15,7 +15,7 @@ config STM32_SELECT select HAVE_CHIPID select HAVE_STEPPER_BOTH_EDGE select HAVE_BOOTLOADER_REQUEST - select HAVE_LIMITED_CODE_SIZE if MACH_STM32F031 || MACH_STM32F042 + select HAVE_LIMITED_CODE_SIZE if FLASH_SIZE < 0x10000 config BOARD_DIRECTORY string @@ -117,6 +117,10 @@ config MACH_STM32F103x6 depends on LOW_LEVEL_OPTIONS && MACH_STM32F103 bool "Only 10KiB of RAM (for rare stm32f103x6 variant)" +config MACH_STM32F070x6 + depends on LOW_LEVEL_OPTIONS && MACH_STM32F070 + bool "Only 6KiB of RAM (for rare stm32f070x6 variant)" + config MACH_STM32F0 bool config MACH_STM32F1 @@ -211,8 +215,8 @@ config CLOCK_FREQ config FLASH_SIZE hex - default 0x8000 if MACH_STM32F031 || MACH_STM32F042 - default 0x20000 if MACH_STM32F070 || MACH_STM32F072 + default 0x8000 if MACH_STM32F031 || MACH_STM32F042 || MACH_STM32F070x6 + default 0x20000 if (MACH_STM32F070 || MACH_STM32F072) && !MACH_STM32F070x6 default 0x10000 if MACH_STM32F103 || MACH_STM32L412 # Flash size of stm32f103x8 (64KiB) default 0x40000 if MACH_STM32F2 || MACH_STM32F401 || MACH_STM32H723 default 0x80000 if MACH_STM32F4x5 || MACH_STM32F446 @@ -234,7 +238,8 @@ config RAM_SIZE hex default 0x1000 if MACH_STM32F031 default 0x1800 if MACH_STM32F042 - default 0x4000 if MACH_STM32F070 || MACH_STM32F072 + default 0x1800 if MACH_STM32F070x6 + default 0x4000 if (MACH_STM32F070 || MACH_STM32F072) && !MACH_STM32F070x6 default 0x2800 if MACH_STM32F103x6 default 0x5000 if MACH_STM32F103 && !MACH_STM32F103x6 # Ram size of stm32f103x8 default 0x8000 if MACH_STM32G431 @@ -384,7 +389,8 @@ choice bool "USB (on PA11/PA12)" if HAVE_STM32_USBFS || HAVE_STM32_USBOTG select USBSERIAL config STM32_USB_PA11_PA12_REMAP - bool "USB (on PA9/PA10)" if LOW_LEVEL_OPTIONS && MACH_STM32F042 + bool "USB (on PA9/PA10)" + depends on MACH_STM32F042 || MACH_STM32F070x6 select USBSERIAL config STM32_USB_PB14_PB15 bool "USB (on PB14/PB15)" @@ -434,7 +440,7 @@ choice select CANSERIAL config STM32_CANBUS_PA11_PA12_REMAP bool "CAN bus (on PA9/PA10)" if LOW_LEVEL_OPTIONS - depends on HAVE_STM32_CANBUS && MACH_STM32F042 + depends on HAVE_STM32_CANBUS && (MACH_STM32F042 || MACH_STM32F070x6) select CANSERIAL config STM32_CANBUS_PA11_PB9 bool "CAN bus (on PA11/PB9)" diff --git a/src/stm32/stm32f0.c b/src/stm32/stm32f0.c index 72fc1645e..d7af831e3 100644 --- a/src/stm32/stm32f0.c +++ b/src/stm32/stm32f0.c @@ -186,10 +186,8 @@ armcm_main(void) hsi14_setup(); // Support pin remapping USB/CAN pins on low pinout stm32f042 -#ifdef SYSCFG_CFGR1_PA11_PA12_RMP if (CONFIG_STM32_USB_PA11_PA12_REMAP || CONFIG_STM32_CANBUS_PA11_PA12_REMAP) - SYSCFG->CFGR1 |= SYSCFG_CFGR1_PA11_PA12_RMP; -#endif + SYSCFG->CFGR1 |= 1<<4; // SYSCFG_CFGR1_PA11_PA12_RMP sched_main(); }