GrblHAL support for BTT SKR MINI E3 V2.0 3D printer board

[MeKeCNC]

Hi
Is it possible to support, 64 pin STM32F103RC with 256 Kbytes of Flash memory? so I want to use BTT SKR MINI E3 V2.0 3D printer board.
https://www.bigtree-tech.com/products/bigtreetech-skr-mini-e3-v2-0-32-bit-control-board-integrated-tmc2209-uart-for-ender-3.html

[terjeio]

It should work out of the box? You will have to create a map file for it as I assume none of the current mappings will work.
Additional features above what is currently supported might be a bit problematic as both free RAM and FLASH is on the low end with the current linker file definitions. This can be overcome by adding a new build option and a corresponding linker file for this MCU.

[MeKeCNC]

Hi terjeio
Thank you very much for your quick reply, I appreciate your work very much. I prefer this card because of its affordable price and many features. I would be very grateful if you could help to create a separate project build file/folder for this processor, I can create the CPU pin map file myself

[terjeio]

There is no need for a new project build folder, post the pin map file here and I will incorporate it in the current one. Alternatively create a PR for it.

[MeKeCNC]

I have created the CPU pin map, the file is here as attachment,
BTT_SKR_MINI_E3_V2.0_map.zip

additional note:
UART pins for TMC2209
TX4->PC10
Rx4->PC11
schematic of this board
BTT SKR MINI E3 V2.0_SCH.pdf

[terjeio]

UART mode for TMC2209 is not possible to test for me as I do not have hardware for that. With lots of luck in might work...

SDCAR and EEPROM support should be possible to add as well, but needs code changes as pins & ports are not the same as the ones already supported?

How is this board programmed, via a bootloader or a ST-link programmer? If via a bootloader it is likely changes will have to be made (new linker script).

[MeKeCNC]

via bootloader; you put the bin file inside the SD card and when you reboot the board, the code loads.

Can we upload the GRBL based compiled bin file/code to the card with the same method?

[terjeio]

Can we upload the GRBL based compiled bin file/code to the card with the same method?

Yes, but kind of hard for me to make a working binary when I am not able to test it. And there is a risk of bricking the card, the only way to recover it if this happens is to use a ST-Link programmer. Do you have one?

[MeKeCNC]

Yes I have ST-Link programmer, no problem I can repair the bootloader, by the way I compiled the code you edited and uploaded it to the board, I can communicate and move the motors but I couldn't communicate and set the tmc2209

[terjeio]

Great, having the programmer means you can set breakpoints for debugging. Do you have access to an oscilloscope or logic analyzer?

First step would be to check if there is any traffic on the Trinamic driver UART, set breakpoints here

STM32F1xx/Src/serial.c

Line 427 in 643400d

char data = USART->DR;

and here

STM32F1xx/Src/serial.c

Line 440 in 643400d

uint_fast16_t tail = txbuf2.tail; // Get buffer pointer

Are they hit?

[MeKeCNC]

Yes, I have both the oscilloscope and the logic probe.
During the debug process, it did not pass this point before reaching the debug points you mentioned. https://github.com/grblHAL/core/blob/2068165e62c949bda37e7006aebd1406b18d76d2/nvs_buffer.c#L244

Other thing, is there any gcode to check the status of tmc2209 via using console?

[terjeio]

Yes, I have both the oscilloscope and the logic probe.

Great, that will help if we run into problems with the UART code.

I have done some testing today with a Bluepill. There are a couple of bugs - init code for the TMC2209 was not in place and there were some timing issues in the low-level interface code. I'll commit an update tomorrow.

Using flash for settings storage might require some work, the memory map is different and that could be the reason it hangs. I'll come back with how to disable this. It is likely to be easier to later switch to EEPROM storage than attempt to fix flash storage, I prefer EEPROM storage when available so I guess that should be prioritized.

Other thing, is there any gcode to check the status of tmc2209 via using console?

Yes, a number of Marlin style M-codes are implemented - M122 is for debugging. Info here.

