SKR2 Firmware

Just recently got my board the new SKR 2 (Rev B), however I discovered it wasn’t the SKR Pro v1.2 I thought I ordered.

So, now I have tasked myself with figuring out how to compile the new board with the firmware builder repo.

I have ran into a few compiling issues and am hoping someone can point me in the right direction.

I have tried two ways of compiling, first on macOS which I get permission denied errors to edit the Configuration.h. No clue why this is an issue.

Swapped to Win10 with wsl and have got a bit further but run into /HAL/STM32/inc/Conditionals_LCD.h: No such file or directory..

This is my fork if you want to see the code and hopefully be able to reproduce my issues.
https://github.com/erickaby/mpcnc-firmware/tree/feature/skr-2

I thought there was an issue with the skr pro 2.0. I can’t remember what the issue was though.

I haven’t tried to configure it for that board, but the problems you’re having look like issues with the tools, and not with the firmware. What I would try is to start fresh, with the MarlinBuilder releases firmware, unedited, and just try to compile that. Once you have it compiling, change the board to the 2.0 and see where you hit a wall.

There are platformio instructions in the docs for windows.

There was an issue around burning up TMC2209 stepper drivers. Now, there are ways to repair the board. Since then they have released a new version and have split them to rev_a (board with issue) and rev_b (fixed board). A quick google search can tell you which board revision you have.

In Marlin, we get two motherboard options BOARD_BTT_SKR_V2_0_REV_A and BOARD_BTT_SKR_V2_0_REV_B. Only difference between the two options is that marlin warns you about the issue with the stepper drivers when building the firmware.


So, I have took your advice and tried another machine with windows 10 and WSL.

Cloning the repository into WSL’s file system, I found that I had permission errors when trying to build (the same errors as before with macOS).

Then I tried cloning the repository to my Desktop (Windows file system), there was no permission errors. So I was able to continue.

I also noticed when cloning, the files all changed to ‘dos’ text file format. Which caused errors when running the scripts in WSL. I was able to fix this by removing all changes to my branch, another option is running dos2unix in the root of the repo.

Following the UBUNTU_BUILD.md file under the docs folder in the repository, I installed Python and the virtual environment successfully.

Cloned the Marlin repository.

Then ran the build steps for the V1CNC_Skr1p3_2209 successfully. Received the firmware.bin file.

To configure the SKR2 board I created a new branch and applied changes. Here are the two files:

They were made by referencing both the skr pro board and skr 1.3 configurations, as well as the skr2 repository on the BTT github.

Compiling the SKR2 board config threw my error from before of ../HAL/STM32/inc/Conditionals_LCD.h: No such file or directory

So it seems, there is an issue either with my configuration or something specific to the board. Not too sure where to look from here, anywhere I should be looking to fix the issue?

Okay, figured it out and have got it compiled and flashed successfully.

Turned out I was removing the wrong HAL configs from Marlin.
image

With this I wonder if my other settings will be correct. What should I be testing on my board to see if I have the right config settings?

2 Likes

Oh wow. You did the hard way by actually using MarlinBuilder. I was suggesting downloading the release zip for skr to get started. But what you did is even better.

There isn’t much to test, really. M119. M122. Put some motors in and drive them around. If those all work, then combination functions like homing will work. And anything else is pretty simple.

Nice job. Thanks for sharing.

1 Like

Thanks. I see, that would of been easier haha.

Hooked up all the motors and they worked, but they were configured wrong. 1 x, 1 y, 2 z, and 1 extruder. Didn’t get a chance to change the config before frying the board… Oh well I have a SKR pro v1.2 on the way. The board fried when I was trying to connect the board to the computer to test out cncjs. I had the jumper on the wrong pin, smoke and all.

I was going to do a pull request in the MarlinBuilder repo for the skr2 board but since I can’t do more testing it might not be worth it.

The Dual or DualLR (low rider) are configured for dual endstops.

Which jumper? That is unfortunate.

Did you have the rev b?

Of course that makes total sense, I had been compiling for Duel the whole time until I started getting issues and changed to the original one to eliminate problems then forgot about it.


