MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.15k stars 19.21k forks source link

[QUESTION] [2.0.x] Marlin video - need advice and help on STM32 #14068

Closed Bob-the-Kuhn closed 4 years ago

Bob-the-Kuhn commented 5 years ago

I'm slowly putting together a video on how to install and upload Marlin 2.0.x. I have 90% of the PlatformIO with AVR, LPC1768/9 & DUE/SAM3X8 portion.

I need help and advice on the STM32 portion.

I've stumbled around in there a bit. As best as I can tell:

I need advice in general, pointers to docs/videos, pointers to the latest systems and especially, info on how to do the very first upload to a new unit.

Ideally I'd like to be able to demonstrate & record the setup, compile & upload process for the following. Please let me know if there are others. In a perfect world they would all be the same but I don't think that's the case currently.

I have the following boards to play with. Are there others that I should get?

Bob-the-Kuhn commented 5 years ago

Here's what I know about uploading:

The ST-Link port is not useable for host programs like Repetier Host or Pronterface.

I was able to download a LED blink program to my Nucleo-64 STM32F103RB but no joy. The jumpers are set so that PB13 is driving LED2 and the pins_STM32F1R.h file has #define LED_PIN PB13

Phr3d13 commented 5 years ago

You can try to get your hands on a gtm32 variant. They're not quite 100% working, but are almost usable. I've been flashing with ST's Flash Loader Demo.

Bob-the-Kuhn commented 5 years ago

Ideally the STM32F world would converge on one all inclusive/HAL/system.

Until then I'm hoping that some ST expert puts together a Marlin specific PlatformIO module.

With neither of these we're stuck with a) Try platformIO. If any platform errors go to b) b) Try various libraries with the Arduino IDE. UGLY!!

jmz52 commented 5 years ago

ST-Link is a hardware and is using it's own MCU (STM32F103C8T6) to connect to PC and flash MCU on dev board. Nucleo boards have build-it ST-Link and extra USB connector. This connector is for programming/debugging purposes only and it not connected to main MCU.

Black STM32F407VET6 does not have on-board ST-Link. It can be flashed via COM port or external ST-Link v2 device. You can use ST-Link from Nucleo board to flash black F407 or any other STM32 board with SWD port. Jumpers on nucleo board needs to be removed (or adjusted) to disconnect ST-Link from Nucleo's main MCU.

thisiskeithb commented 5 years ago

Related question: Is U8GLIB compatible with STM32? I was hoping to remap the EXP1/2 pins on an SKR Mini to allow graphical LCDs, but the U8GLIB library is specifically excluded.

jmz52 commented 5 years ago

@thisiskeithb partially compatible. You can use STM32 with RepRap Discount Full Graphics controller, MKS MINI 12864 controller and i2c OLED 128x64 displays on SH1106 or SSH1306.

xC0000005 commented 5 years ago

For the Malyan M200 V1, V2, and V3, and the M300, I'm currently building using the Arduino IDE. These are limited systems with relatively fixed hardware, based on STM32F103 and STM32F070, which only support updating via an SD card/reboot bootloader method.

The Lerdge X, K, and S are much more capable systems, which I also build in the Arduino IDE. Eventually I'd love to get PIO working again, but I'm more interested in keeping my printers running than playing with the tool chain constantly.

RE hals - STM32DUINO is retired (I'm sure someone will fork and continue it eventually, but I don't know who). ST's core has an employee assigned to it, and supports just about every STM processor out there. I'm pretty much only working on the HAL_STM32 at this point, since I only want to support one.

The downsides of the ST arduino core are that STM32DUINO was very stable. It had a ton of libraries ported to it and a ton of investment. @jmz52's support for SDIO, for instance, works perfectly well in STM32DUINO but struggles in ST's core for reasons I haven't gotten to the bottom of. ST's core also uses hardware PWM, which makes determining which timers are available a bit of a chore, since you need to know for a given processor which timers are available, which pins are PWM, which available timers will be consumed by PWM, and thus, which are available for stepper/temperature.

I'd be happy to write up a guide for the malyan M200 systems (and eventually M300 and Lerdge, when I finally get around to creating a PR).

Bob-the-Kuhn commented 5 years ago

J.C. - thanks for all you've done & thanks for the info.

Where does maple fit in?

Please point me to the library(s) you use for Arduino.

Please point me at ST's HAL.