FYI ioSender has a tab for Trinamic driver tuning that uses the debug information.

Example M122 output:

[TRINAMIC]
                      X
Driver          TMC2209
Set current         500
RMS current         489
Peak current        691
Run current       15/31
Hold current       7/31
CS actual          7/31
stealthChop       false
msteps                2
tstep           1048575
pwm
threshold             0
[mm/s]                -
OT prewarn        false
OT prewarn has
been triggered    false
off time              3
blank time            1
hysteresis
-end                 -2
-start                4
Stallguard thrs       0
DRIVER STATUS:
stallguard
sg_result             0
stst                  *
fsactive
olb
ola
s2gb
s2ga
otpw
ot
STATUS REGISTERS:
 X = 0x80:07:00:00
ok

Note that you have to enable Trinamic drivers with the $338 setting!

[terjeio]

Update just committed. I have enabled EEPROM support - this causes flash overflow so I had to add a new linker script to take advantage of the larger flash (and RAM). You have to select the Debug F103RC build option available in the build menu (from the "hammer" icon) to make it compile.

[MeKeCNC]

You are a responsible and very helpful person, thank you very much.

Update just committed. I have enabled EEPROM support - this causes flash overflow so I had to add a new linker script to take advantage of the larger flash (and RAM). You have to select the Debug F103RC build option available in the build menu (from the "hammer" icon) to make it compile.

I re-uploaded the code you just edited, but nothing changed, it still hangs in the same place during debug, I took a video and added it below
https://youtu.be/uuYLsN6Yqkc

FYI ioSender has a tab for Trinamic driver tuning that uses the debug information.

in ioSender, after connet the bord the console output
and I am trying the M122 code but the command is not accepted
https://youtu.be/KWL4XMe4LuU

[terjeio]

Have you enabled the BTT board in my_machine.h? This line has to be commented in:

STM32F1xx/Inc/my_machine.h

Line 26 in ad3d08b

//#define BTT_SKR_MINI_E3_V20

[MeKeCNC]

Yes this is my file

// NOTE: Only one board may be enabled!
// If none is enabled pin mappings from generic_map.h will be used.
//#define BOARD_CNC3040
//#define BOARD_CNC_BOOSTERPACK
#define BTT_SKR_MINI_E3_V20
//#define BOARD_MY_MACHINE // Add my_machine_map.h before enabling this!

// Configuration
// Uncomment to enable.

#define USB_SERIAL_CDC 1 // Serial communication via native USB. Comment out for UART communication.
//#define SDCARD_ENABLE 1 // Run gcode programs from SD card, requires sdcard plugin.
//#define KEYPAD_ENABLE 1 // I2C keypad for jogging etc., requires keypad plugin.
//#define ODOMETER_ENABLE 1 // Odometer plugin.
//#define TRINAMIC_ENABLE 2130 // Trinamic TMC2130 stepper driver support. NOTE: work in progress.
#define TRINAMIC_ENABLE 2209
//#define TRINAMIC_ENABLE 5160 // Trinamic TMC5160 stepper driver support. NOTE: work in progress.
//#define TRINAMIC_I2C 0 // Trinamic I2C - SPI bridge interface.
//#define TRINAMIC_DEV 1 // Development mode, adds a few M-codes to aid debugging. Do not enable in production code.
#define EEPROM_ENABLE 1 // I2C EEPROM support. Set to 1 for 24LC16(2K), 2 for larger sizes. Requires eeprom plugin.
//#define EEPROM_IS_FRAM 1 // Uncomment when EEPROM is enabled and chip is FRAM, this to remove write delay.

[MeKeCNC]

when I followed the debugging step by step, I found that it was hangs at this point, I think it hangs because it is waiting for data on the usb, is it correct?

STM32F1xx/Src/usb_serial.c

Line 80 in ad3d08b

if(!hal.stream_blocking_callback())

[terjeio]

when I followed the debugging step by step, I found that it was hangs at this point, I think it hangs because it is waiting for data on the usb, is it correct?