I plugged the usb in while using 12v-24v power as I wanted to connect to cncjs.

It was the rev b board. However, I think I was having issues with the usb controller from the first day. Since getting the board the pc was never able to even see the board connected. Both on Windows and macOS.

I fried it because I was just messing around with random configs to see if I could get something to work.

This should be fine. It just won’t stay powered when you disconnect the 12V. If you managed to jumper all three I could see a problem, but you should be able to power it via 12V and use the usb at the same time (intermittently). At least, I have with the skr pro.

That was what I expected. However, it clearly didn’t like it as it had a bit of smoke while I watched the LED’s slowly die.

I couldn’t actually find the component which started smoking, I’m not too bad at smd soldering and potentially could of repaired it.

I have been in contact with BTT support the last week from having firmware flashing issues, and now raised this issue. Waiting on their response.

I would guess it is the 5v regulator. I assume you checked the fuses.

Yeah, first thing I checked was the fuses.

BTT support told me to test this:

It is possible that the motherboard is short-circuited. Please check if the chip is damaged. Or if you have the buzzer gear of the multimeter, you can test the 12V, 5V and 3.3V continuity of the motherboard. If the buzzer sounds, it is a short circuit.
image

Turned out my 3.3v was short-circuited.

1 Like

Went to have a look at your diffs - as I’ve also got an SKR 2 here - only to get a 404 in response.
I’ve used MarlinBuilder, configured a board and built, I just haven’t flashed it yet. TBD.

Sorry I removed that branch. Here is my new one, this one compiled and flashed with no problems.
https://github.com/erickaby/mpcnc-firmware/tree/feature/add_board_skr2

1 Like

I’ve been messing with the hw config, so still haven’t had a chance to look at the fw yet.

One thing I noticed - the SKR2 appears to only have 1 explicit endstop sensor per axis, with the adjacent connectors ostensibly for filament runout (Z2 being power detection). Any reason these shouldn’t be used for endstops, or do we wire the endstop switches in series? (Not that it’s needed just yet)

You want one endstop per driver if you want it to do autosquaring (And with Marlin firmware, there’s no reason to use endstops at all unless you’re doing autosquaring.)

So you’ll be using the other inputs for endstops. Since the firmware really only cares about pins, and not what the silkscreen on the boards says, this is perfectly fine.

1 Like

With series wiring, that’s by definition 1 stop per axis, isn’t it? (Scratch that - re-reading appears to suggest 2 drivers per XY axis for endstop use)

It was less what the silkscreen says and more whether the fw has a fixed setup - well, as fixed as code gets - on that side of the config. No idea yet, I’ll need to have a bimble through the code tree.

We don’t have any firmware for the skr pro 2.

For series wiring, just skip the endstops. If you must, then it is one endstop per axis, not one per motor. And remember that endstops are ignored unless you are homing, which is pretty useless if you have series wiring, since the origin is based on the workpiece, not the mavhine coordinates.

1 Like

Clarifying (hopefully).

When using one stepper driver to run both motors on an axis, the two motors should be wired in series. Since these motors will always move identically, auto-squaring is not possible. You can use an end stop for machine homing but you only need one per axis.

A dual end stop configuration requires that each motor have a dedicated driver, so each motor is directly wired by itself to that driver. With each motor able to be driven separately, if there is an independent end stop at the same end of travel on each rail for the axis, then as part of a customized homing sequence one motor per axis can be micro-adjusted to automatically square the X and Y axes to one another. The amount of adjustment needed is normally worked out during final tuning of the machine and stored in the eeprom of the controller. Outside of the homing/squaring sequence the firmware sends the same motion instruction to both drivers on the axis so they move in lockstep during all other machine operations.

We don’t have any firmware for the skr pro 2.

Not yet… Looks like either @snag will have something worth pushing soonish, if not then I’ll carry on with mine.

@ttraband - yeah, that makes sense. Learning quickly with this setup, it’s a bit different to stuff I’ve worked on before. In part because someone else has already done the heavy lifting & I need to follow along.