yeah seems good now. on the USB port issue, I just took the port off the board.
So I was using custom firmware on my other printer that turned on bl touch for Z homing and UBL for bed leveling but that firmware hasn’t been updated yet for these new boards. So you think I could just run through the confif=gs turning on the same stuff that was in the old configs?
thanks for your help. after some fiddling and tracing down commands I finally have it working. I also got my firmware installed and working and found the BL touch on this one is toast … literally. Found and repaired crushed bit of the harness for the bltouch and tried it with mine and now it’s all working so I guess I have to order a new BL touch for it heh!
thanks for letting us know glen. Did you have any issues flashing firmware on the SKR2. Doing one right now and cannot for the life of me get this thing to build properly out of VS code.
Guess I should qualify that It will build and says its successful, Now, try to find the Hex file… NOT gonna happen.
Usually its under .pio/blah/blah/blah. this one cannot find it anywhere. I’m suspecting its saying its building but its actually not…
I did at first. but it was because the bugfix was broken and wouldn’t compile for anybody… blew 4 hours on that and in that time I found about the 3 revisions that the board has and you have to be careful about the environment that its the right one. Also check carefully after you burn the firmware the Fan0 on that board is not the same as on the V1.4 boards. on my board the DCIN from the V1.4 board was plugged into the FAN0 port and I think it killed the input on the V2.0 board. There is a slim chance the boards was bad out of the bag though. I may get an RMA so not Knowing, I wanted to let you know what mine was like.
The firmware.bin file winds up in this folderMarlin-B1-2.0.9.2.x.pio\build\BIGTREE_SKR_2
there is deff something wrong, I do not have a .pio folder. I’m pretty sure its building into space.
so it builds with no errors and finishes with no file?
I just tried to compile the firmware I am using now again and i get a platformio error instead. I think VS code has to get outside files to do it’s thing and can’t reach them, it took a while for this to error out. I’ve made a few versions of this firmware and not had any issues before
yes correct, get a completion successful and everything, when I check for the folder, nothing
I’m pretty good at firmware but this one is brutal. I have a feeling its a VScode issue. Going to try to rebuild my environment and see what it does.
try restarting VS code now and try again. I think there was some background crap going on with it and it was broke for a while now I get a success that it compiled but no new file like you are getting. seems to be a moving target
hrm ok I’ve been asking about this in discord does your terminal in VS say something like this around the success statement?
“Checking size .pio\build\BIGTREE_SKR_2\firmware.elf”
I’m going to cut out a whole chunk in the middle but here is most of my terminal window
Executing task in folder Marlin-2.0.x: C:\Users\jasonh.platformio\penv\Scripts\platformio.exe run <
Processing mega2560 (platform: atmelavr; board: megaatmega2560; framework: arduino)
---------------------------------------------------------------------------------------------------------------------------------------Verbose mode can be enabled via -v, --verbose option
CONFIGURATION: Redirecting...
PLATFORM: Atmel AVR (3.4.0) > Arduino Mega or Mega 2560 ATmega2560 (Mega 2560)
HARDWARE: ATMEGA2560 16MHz, 8KB RAM, 248KB Flash
DEBUG: Current (avr-stub) On-board (avr-stub, simavr)
PACKAGES:
- framework-arduino-avr 5.1.0
- toolchain-atmelavr 1.70300.191015 (7.3.0)
Converting Marlin.ino
LDF: Library Dependency Finder → Library Dependency Finder (LDF) — PlatformIO latest documentation
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 6 compatible libraries
Scanning dependencies…
Dependency Graph
|-- 0.4.5
| |-- 1.0
| |-- 1.0
|-- 1.0
|-- 1.0
|-- 2.0
|-- 1.0
Building in release mode
Compiling .pio\build\mega2560\src\src\HAL\AVR\HAL.cpp.o
Compiling .pio\build\mega2560\src\src\HAL\AVR\HAL_SPI.cpp.o
Compiling .pio\build\mega2560\FrameworkArduino\wiring_shift.c.o
Archiving .pio\build\mega2560\libFrameworkArduino.a
Linking .pio\build\mega2560\firmware.elf
Checking size .pio\build\mega2560\firmware.elf
Advanced Memory Usage is available via “PlatformIO Home > Project Inspect”
RAM: [====== ] 60.3% (used 4940 bytes from 8192 bytes)
Flash: [===== ] 53.9% (used 136872 bytes from 253952 bytes)
Building .pio\build\mega2560\firmware.hex
==================================================== [SUCCESS] Took 52.44 seconds ====================================================
Environment Status Duration
mega2560 SUCCESS 00:00:52.440
===================================================== 1 succeeded in 00:00:52.440 =====================================================
Terminal will be reused by tasks, press any key to close it.
ok so I went to the folder Marlin-B1-2.0.9.2.x.pio\build\BIGTREE_SKR_2. this is where my firmwares go usually and renamed to old one and renamed the .elf file too and it compiled and made a whole new set of folders and a new firmware.bin file… maybe try that?
ok, weird so it is a VS code issue. I found the file in the last projects subdirectory I worked on.
Somewhere in VS code it used the source code from the new firmware I downloaded but dumped the hex file in the last version of marlin I was working on… just weird.
ok glad you found it, do you use the"clean" function in between compiling? I’m not sure if that has anything to do with it. and yes VS code was definitely doing some wacky random things yesterday
Hey Glenn
I actually blew away VS and reinstalled it with the same BTT tree of Marlin. After that its started compiling and putting in the right location. The last hiccup I had was it was compiling in hex files which was a new quirk.
I installed a new plugin call “marlin auto builder” it’s actually pretty simple but it looks at the preconfigured file from BTT and makes all the board and processor selections for you. Made the rest of it a breeze. After that, it was compiled in Bin files as it should. Was a bit of a headache but now I have a stable install I can easily modify the firmware as required.
Just as a side note for you, with the SKR 2 board and if you are using a machine with multiple Z lead screws you can set up auto bed levelling with the G34 pretty simply.
Wow. That’s quite the pain. I use something called “autobuild marlin” sounds similar in function to that add on. My printers don’t have dual z although there is a kit to add it.
yes, that’s it, I just checked the name on it.
pretty handy add-on, not sure if it’s new or not?
I have no idea. When I did my first firmware a year ago I followed a teaching tech video and that is the way he was set up so I thought that’s just how everyone does it lol… well this was the first time I had one not compile. You learn more when things screw up than when they don’t
Meh, I look at it as you never learn anything if nothing goes wrong. Plus everyone would be doing it.
It’s what makes us different, we look for problems to solve.
1 Like