When the USB output buffer is full it loops there until a connection is established.

I have updated the ST driver framework to the latest version and I am having problems with flakiness - perhaps due to the MCU beeing a clone or the fact that I have nearly used all available flash/RAM:

I have found a couple of further bugs, and I am reminded why did not add TMC2209 to the initialization - the code is not 100% ready... If you are still interested there are a few more things to try:

Add
#define TRINAMIC_MIXED_DRIVERS 0
at the start of btt_skr_mini_e3_2.0_map.h. This will disable the $338 setting, it is not needed since it is not possible to have other drivers than TMC2209. It will also bypass a problem where the setting $338 does not immediately enable the drivers, a restart is required which, for you, I believe resets $338 back to 0.

Change this line

STM32F1xx/Src/serial.c

Line 448 in ad3d08b

USART->BRR = UART_BRR_SAMPLING16(HAL_RCC_GetPCLK2Freq(), 115200);

to
USART->BRR = UART_BRR_SAMPLING16(HAL_RCC_GetPCLK1Freq(), 115200);
to get the correct baud rate.

I am not sure this line is needed or not, comment out if UART output is not working:

STM32F1xx/Src/serial.c

Line 445 in ad3d08b

__HAL_AFIO_REMAP_USART3_PARTIAL();

Disable settings storage by changing

STM32F1xx/Src/driver.c

Line 905 in ad3d08b

#elif FLASH_ENABLE

to
#elif xFLASH_ENABLE
as it seems the I2C EEPROM is not recognized. I have it working with my Bluepill so I am not sure why. Can you check the label on the EEPROM chip and verify that it is an AT24C32?

Set breakpoints at line 39, 61 and 63 here:

STM32F1xx/Src/btt_skr_mini_e3_2.0.c

Lines 39 to 63 in ad3d08b

	tmc_uart.write_n((char *)dgr->data, sizeof(TMC_uart_read_datagram_t));
	while(tmc_uart.get_tx_buffer_count());
	while(--dly);
	tmc_uart.reset_read_buffer();
	// Wait for response with 3ms timeout
	while(tmc_uart.get_rx_buffer_count() < 8) {
	if(hal.get_elapsed_ticks() - ms >= 3)
	break;
	}
	if(tmc_uart.get_rx_buffer_count() >= 8) {
	wdgr.data[0] = tmc_uart.read();
	wdgr.data[1] = tmc_uart.read();
	wdgr.data[2] = tmc_uart.read();
	wdgr.data[3] = tmc_uart.read();
	wdgr.data[4] = tmc_uart.read();
	wdgr.data[5] = tmc_uart.read();
	wdgr.data[6] = tmc_uart.read();
	wdgr.data[7] = tmc_uart.read();
	} else
	wdgr.msg.addr.value = 0xFF;

When continuing from line 39 you should see output on the UART line, if a valid response is forthcoming the next break should be at line 61 - if not it will stop at line 63.

Here is a valid read transaction on my scope, timebase is 200us/div:

The blue and yellow traces track each other when transmitting, the blue trace shows the response. This since Rx an Tx is wired together via 1K resistor and I am monitoring on both ends of it.

Finally - I can upload the project as it is now as a zip file if of interest.

[MeKeCNC]

Finally - I can upload the project as it is now as a zip file if of interest.

Yes please, I want to run this board with grblHal. I am quite interested it

[MeKeCNC]

What's your suggestion about it not accepting the M122 command?

[terjeio]

Yes please, I want to run this board with grblHal. I am quite interested it

Ok, you can download it from here.

What's your suggestion about it not accepting the M122 command?

It is due to no motors accepting/responding to configuration during startup.

https://github.com/terjeio/Trinamic-library/blob/5e48bda6977b282d2543c41c83e27ecde224f3ff/tmc2209.c#L103-L108

[MeKeCNC]

the EEPROM chip and verify that it is an AT24C32?

BT24C32A

[terjeio]

BT24C32A