Please provide details on the "SD card/reboot bootloader method". Is it the same as the Smoothie system (looks for fimware.bin, loads it and then renames it) Do all the cards with SD slots support this?


😉

playing with the tool chain constantly

What!??! Your sole purpose in life isn't to make my life easier??!!?? How strange.

xC0000005 commented 5 years ago

Here's the documentation I've been providing people. I've been experimenting with Arduino Portable - creating a single-zip downloadable solution that includes all the weird fixes for the toolchain, etc. Portable is very powerful in terms of being able to have someone prepare an entire environment for someone else, but the download sizes are huge .

MarlinForM200.docx

Bob-the-Kuhn commented 5 years ago

Thanks

Off to play around.

xC0000005 commented 5 years ago

To answer the other questions I totally spaced on: Maple - maple labs built the original libMaple, which would get picked up and mutated eventually into STM32DUINO. It supported STM32F103 and eventually STM32F4x. STM32F7 support was somewhat in and then removed, if I recall correctly. 103 isn't bad, but it isn't any of the value line or low power MCUs (like my good friend the STM32F070 that runs the Malyan M200 V2). So enter STM32GENERIC, which, being HAL based, supports most everything ST did, to a certain level of "supports." STM32GENERIC made some different decisions about how to do timers, but on the plus side, it actually sets the NVIC priority mode to get interrupt priorities to function. STM32GENERIC was cool for being able to work on processors that weren't named STM32F103 or F4 adjacent.

Downside: STM32GENERIC gets basically no support. There's a couple of STM32GENERIC style arduino cores, one of which uses mbed, another that appears to be someone else scratching the "write my own arduino core from scratch," but I'm going to make the rash assumption not many people want to take up an abandoned core that's less functional than STM32GENERIC.

Flash forward: ST MCUs are becoming cheap, and they're powerful little buggers, but the fact that they can do almost anything makes it near impossible to get them to do anything. ST produces their own arduino core, with an employee actually maintaining it.

That core is structured similarly to STM32GENERIC, but I'd say it's acquiring features slowly. THe number of compatible libraries is low, the feature set is not complete (ACD library support and a proper HardwareTImer are the big gaps I see). Both of those are on the plans, and will allow us to re-enable circular collection of temp pins, and switch from the way we define timer intervals to something that resembles a correct implementation.

Why do I say this? because ST's clock config can be changed. The scalars for any particular bus can be reset on the fly, though it's a little bit crazy to do so - my point is that a stable version I don't have to revisit every couple of weeks would take a timer, look at the clock config, and calculate based the timer's desired frequency + the CPU speed + the configured scalars what the period and prescalar should be. For now, we edit the hal timer h.

ST's arduino core: https://github.com/stm32duino/Arduino_Core_STM32 Note that it has its own servo lib - that's what you change to change frequencies.

