About SKR2 settings

I just purchased SKR2 board from BigTreeTech and want to run it with Repetier ver2 firmware. I see in constants.h file that STM32F4 chip is supported however SKR is not explicitly defined:
// STM32F4 based boards (3000 - 3499)
#define MOTHERBOARD_RUMBA32 3000
Should I use any of these 2 motherboards in my settings, or do I need a different setup?
If somebody is already running Repetier on SKR2 and could share config, that would help immensely.



  • None of them will work. Checking the new board I see it uses a STM32F407VGT6 with 168MHz. Both boards use the F406 with 180MHz. Don't think difference are big enough to make changes necessary, but you need to set the correct cpu frequency and have a board description with the correct pin assignments for the board.

    If you are up to some testing I can try to copy some required files and make changes to the firmware so it theoretically should then work at the weekend, but it will be untested as I do not own that board. I would then post progress here for testing.
  • Sure, I can test. Hopefully it won't take more than 3 weeks, because then I will be out of town for 1 month.

    I am upgrading my old printer that currently has 8bit CPU controller running on Repetier 1.0.x. It is CoreXY H-bot with closed loop stepper drivers on XY motors, regular stepper on Z and single Hemera extruder. I have ABL enabled with Z-max sensor configured as Z-probe. Also have Zmin, Xmax and Ymax sensors. LCD is really old one - 4 lines with 20 characters in each but with SD card reader.


  • At least the board configuration would be no problem. Features should all work ok. LCD type is supported but you might need to provide the driver/pins manually if there is no official connector for that format, but I will see then.
  • Ok, I have include dit all and it compiled a test config well.
    and in platformio.ini default_env to SKR2

    The board uses 3 different hardware SPI so hope spi devices work correctly. See skr.h for definitions and comments. By default the sd card on the board is used which has an own spi.
  • edited August 2
    Wow! You even added all pin numbers! I was doing the same but will rather use your file. :)

    I downloaded the latest dev2 version and was able to successfully compile it with the changes you suggested. Unfortunately PC cannot "see" the board. Baudrate is set correctly. I tried to change BLUETOOTH_SERIAL value from 101 to -1 and then to 1 (not sure if this is even relevant). Did not see any difference in behavior with -1, and got compilation errors when set to 1. The same error appeared in several files saying - "undefined reference to `Serial1'"

    Just to make sure the board is functional I loaded Marlin and was able to connect to it and run G-codes via Pronterface.

    I'll keep looking into the issue, but decided to post this update in case you've seen this problem and have a quick solution.


  • Just to be sure uploading is working and only after compilation it is not working? I ask because windows has problems seeing board in dfu mode at least without some drivers if I remember right (no real windows user).
  • edited August 3
    Compilation ends with SUCCESS status. Then using Windows Explorer's "Sent to" function I send firmware.bin file to SD card. After clicking Eject SD and removing SD card from PC I insert it into SKR2 and power it on via USB cable from PC.
    One red and one green LEDs light up and another red LED flushes several times and then comes up in half brightness. PC does not detect new serial port and Pronterface has nothing to connect to.

    Then if I disconnect SKR2 from USB and put SD card into PC's card reader I can see that firmware.bin file was renamed into FIRMWARE.CUR.

    I am comparably new to VSC and following Youtube instructions describing how to compile Marlin firmware and upload it to SD card. When repeating the exact same steps with Marlin code - it works. PC adds COM3 port and Pronterface can communicate with it. The file, btw, gets renamed into FIRMWARE.CUR as well.

    I think if missing driver would be an issue, it won't work with Marlin as well.

    Apart from this, when I set Z_PROBE_TYPE to 1 (1 = default z probe) I got the following compilation errors:
    Compiling .pio\build\SKR2\src\io\io_temperature.cpp.o
    src\drivers\zprobe.cpp: In static member function 'static float ZProbeHandler::runProbe(uint8_t, bool)':
    src\drivers\zprobe.cpp:278:27: error: redeclaration of 'RememberedEndstopMode oldMode'
      278 |     RememberedEndstopMode oldMode; // RAII does restore on return
          |                           ^~~~~~~
    src\drivers\zprobe.cpp:132:27: note: 'RememberedEndstopMode oldMode' previously declared here
      132 |     RememberedEndstopMode oldMode; // RAII does restore on return
          |                           ^~~~~~~
    *** [.pio\build\SKR2\src\drivers\zprobe.cpp.o] Error 1

  • Not sure if you are familiar with Marlin code and if this is helpful at all, but here is the video showing how to set up ports for it. You can watch from time stamp 7min 20sec

    And here is another link. It is for SKR PRO and I don't know if this applies, but may give you some ideas https://github.com/bigtreetech/BIGTREETECH-SKR-PRO-V1.1/issues/18

  • Z-Probe is fixed. Was just deleting line 278.

    Not sure if the sd card upload is something that comes from the chip or not. The STM32 on rumba have a DFU mode that I use for uploading. But that is one mode used by some chips so it can be and as long as it also works after marlin has been replaced it is ok to use that.

    Unlike marlin I use the provided serial solution from STM32 for usb. This gets influenced by the special board definition in stm32f4.ini in this part:

    # src_filter = ${common.default_src_filter} +<boards/STM32F4> +<boardFiles/skr2>
    src_filter = ${common.default_src_filter} +<boards/STM32F4>
    extends = stm32f4_common
    board = skr2
    board_build.offset = 0x8000
    board_upload.offset_address = 0x08008000
    board_build.variants_dir = src/boardFiles
    board_build.ldscript = src/boardFiles/skr2/ldscript.ld

    Fixed settings are -DUSBCON -DHAL_UART_MODULE_ENABLED -DUSBD_USE_CDC which are needed to enable usb drivers.
    The part that is unsure is
    -DUSBD_VID=0x8000 "

    These define how it is named and might windows make not detect it. Can you check in hardware manager if you see it as unknown device. I just copied it from rumba32 settings where it works, but there Manufacturer has name "Unknown" so that might be a significant difference making it fail detecting on windows.
  • Device Manager cannot see it at all - the entire Ports branch is missing.
    Then I tried Marlin once again. In Device Manager under Ports (COM & LPT) I got USB Serial Device (COM4).
    It says Manufacturer "Microsoft" and uses device driver from Microsoft.

    Under Details there are lots of fields that unfortunately is impossible to copy all together, but here are few that you may be interested in seeing:

    Device instance path: USB\VID_0483&PID_5740&MI_00\6&2FF63EB9&0&0000
    Hardware IDs: USB\VID_0483&PID_5740&REV_0000&MI_00
    Bus reported device description: MARLIN_STM32F407VGT6_CCM CDC Config
    Last known parent: USB\VID_0483&PID_5740\3559345F3439

    So, looks like -DUSBD_VID should be 0x0483 and -DUSBD_PID value is correct.

    I tried  -DUSBD_VID=0x0483 and even tried to set Microsoft in Manufacturer field but that did not change anything.


  • Actually you always should copy VID and PID. VID is vendor ID and PID is product id of that vendor, so only combination of them make sense. What I have entered is the VID/PID I have working with rumba32.

    But I have now ordered the skr 2 to see myself. It is hard to do remote debugging and having it locally for tests is much easier especially since I see some things other might not mention or even notice to be important. So lets hope I see something then so it works quickly.
  • It is hard to do remote debugging and having it locally for tests is much easier

    You are absolutely right. Meanwhile I will focus on hardware changes, will need to do lots of crimping, replace power supplies, etc.

    Looking forward for your test results and updates.


  • Some good news. I found why the executeable did not run - its start address needed to be realocated to 0x8000 to work with bootloader. Latest commit now compiles and I can connect via usb. Have no printe rconnected, but that should be no problem as it is same code as other stm32 use. If you get problems check pins.
  • That’s great news!! I am out of town once again. Will be able to try in 2 weeks. 
Sign In or Register to comment.