STM32F1xx/Inc/btt_skr_mini_e3_2.0_map.h

Line 37 in ad3d08b

#define EEPROM_ENABLE 2

Change 2 to 3 in this line - I forgot about the 4K chips having a 32 byte page size. I believe it is the first time I've encountered one, hopefully EEPROM storage will then work (you will have to undo the FLASH_ENABLE hack above to test).

[MeKeCNC]

Change 2 to 3 in this line - I forgot about the 4K chips having a 32 byte page size. I believe it is the first time I've encountered one, hopefully EEPROM storage will then work (you will have to undo the FLASH_ENABLE hack above to test).

EEPROM is OK, stored the my setting

still tmc2209 is not working :(

[terjeio]

still tmc2209 is not working :(

Are the breakpoints mentioned above above getting hit? If so, any activity on the UART line?

[MeKeCNC]

Are the breakpoints mentioned above above getting hit? If so, any activity on the UART line?

I will remove the card from its slot and monitor the uart activities with the analyzer as soon as possible.

[terjeio]

I have assembled a revised Nucleo-64 CNC breakout board (for a F446) and managed to get multiple TMC2209 drivers working by increasing the post read data delay to 5000 (from 150):

STM32F1xx/Src/btt_skr_mini_e3_2.0.c

Line 65 in ad3d08b

dly = 150;

Note that the current code does not support sensorless homing as the Stallguard implementation is different from TMC2130/5160 version. I am looking into that now.

[MeKeCNC]

Sorry for delayed reply
I took the card out, figured out UART pins from schematic and connected the RxTx pins with a cable. I compiled and uploaded the project you sent without any changing it, it still hangs during the debugging process, it still doesn't reach the points you mentioned. Also, the RxTx pins are pulled from zero to high level and staying that way.

[MeKeCNC]

When I upload the code to the card and run it normally, while restart process the Rx TX activities are as follows

[terjeio]

Oops, I forgot about that. Add defined(STM32F103xE) || to line 24 in grbl/platform.h so it becomes:
#if defined(STM32F103xB) || defined(STM32F103xE) || defined(STM32F401xC) || defined(STM32F407xx) || defined(STM32F411xE) || defined(STM32F446xx) || defined(STM32F756xx)

It compiles for me when I do that.

[MeKeCNC]

Oops, I forgot about that. Add defined(STM32F103xE) || to line 24 in grbl/platform.h so it becomes:

I added this but the number of errors decreased only

[MeKeCNC]

Ok, it didn't give a compile error after making the following changes

I modified the following files for path
sdcard/sdcard.h,
src/driver.c and
src/diskio.c

I changed both #include "ffi.h" and #include "diskio.h"
to:
#include "../FatFs/ff.h"
#include "../FatFs/diskio.h"

[terjeio]

One more, you have to add FatFs to Includes in C++ General > Paths and Symbols as well.

I was interrupted by a telephone call so I forgot I did that earlier - getting old...

Luckily the SPI port and pins used for the SD-card is the same as the current code so it should work.

[MeKeCNC]

It gives sd card connection error

[terjeio]

You fooled me with your map file? This text is just before the pin definitions:

// The following defines are not used but defined for reference
// Port init and remap is done by HAL_SPI_MspInit() in stm32f1xx_hal_msp.c

Have modified stm32f1xx_hal_msp.c to match the definitions?
I guess driver.h should be included in this file and definition(s) from that used to select a HAL_SPI_MspInit version matching the board.

[MeKeCNC]

Have modified stm32f1xx_hal_msp.c to match the definitions?

I made the changes but the SD card error did not change. I monitored the SPI pins with an oscilloscope no activity

void HAL_SPI_MspInit(SPI_HandleTypeDef* hspi)
{
GPIO_InitTypeDef GPIO_InitStruct = {0};
if(hspi->Instance==SPI1)
{
/* USER CODE BEGIN SPI1_MspInit 0 */

/* USER CODE END SPI1_MspInit 0 /
/ Peripheral clock enable */
__HAL_RCC_SPI1_CLK_ENABLE();

#ifdef BTT_SKR_MINI_E3_V20
// __HAL_RCC_GPIOA_CLK_ENABLE();
/**SPI1 GPIO Configuration
PA5 ------> SPI1_SCK
PA6 ------> SPI1_MISO
PA7 ------> SPI1_MOSI
*/
GPIO_InitStruct.Pin = GPIO_PIN_5|GPIO_PIN_6|GPIO_PIN_7;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;
GPIO_InitStruct.Pull = GPIO_PULLUP;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

#else
// __HAL_RCC_GPIOB_CLK_ENABLE();
/**SPI1 GPIO Configuration
PB3 ------> SPI1_SCK
PB4 ------> SPI1_MISO
PB5 ------> SPI1_MOSI
*/

GPIO_InitStruct.Pin = GPIO_PIN_3|GPIO_PIN_5;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;
GPIO_InitStruct.Pull = GPIO_PULLUP;
HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);

GPIO_InitStruct.Pin = GPIO_PIN_6;
GPIO_InitStruct.Mode = GPIO_MODE_INPUT;
//GPIO_InitStruct.Pull = GPIO_NOPULL;
HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);

#endif
__HAL_AFIO_REMAP_SPI1_ENABLE();

/* USER CODE BEGIN SPI1_MspInit 1 */

/* USER CODE END SPI1_MspInit 1 */
}

}

