SKR 1.4 - Flashing Custom Firmware

Thanks for this insight! That would be a good way for me to check if my driver has come faulty or not.

So far, I have only looked at the datasheet for understanding basic pin outs and familiarisation with the different registers and their addresses for planning my SPI communication. I’m a beginner in this firmware and mcu stuff so the manual is admittingly very daunting but will try my best to set up the pins to achieve the mode and parameters I want to make user of.

Let’s say I go with using “STEP/DIR” operation, would you know if it would still be possible to set up sensorless homing? The point of getting this driver in the first place was being able to communicate with the driver using SPI and set up sensorless homing.

Not without having communication with the chip to set up StallGuard operation.

Good news @mykepredko, got SPI communication working between the driver and the mcu on the MANTA board by configuring the TMC5160 to operate in ‘mode 2’, which essentially sets both SD_mode and SPI_mode to high. So I have been able to get basic step and direction signals sent over to the driver to carry out basic stepper rotation. Although, when I come to add sensorless homing by setting up StallGuard operation as you have mentioned, I’m running into an issue where the motor just does not stall no matter how hard I press on the rotating stepper shaft.

I have ensured to set the sensorless homing jumper for my x axis driver as seen in the following schematic:

I haven’t uploaded my code on this forum since it is STM32CubeIDE, but thought I could summarise what I’m trying to do
In my code, I have ensured to do the following:

  • Configure the diag1 pin (which would be assigned to the endstop1 pin which I checked is PD3 in the Klipper code) as an GPIO_EXITI interrupt pin. So when the pin is pulled LOW, it would interrupt running the while loop for rotating the stepper and disable the driver and turn off the LED. I also configured the DIAG1 pin to be an active low that uses the falling edge to signal an interrupt and have no need to use any external pull up resistor as the driver can independently drive the pin HIGH.

  • I have written to IHOLD_IRUN Register to set the hold and run currents of the driver.

  • Writing to the register COOLCONF to configure the stallguard sensitivity and enable diag1 pin to detect stalls. I have tried with setting the sensitivity towards the higher end by using values such as -64, -50 and -45 (sensitivity in the COOLCONF register is within a range of -64 to +63, where the lower values result in higher sensitivity)

-I seem to have set constant off-time mode and not spreadCycle when writing to the CHOPCONF register. Apparently, spreadCycle is better for stall detection so wonder if that is worth a fix?

  • Set a reasonable rpm that should be enough to detect stalls

I have even coupled an LED to turn off on condition a stall is detected as an easy indicator and have yet to see this LED turn off.

If you had any ideas from your experience working with and setting up sensorless homing with these drivers and/or boards, that would be much appreciated.

Looks interesting. Glad to hear you have SPI working.

You’re still using an SKR 1.4 board for this? How are you going to handle normal movements - are you going to use STEP/DIR/EN or through the SPI port?

I would be interested in seeing your code. I like the idea of having an indicator LED (I always like that idea).

I’d be interested in seeing your code.

So using the MANTA M5P Board and using STM32CubeIDE to code the custom firmware as the manta as the stm32 mcu. And the following is a summary and main snippets of my code that I added onto the ide after generating the main.c from CubeMX:

  1. Initialization
  • HAL & clocks: Calls HAL_Init() and SystemClock_Config() to get the MCU up and running.
  • Peripherals:
    • GPIO (MX_GPIO_Init):
      • EN (PA15) as push-pull output → drives the TMC5160’s enable pin low to turn the driver on.
      • DIR (PC9) and STEP (PC8) as outputs for step/dir signaling.
      • LED (PD2) as output for visual feedback.
      • DIAG1 (PD3) as a pull-up input → reads the driver’s open-drain stall signal.
    • SPI2 (MX_SPI2_Init): Configured as a 4-wire master to talk to the TMC5160’s SPI interface.
    • TIM3 (MX_TIM3_Init): Used as a micro-delay timer for generating precise STEP pulse widths.
  1. Driver Configuration via SPI2
    In main(), right after HAL_TIM_Base_Start(), I send a handful of 5-byte datagrams down SPI2 to the TMC5160:

Then I write the following datagrams to the following tmc driver registers:

TMC5160_WriteReg(0x00,  (1U<<8));       // GCONF: bit-8 → DIAG1 goes low on StallGuard2 stall
TMC5160_WriteReg(0x10,  0x08140A);      // IHOLD_IRUN: IHOLD=8, IRUN=20, IHOLDDELAY=10
TMC5160_WriteReg(0x11,  0x0000000A);    // TPOWERDOWN
TMC5160_WriteReg(0x14,  0x00000000);    // TCOOLTHRS=0 → StallGuard2 always active
TMC5160_WriteReg(0x6C,  0x04814153);    // CHOPCONF: SpreadCycle, 16 µstep, TOFF=3, TBL=24
TMC5160_WriteReg(0x6D,  0x00440000);    // COOLCONF: SGT=–60, SFILT=0