The bootloader info for M100/M200/M300 is in the doc (note I do not currently support M100 - I have zero idea why the code doesn't just run, and I don't have an M100 mainboard to reverse engineer it. I have code that enables fans by writing straight to GPIO control registers, and it never gets hit.

Bob-the-Kuhn commented 5 years ago

Two steps forward and one step back.

I was able to compile the black STM32F407VE on Arduino and download it via the FLASH Demonstrator utility. I could then talk to Marlin via the USB port using Repetier Host.

The bad news is I can no longer access the bootloader. It'll boot to Marlin if I have BOOT0 at 3.3V and BOOT1 at gnd. Moving BOOT0 to gnd results in no activity that I can find.

I think my mistake was clicking the "jump to user program" option when I did the download. Or was it not clicking it? Don't remember for sure.

I was able to connect it to my J-Link and download a new Marlin image. I had hoped it would give me access to the onboard SD card but ...

Questions/requests:

I'll look at the pin definitions some more to see why Marlin isn't acessing the onboard SD card.

Is the "boot from SD card" bootloader readily available? It would be nice to play with it before I get my MKS Robin.

jmz52 commented 5 years ago

Flash demonstrator uses vendor's bootloader that can't be overwritten, so you did not ruin it. If I recall correctly you need to use 'connect under reset' method - press and hold reset on devboard, click connect button in flash demonstrator then release reset. Boot0 jumper should be set to high, Boot1 - to low.

On-board SD card uses SDIO and it is not supported in HAL_STM32 yet. There is a working code for Lerdge but is it not in main repository yet. Also I do not know if SDIO stability fix was ported to this code.

Marlin's configuration for black 407ve is to use SPI to access SD card on on smart controller (connected to standard EXP1/EXP2 connectors on shield).

Sorry, no 'boot from SD card' bootloader yet.

Please note that there are board definition and configuration files in buildroot/share/PlatformIO/variants/MARLIN_F407VE. PlatformIO uses extra_scripts to ensure that Marlin is compiled with these files. Default configuration for 407ve in Arduino IDE might have different pins functions or timer settings.

Also platformio's extra_scripts handles firmware relocation to use with bootloader and firmware encryption for MKS Robin. These scripts will not work in Arduino IDE, so some manual works required to compile code for 'sd update' for MKS Robin. It is quite doable, I just never did it myself.

Bob-the-Kuhn commented 5 years ago

I'm back FLASHing again.

With BOOT0 tied to 3.3V and boot1 tied to ground it doesn't matter what the reset/next sequence is or the baud rate setting, the RS232 out is silent.

If I set the baud rate to 128K, BOOT0 tied to ground and boot1 to 3.3V then a reset on the board followed by NEXT on the FLASH utility results in success. 115200 is not acceptable. Haven't tried any other baud rates.

With BOOT0 tied to 3.3V and boot1 tied to ground, the board boots to Marlin after a reset.

As I read the documentation the boot0 & boot1 settings are backwards and the chip should be doing autobaud. On the other hand it sure wouldn't be the first time I got things wrong.


To be really kind, the state of the STM32F HAL/toolchain universe is murky. If I had to give a new user advice I'd say "open an issue and hope an expert responds with the current toolchain/library and what is/isn't working."

There's a lot of work ahead for the STM32 experts. Definitely over my pay grade.


firmware encryption for MKS Robin

Interesting.

Any idea why this one (?) board uses it?

How is the decription handled? Is there a hardware device that sits on the bus, is it a feature of the CPU, ....?

ghost commented 5 years ago

Any idea why this one (?) board uses it?

How is the decription handled? Is there a hardware device that sits on the bus, is it a feature of the CPU, ....?

If you were keen enough, due to a bug in the STM32 DFU, you could read out the custom boot loader, disassemble it, and see how the encryption is done.

xC0000005 commented 5 years ago

ST”s read protection 1 and 2 don’t protect against executing firmware reads, just SWDIO/JTAG reads, and RAM is not protected at all, so one of the easiest ways is write a simple reset handler to copy out the bootloader to ram and dump it. That’s what I did to Malyan and (after breaking the encryption) Lerdge.

My opinion is that the average end-user shouldn’t be updating boards via STLINK or debugger. MOST board support a built in bootloader with IAP of some sort (it’s why I took so long to figure out Lerdge’s encryption rather than just reseting and building against the raw hardware). The blackpill/bluepill class boards are an exception - they’re dev units meant to be used by developers who don’t mind doing fiddly things with wires and jumpers. Other than the board in Anycubic’s delta, I can’t think of an ST MCU printer that doesnt’ support some class of in app patching via SD card.

And yes, the tool chain is in transition. That’s why I keep coming back to arduino portable - someone knowledgeable sets up a portable instance, other people just download it and compile.

On May 20, 2019, at 9:57 AM, doggyfan notifications@github.com wrote:

Any idea why this one (?) board uses it?

How is the decription handled? Is there a hardware device that sits on the bus, is it a feature of the CPU, ....?

If you were keen enough, due to a bug in the STM32 DFU, you could read out the custom boot loader, disassemble it, and see how the encryption is done.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/14068?email_source=notifications&email_token=AHVGS4OLXJPTPRKQFTNF7SLPWLKAJA5CNFSM4HN5HMO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVZOJ4Y#issuecomment-494068979, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVGS4KVMRJRWSRR6II66GTPWLKAJANCNFSM4HN5HMOQ.

jmz52 commented 5 years ago

Any idea why this one (?) board uses it?

How is the decription handled? Is there a hardware device that sits on the bus, is it a feature of the CPU, ....?

Firmware encryption is next logical step after not opening fork of GPL firmware. Firmware for MKS Robin v2.x is based on Repetier Firmware, firmware for MKS Robin2 is Marlin-based.

Vendor's bootloader reads encrypted firmware from SD card, decrypts it and flashes MCU with decrypted firmware. MCU is locked, so you can't read decrypted firmware or botloader via ST-Link. Unlocking MCU wipes entire flash including vendor's bootloader. (When compiled in PlatformIO) Marlin encrypts its firmware.bin, so resulting Robin.bin file can be used with original MKS Robin bootloader without need to wipe MCU. You just copy encrypted Marlin to SD card and update MKS Robin like it is done for vendor-provided firmware.

ghost commented 5 years ago

oh yeah, the key's in mks_robin.py along with the simple xor coding. Well I never.

With encryption like that. I hope these cheap chinese companies never enter the encryption marrrket ;)