[terjeio]

__HAL_AFIO_REMAP_SPI1_ENABLE();

... has to be removed. I have uploaded a new version that sets a symbol for backwards compatibility. And I had to reduce the SPI clock frequency to make it work, this is likely due my test setup with a breadboard and flying leads. You should try to increase it again by reducing the clock divider:

STM32F1xx/Src/diskio.c

Line 203 in ad3d08b

hspi1.Instance->CR1 |= SPI_BAUDRATEPRESCALER_32; // should be able to go to 12Mhz...

[MeKeCNC]

Excellent, thank you so much
SD card also worked, now it's time to try on the CNC machine, with which variable we adjust the holding current of the motors, I guess with the variable below, I made a change for 240mA but the current did not increase

https://github.com/grblHAL/Plugins_motor/blob/4198fd26c19b6e403858df677a50d0325d512736/trinamic.h#L56

[terjeio]

If changing the default current you have to reset EEPROM settings after flashing with $RST=* or $RST=&. It is easier to use $settings, also available per axis from the Settings: Grbl tab in ioSender:

[MeKeCNC]

Great, I tried with the board for the first time, the result is successful, now we are used as a CNC machine with a 3D board,

https://youtu.be/f9PZOSTOf88

[MeKeCNC]

terjeio
As we talked before, firmware is uploaded to this card with SD card using bootloader. What is your suggestion to upload firmware to this card with the same method? Because when we switch between the two firmwares Marlin and grblHAL, it will be easy and convenient to install via SD card.

[terjeio]

What is your suggestion to upload firmware to this card with the same method?

It will be the same (or similar) as for the LPC176x driver? A new build option and a corresponding linker file or linker scripts.

[noahwilliamsson]

Hey nice work getting this up and running. I'd like to test this out on a two axis machine. Is there a way to build this project on Linux, without Eclipse? I tried to follow https://github.com/grblHAL/core/wiki/Compiling-GrblHAL for compiling with Arduino (on macOS) but I realized the board wasn't supported by the built-in board manager.

The following attempt failed because the default target all in the generated Makefile is empty:

git clone --recurse-submodules --jobs 10 https://github.com/grblHAL/STM32F1xx.git
cd STM32F1xx
echo '#define BTT_SKR_MINI_E3_V20' >> Inc/my_machine.h
echo '#define EEPROM_ENABLE 1' >> Inc/my_machine.h
vi grbl/config.h
cmake grbl
make -C grbl

[terjeio]

Is there a way to build this project on Linux, without Eclipse?