SPI2 is used only to write to these registers (no reads or other data transfers).

These register settings together turn on sensorless StallGuard2, tune its sensitivity, and set my motor currents & microstep mode.

  1. Stepping Loop & Stall Detection
while (1) {
  // 1) Poll DIAG1 (PD3). If it’s pulled LOW by the driver, we’ve hit a stall:
  if (HAL_GPIO_ReadPin(GPIOD, GPIO_PIN_3) == GPIO_PIN_RESET) {
    HAL_GPIO_WritePin(GPIOD, GPIO_PIN_2, GPIO_PIN_RESET); // turn off LED
    HAL_GPIO_WritePin(GPIOA, GPIO_PIN_15, GPIO_PIN_SET);  // disable driver
    break;
  }
  // 2) Otherwise, generate one STEP pulse:
  HAL_GPIO_WritePin(GPIOC, GPIO_PIN_8, GPIO_PIN_SET);
  microDelay(100);  
  HAL_GPIO_WritePin(GPIOC, GPIO_PIN_8, GPIO_PIN_RESET);
  microDelay(100);
  // 3) LED ON while spinning (no stall)
  HAL_GPIO_WritePin(GPIOD, GPIO_PIN_2, GPIO_PIN_SET);
}

EN (PA15) = LOW → driver enabled; when a stall is detected, I drive it HIGH to cut power.
DIR (PC9) is set once at startup and never changes, so the motor runs in one direction.
STEP (PC8) pulses at 5 kHz (100 µs high, 100 µs low) for continuous rotation.
PD3 is sampled each pass; when the TMC5160’s StallGuard2 logic pulls DIAG1 low, I stop the loop.

The pin out configuration for my mcu is as follows:

It would be greatly appreciated if you could see where I may be going wrong. After so much troubleshooting and changing the parameters, I have yet to stall my motor. I’ve just been holding down a plier on the shaft as it rotates no matter how much I press, it just doesn’t turn off. I do also see the current slightly increase but nothing too crazy but the stepper warms up as I hold it for quite a while.

You’re definitely on the right track.

The only question I have is your choice of LED - you say you’re working with a Manta M5P and you’re using PD2 for an LED but when I look at the schematic, PD2 is M2STOP-Det.

Why aren’t you using PC11 which is the onboard LED?

My big suggestion for you is to get an ST-Link V2 and use it as a debugger as well as a programmer. By doing that you can:

  • Single step/set breakpoints
  • View and change MCU registers on the fly
  • Confirm you are running the code you think you are running

Here’s my setup for working with BTT boards (and their 5 pin SWD connector) - note that I painted pin 1 white to help me make sure I plug it in the right way:

Cheap, really helpful and being able to use a real time debugger is a good skill to have. You can use the ST-Link V3, but it is harder to make a connection to a custom connector.

My second suggestion is to add the code to read back the contents of registers. When I worked with the TMC2225, it was a good indicator for me that datagram communications was working.

I’m making these suggestions because I don’t think you can confirm that you are setting the registers in the way that you think you are and adding the debug tool will give you that confidence.

Wow thanks for the reply. So I’ve been current using at ST LINK V2 the ones that look like a USB and just plug straight into my PC and are wired as you explained to me earlier when got my LED flashing. I’ve been using this ST LINK to also flash the firmware to the board. The USB looking ones should also be able to implement the troubleshooting you’ve suggested or does it need to be that bulkier version?

In terms of reading the registers, that is a solid idea just need to see how I’m going to output them on the stm32cube ide. Although seems possible as like you said, the ST LINK does also serve as a debugger so should allow me to read back from the mcu for troubleshooting. I wouldn’t necessarily need to have the cm4 installed yet let’s say to establish serial port communication between the board and ide to do this?

What do you mean the “ST LINK V2 the ones that look like a USB”? Can you send me a picture of what you’re using/want to use?

When you select “Debug” for your project instead of “Release”, you will get a different desktop on STMCubeIDE that allows you to access the registers.

So this is the ST LINK I’m currently using:

And thanks for the tip I will check out the debugger then.

Huh,

That ST-Link doesn’t show up on Digi-Key, but it does on Mouser.

It looks interesting as you can probably make a more robust connection using a 10 pin IDC and ribbon cable.

Thanx for that pointer.


Just as a thought - should this be moved to a new thread as you have resolved the issues with the SKR 1.4 and are going onto a new project with the Manta M5P?

Yeh it was some random one I bought of Amazon and been seeing others using it in their tutorials so seems to be a workable solution. I will see how it goes then and keep you posted no problem.

And yes happy for us to move the discussion to one for Manta M5P.

1 Like