tpruvot commented 5 years ago

well they are not all encrypted like that... not the alfawise one at least

Bob-the-Kuhn commented 5 years ago

Most definitely having the users upload via the SD card method is the best method. I'm evidence that it's way too easy to screw up with the serial link methods.

I really like the "arduino portable" idea. Maybe a place in GitHub can be found for the recipes and then the users pointed at the repositories.

The encryted binaries definitely make this more complicated. I wonder if custom downloaders can be added to Arduino.

xC0000005 commented 5 years ago

On my machine, I have “Copy to SD” as an option, which copies over the binary with the appropriate name, so it’s absolutely possible. These call scripts/tools, which could do the work.

On May 20, 2019, at 3:19 PM, Bob Kuhn notifications@github.com wrote:

Most definitely having the users upload via the SD card method is the best method. I'm evidence that it's way too easy to screw up with the serial link methods.

I really like the "arduino portable" idea. Maybe a place in GitHub can be found for the recipes and then the users pointed at the repositories.

The encryted binaries definitely make this more complicated. I wonder if custom downloaders can be added to Arduino.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/14068?email_source=notifications&email_token=AHVGS4NYH5VKZWCT6M7HKUTPWMPVRA5CNFSM4HN5HMO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV2HFLA#issuecomment-494170796, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVGS4MRDL32UMGULSKZDP3PWMPVRANCNFSM4HN5HMOQ.

xC0000005 commented 5 years ago

Ah, I remember, I did document this: https://hackaday.io/project/158263-monoprice-mini-marlin-20-support/log/155140-minor-note-uploading-to-sd-card-via-arduino-ide https://hackaday.io/project/158263-monoprice-mini-marlin-20-support/log/155140-minor-note-uploading-to-sd-card-via-arduino-ide

On May 20, 2019, at 3:19 PM, Bob Kuhn notifications@github.com wrote:

Most definitely having the users upload via the SD card method is the best method. I'm evidence that it's way too easy to screw up with the serial link methods.

I really like the "arduino portable" idea. Maybe a place in GitHub can be found for the recipes and then the users pointed at the repositories.

The encryted binaries definitely make this more complicated. I wonder if custom downloaders can be added to Arduino.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/14068?email_source=notifications&email_token=AHVGS4NYH5VKZWCT6M7HKUTPWMPVRA5CNFSM4HN5HMO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV2HFLA#issuecomment-494170796, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVGS4MRDL32UMGULSKZDP3PWMPVRANCNFSM4HN5HMOQ.

Bob-the-Kuhn commented 5 years ago

I had naively assumed that there were RAMPS type boards available for the Nucleo series. Putting Marlin on them is a fun exercise but won't result in a practical printer. It does help understand the tool chains and HALs.

I think I'm going to finish the AVR, LPC1768 & DUE sections of the video while keeping an eye on the STM32 PRs. I'll probably include a few slides on the STM32 printers listing some of the current challenges and basically saying that other videos will go into detail on them. If we have elegant solutions for any of the printers I'll start videos for them.

I'll generate some rough slides and post them here for comments. Hopefully you'll keep me from leading people too far astray.

Bob-the-Kuhn commented 5 years ago

I copied parts of DUE's soft SPI over to HAL_STM32 and HAL_STM32F4. I can now access the onboard SD card from Marlin.

I was surprised to see no composite USB support for the SD card. I take it that the SD card is physically moved between the PC and the controller when doing a firmware update.

xC0000005 commented 5 years ago

Yes, sir. STM32F103 doesn’t even have an SDIO until later revisions. Anything that has SDIO, I’d expect you to use that.

On May 20, 2019, at 8:28 PM, Bob Kuhn notifications@github.com wrote:

I copied parts of DUE's soft SPI over to HAL_STM32 and HAL_STM32F4. I can now access the onboard SD card from Marlin.

I was surprised to see no composite USB support for the SD card. I take it that the SD card is physically moved between the PC and the controller when doing a firmware update.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/14068?email_source=notifications&email_token=AHVGS4LENJCIVPIPINNUVUTPWNT6ZA5CNFSM4HN5HMO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV2US7I#issuecomment-494225789, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVGS4LBM4Y2KESBHYD7RBTPWNT6ZANCNFSM4HN5HMOQ.

Bob-the-Kuhn commented 5 years ago

SDIO is a neat module but soft SPIs are easy and 99% of the users wouldn't notice the performance difference.

If we ever go to a RTOS then we may see some real performance advantages to the average user.

It'll be interesting to see how the onboard SD card is handled when the composite USB is added.

3DSmitty commented 5 years ago

Hello this is very interesting reading. @xC0000005 great job on all your work you have done and the wealth of knowledge! I just got the new Bigtreetech SKR Mini V1.1 that runs a STM32F103RCT6 (https://github.com/bigtreetech/BIGTREETECH-SKR-MINI-V1.1). I recently got it building with Marlin 2.0 in Platformio. Everything seems to work ok except I can't access the internal SD in Marlin. This board is setup to use SPI for the SD. If I enable the SPI pins for some reason it breaks the USB/Serial port and Windows says it can not read the device descriptor and I can not connect to the board. @Bob-the-Kuhn exactly what parts did you copy from the DUE's soft SPI over to HAL_STM32 and HAL_STM32F4?

jmdearras commented 5 years ago

@Bob-the-Kuhn

  • Nucleo-64 STM32F103RB
  • MKS Robin V2.4 STM32F103ZET6
  • black STM21F407VET6
  • Nucleo-144 STM32F746ZG bigtreetech Mini V1.1 I can loan/give you one.
jmdearras commented 5 years ago

the "stock" firmware for the BigTreeTech Mini V1.1 could read the SD card but used an older STM32 library, platform = ststm32@<4.4.0

3DSmitty commented 5 years ago

I tried building the stock source from the Bigtreetech GitHub and still no SD.

jmdearras commented 5 years ago

I tried building the stock source from the Bigtreetech GitHub and still no SD.

I never got it to compile, but it is claimed to be the code that comes on the Mini, and as unboxed, it does read SDCards.

jmz52 commented 5 years ago

@3DSmitty SKR Mini uses pins PB3, PB5 and PB5 in EXP1/EXP2 connectors. These pins can be configured to be SPI3 (primary) or SPI1 (remap). SDSS is PA15. On-board SD card is connected to PA5, PA6 and PA7. These pins are SPI1 (primary), SDSS is PA4. Also for some reason DATA2 is connected to PA3 pin. This pin is not used in SPI communication, but you might need to set it high if there is no onboard pull-up resistor.

How your SPI class is configured - which SPI device and what pins are used?

Edit: PA8 was mentioned instead of PA5. Fixed.

3DSmitty commented 5 years ago

Hello @jmz52 according to https://github.com/bigtreetech/BIGTREETECH-SKR-MINI-V1.1/blob/master/hardware/SKR-mini-V1.1-PIN.pdf the internal SD is PA4, PA5, PA6, and PA7. PA8 is for the extruder heater. Is it wrong? I am using the stable release of ststm32 and the STM32F1 library in Patformio for SPI. Attached is my Marlin patch. In pins_BIGTREE_SKR_MINI_V1.1.h (which came from the original vendor... needs alot of cleaning up) the SPI / SD pins are as follows:

` //#define _SPI1 //if use spi1, plaese Open it or enable spi3

ifdef _SPI1

  #define SDSS               PA4  // SPI1τëçΘÇë

else

  #define SDSS                PA15  // SPI3τëçΘÇë
  //#define DISABLE_DEBUG
  #define DISABLE_JTAG

endif

//#define USB_SD_DISABLED

define USB_SD_ONBOARD // Provide the onboard SD card to the host as a USB mass storage device

//#define LPC_SD_LCD // Marlin uses the SD drive attached to the LCD

define STM32_SD_ONBOARD // Marlin uses the SD drive on the control board

if ENABLED(LPC_SD_LCD)

define SCK_PIN PB3

define MISO_PIN PB4

define MOSI_PIN PB5

define SS_PIN PA15 // Chip select for SD card used by Marlin

define ONBOARD_SD_CS PA4 // Chip select for "System" SD card

elif ENABLED(STM32_SD_ONBOARD)

if ENABLED(USB_SD_ONBOARD)

// When sharing the SD card with a PC we want the menu options to
// mount/unmount the card and refresh it. So we disable card detect.
#define SHARED_SD_CARD
#undef SD_DETECT_PIN           // redefine detect pin onboard tf card
#define SD_DETECT_PIN  PA3

endif

define SCK_PIN PA5

define MISO_PIN PA6

define MOSI_PIN PA7

define SS_PIN PA4 // Chip select for SD card used by Marlin

define ONBOARD_SD_CS PA4 // Chip select for "System" SD card

endif

`

I don't really agree with how they did it.. there are better examples on other board pins files. Anyways I have tried a hundred different combinations and if I enable #define _SPI1 it causes things to fail. Any suggestions, thoughts? Thanks for your time.

bigtreetech_skr_mini_v1.1.patch.log

AletheianAlex commented 5 years ago

Sorry to jump in late, but I was working with stm32 and marlin a few years back, and thought I would throw in a few bits. Sorry if much of this is review. I shelved the project temporarily to wait for everything to mature, and have not had the time to get back into it. There is a hardcoded boot loader (as you have discovered) that you can either access with STLink/serial-to-usb, etc using DFU (which is a bit quirky, but usually worked). The prebuilt stm32duino-included DFU was/is not working properly on my machine, but building the tools from scratch worked. IE

02 STM native bootloader

04 STM native bootloader bootloader pattern

I tinkered around with a few other boot loader options and helped test/patch the stm32duino HID boot loader for F103 chips (which is driverless on the PC side, so that is nice) and was using that to upload via the command line tool over USB, so that may be an option, but stLink/ft232 is required to burn that boot loader initially. Another method I tinkered with was SD card firmware bootloader bootstrapped off the default boot loader, which was OK for bigger chips in the family (as long as it jumped to the right address), but the FAT32 lib took up too much space for the skinnier mcu families (128k and below), so I didn't spend much time on it since I was focusing on blue pill and maple mini, but I had just used a piece of code from an ST example file or data sheet, and I can't dig it up right now.

A quick peek turned up this SD loader for SDIO models, but I have not tried it: https://github.com/DAlexis/stm32-usb-bootloader Looks similar to the smoothie boot loader, which I believe was pulled from Mbed sample code.

The display I got working was char display over i2c (I THINK it was a PCF8574). I submitted the code and link to proper LCD lib to get that working and I THINK it made it's way into marlin way back. I didn't try SPI display, and never got around to checking what was needed for GLCD with the new marlin 2 intermediate u8g lib. SD was working on its own from what I remember, but I had to try several Arduino SD modules before I found one that would behave.

3DSmitty commented 5 years ago

@AletheianAlex Thanks for the great info! I managed to get some bootloaders built easily using STM32Cube. I was trying to create a bootloader that could update the firmware via SD using SPI (The Bigtreetech Mini V1.1 uses SPI for the SD). I wasn't able to get the SPI working the way I wanted though.. The bootloader you mentioned above is pretty much what I was trying to do over SPI instead of SDIO.

xC0000005 commented 5 years ago

@Bob-the-Kuhn , I put together an arduino portable installation that mostly "just works" for compiling for the M200 (if you're building from my branch, or until a few more PRs are in). https://1drv.ms/u/s!AjuNQlXUvQuaq-45AF_Nwk7l9XIhag is for Windows, and is pretty much all-in-one, except for the Marlin source. If you want to give it a run, use the same setting as listed in my build help thread.

DaVincIan commented 4 years ago

Hi Bob

Please if you could look into MKS Robin2 (STM32F407ZE) (Not Robin V2.nn) it would be appreciated.

I added the schematic provided by MKS and a pins file I could piece together.

Robin2 SCH and Pins.zip

boelle commented 4 years ago

@Bob-the-Kuhn still working on this one?

Vertabreak commented 4 years ago

GTM32 boards already run marlin but they need work to be fully functional if you could help out that would be cool.

boelle commented 4 years ago

this one has also served its purpose i think, can reopen if its not the case

github-actions[bot] commented 4 years ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.