Possibly, I have not investigated other options such as PlatformIO or use of command line make.

The following attempt failed because the default target all in the generated Makefile is empty:

The CMakeLists.txt in the grbl folder is only for the core and is intended for builds of drivers that uses cmake, such as the RP2040. cmake grbl uses this file only?
I have no idea what it would take to configure this driver for cmake, I am used to the IDE doing the work for me by generating the required makefiles (there is one master makefile and one for each subdirectory).

[MeKeCNC]

It will be the same (or similar) as for the LPC176x driver? A new build option and a corresponding linker file or linker scripts.

I checked the CPU linker related parts you mentioned, but I couldn't get over it, it was a bit confusing.

[lluiscab]

Note that the current code does not support sensorless homing as the Stallguard implementation is different from TMC2130/5160 version. I am looking into that now.

Hi, was sensorless homing ever implemented? I've seen no other mention of it on this thread and I can't get it to work on my machine. I've tried the same board with Klipper and it works perfectly with that software and the same hardware so I'm assuming there's something wrong with the TMC2209 implenentation on grblHAL.

[terjeio]

Hi, was sensorless homing ever implemented?

I believe it is, but not sure about the parameters - I do not have a machine to test with.

I'm assuming there's something wrong with the TMC2209 implenentation on grblHAL.

Could well be, but most likely issues with the parameters (tuning) and not the code? Do you know the parameters that Klippers use and can compare them with grblHAL?

[lluiscab]

I'm not sure whatever to post this here or open a new issue, if you believe this deserves to be it's own issue please tell me all I'll open one accordingly.

Here's the output of M122 and my current configuration:

> M122
[TRINAMIC]
                      X       Y       Z
Driver          TMC2209 TMC2209 TMC2209
Set current        1000    1000    1000
RMS current         994     994     994
Peak current       1405    1405    1405
Run current       17/31   17/31   17/31
Hold current       8/31    8/31    8/31
CS actual          8/31    8/31    8/31
PWM scale            10      10      10
vsense          0=0.325 0=0.325 0=0.325
stealthChop        true    true    true
msteps               32      32      32
tstep           1048575 1048575 1048575
pwm
threshold             0       0       0
[mm/s]                0       0       0
OT prewarn        false   false   false
OT prewarn has
been triggered    false   false   false
off time              3       3       3
blank time            1       1       1
hysteresis
-end                 -1      -1      -1
-start                1       1       1
Stallguard thrs      22      22      22
DRIVER STATUS:
stallguard
sg_result            28       4     260
fsactive
stst                  *       *       *
olb
ola
s2gb
s2ga
otpw
ot
STATUS REGISTERS:
 X = 0xC0:08:00:00
 Y = 0xC0:08:00:00
 Z = 

> $$
$0=10.0 (Step pulse time, microseconds)
$1=25 (Step idle delay, milliseconds)
$2=0 (Step pulse invert, mask)
$3=6 (Step direction invert, mask)
$4=7 (Invert step enable pin, boolean)
$5=0 (Invert limit pins, boolean)
$6=0 (Invert probe pin, boolean)
$9=1
$10=511 (Status report options, mask)
$11=0.010 (Junction deviation, millimeters)
$12=0.002 (Arc tolerance, millimeters)
$13=0 (Report in inches, boolean)
$14=0
$15=0
$16=0
$17=0
$18=0
$19=0
$20=0 (Soft limits enable, boolean)
$21=0 (Hard limits enable, boolean)
$22=1 (Homing cycle enable, boolean)
$23=7 (Homing direction invert, mask)
$24=48.0 (Homing locate feed rate, mm/min)
$25=480.0 (Homing search seek rate, mm/min)
$26=250 (Homing switch debounce delay, milliseconds)
$27=1.000 (Homing switch pull-off distance, millimeters)
$28=0.100
$29=0.0
$30=1000.000 (Maximum spindle speed, RPM)
$31=0.000 (Minimum spindle speed, RPM)
$32=0 (Laser-mode enable, boolean)
$33=5000.0
$34=0.0
$35=0.0
$36=100.0
$37=0
$39=1
$40=0
$43=1
$44=4
$45=3
$46=0
$62=0
$63=2
$64=0
$65=0
$100=480.000 (X-axis travel resolution, step/mm)
$101=480.000 (Y-axis travel resolution, step/mm)
$102=3200.000 (Z-axis travel resolution, step/mm)
$110=1200.000 (X-axis maximum rate, mm/min)
$111=500.000 (Y-axis maximum rate, mm/min)
$112=500.000 (Z-axis maximum rate, mm/min)
$120=10.000 (X-axis acceleration, mm/sec^2)
$121=10.000 (Y-axis acceleration, mm/sec^2)
$122=10.000 (Z-axis acceleration, mm/sec^2)
$130=200.000 (X-axis maximum travel, millimeters)
$131=200.000 (Y-axis maximum travel, millimeters)
$132=200.000 (Z-axis maximum travel, millimeters)
$140=1000
$141=1000
$142=1000
$150=32
$151=32
$152=32
$200=22.0
$201=22.0
$202=22.0
$210=50
$211=50
$212=50
$220=22.0
$221=22.0
$222=22.0
$339=7
$341=0
$342=30.0
$343=25.0
$344=200.0
$345=100.0
$346=1
$384=0
ok

> $I
[VER:1.1f.20221115:]
[OPT:VNMSL,35,512,3,0]
[AXS:3:XYZ]
[NEWOPT:ENUMS,RT+,HOME,TC,SED,TMC=7]
[FIRMWARE:grblHAL]
[NVS STORAGE:*EEPROM]
[DRIVER:STM32F103C8]
[DRIVER VERSION:221206]
[BOARD:BTT SKR MINI E3 V2.0]
[PLUGIN:Trinamic v0.09]

If I manually unlock the machine then I'm free to move any axis without any problem, but when they are being moved as part of the homing process, here's what happens: https://streamable.com/ikk2mo

First movement is homing, second movement is a G0 command after manual unlock.
I am not sure, but by reading the description, if might be related to this issue on Marlin MarlinFirmware/Marlin#14683

I've also tried to home without sensorless activated and every axis moves correctly, this problem is caused by having sensorless homing activated)

In the past (a month ago) I used this board with klipper with the following settings and sensorless homing worked without a problem.

I'd like to point out that the only code change that I've performed in grblHAL has been swapping the values of Y_STEP_PIN with Z_STEP_PIN, Y_DIRECTION_PORT with Z_DIRECTION_PORT, Y_DIRECTION_PIN with Z_DIRECTION_PIN and Y_ENABLE_PIN with Z_ENABLE_PIN in order to swap the Y and Z axis as I want to use my board "z axis" with two motor outputs as my y axis (this board is intended for 3d printers, not cnc machines, so the driver for the Z axis has two outputs for dual Z axis motors, but in my case, it's more useful to have two Y axis motors, as that's my main axis on top of which X and Z move)

I'd also like to ask: I've been looking though the code to quickly see what each settings does, as a lot of them do not show a description with $$ but I've seen that they do have descriptions, why are they not shown?

[terjeio]

@lluiscab There is something odd with the Z-axis sg_result, it is way higher than the other axes.This might be the reason for the noisy movement. A heavy spindle? What happens if you try without the spindle mounted?

I'd like to point out that the only code change that I've performed in grblHAL has been swapping the values of Y_STEP_PIN with Z_STEP_PIN...

I guess ganged motor support should be added to this driver, this would allow you to use the E motor driver for the second Y-motor. Having two motors on the same driver is not ideal.

Are you using Windows and can try ioSender? - it has a Trinamic tuner tab where you can visualize the StallGuard result for different values of the Stallguard threshold.

a lot of them do not show a description with $$ but I've seen that they do have descriptions, why are they not shown?

The descriptions must have been added by your sender - they are not coming from the controller like that. The missing descriptions are thus due to the sender not knowing about the new grblHAL settings. Use $help settings for controller generated descriptions for all settings or $$=<id> where <id> is a settings number for description for a specific setting.

[lluiscab]

Those values were captured after a failed homing attempt. Here's the output of M122 after boot.

> M122
[TRINAMIC]
                      X       Y       Z
Driver          TMC2209 TMC2209 TMC2209
Set current        1000    1000    1000
RMS current         994     994     994
Peak current       1405    1405    1405
Run current       17/31   17/31   17/31
Hold current       8/31    8/31    8/31
CS actual          8/31    8/31    8/31
PWM scale            26      15      26
vsense          0=0.325 0=0.325 0=0.325
stealthChop        true    true    true
msteps               32      32      32
tstep           1048575 1048575 1048575
pwm
threshold             0       0       0
[mm/s]                0       0       0
OT prewarn        false   false   false
OT prewarn has
been triggered    false   false   false
off time              3       3       3
blank time            1       1       1
hysteresis
-end                 -1      -1      -1
-start                1       1       1
Stallguard thrs       0       0       0
DRIVER STATUS:
stallguard
sg_result             0       0       0
fsactive
stst                  *       *       *
olb
ola
s2gb
s2ga
otpw
ot
STATUS REGISTERS:
 X = 0xC0:08:00:00
 Y = 0xC0:08:00:00
 Z = 0xC0:08:00:0

I currently do not have a spindle mounted onto the Z axis.

Ganged motors using the E driver would be a nice to have.

I am using Linux, it seems like ioSender is only available for Windows, I guess I could try a VM or move the machine closer to a windows PC. What should I do there? Change the threshold values until it works?

[terjeio]

Those values were captured after a failed homing attempt.

It is those values that are somewhat useful for tuning. The ioSender tuning tab is better, but for ideal tuning you will need an oscilloscope with a current probe (IIRC) - see the driver datasheet.

Change the threshold values until it works?

Basically yes, you cannort expect the default values to work. I have updated the plugin readme with some missing settings and links to driver information, the datasheets have fairly comprehensive information on how to tune StallGuard.

[lluiscab]

Okay, been playing with ioSender for about an hour now, I've tried every possible value for stall guard and it does not work. I've reflashed the board with klipper and homing there worked perfectly without any weird motor noises or anything like that. It does seem to me like nothing changes between runs, I'm pretty sure that whatever or not the motor makes noise has nothing to do on what the threshold value is, as said, with klipper is runs perfectly without a problem. There 100% has to be something wrong during the homing sequence, if I unlock the machine manually, I can then jog each axis manually and the motor moves perfectly. Pretty sure there's something that's not correctly implemented somewhere

[lluiscab]

Update: While monitoring the stall guard value live (M122 Z S1), I have seen the following output while moving the axis with a G0 command

(...)
[SG:66]
[SG:50]
[SG:66]
[SG:376]
[SG:28]
[SG:410]
[SG:420]
[SG:428]
[SG:358]
[SG:418]
[SG:354]
[SG:434]
[SG:432]
[SG:394]
[SG:308]
[SG:332]
[SG:62]
[SG:308]
[SG:294]
[SG:48]
[SG:52]
[SG:26]
(...)

Why is it that there's values over 255? According to the docs for TMC2209, range for the stall guard threshold is 0-255.

Also, this reporting stops while homing, is there any way to enable it while homing to enable for better debugging?

[terjeio]

I am not able to dig into this until I am back home later in the month, however this issue may contain some clues.

While monitoring the stall guard value live (M122 Z S1), I have seen the following output while moving the axis with a G0 command

You should monitor the StallGuard value while moving with G1 and feedrates equal to the homing rates you intend to use.

Also, this reporting stops while homing, is there any way to enable it while homing to enable for better debugging?

IIRC not easily as the limit switches are polled at a high frequency and reporting is disabled to not put a limit on it.

Did you use default parameter values for Klipper or did you modify any (of interest are Triniamic related values, homing feedrates and acceleration)?