Marlin
Marlin copied to clipboard
MarlinFirmware
[FR] (GD32F103 Processor Support)
Is your feature request related to a problem? Please describe.
Some Chinese processor boards have switched to the GD32F103 which is an STM32 clone that is pin compatible and almost identical, but requires firmware changes for a faster clock and currently I am unable to compile successfully for this version of board.
If Creality chooses to go to the GD32 (or other manufacturers), this will be a problem in the future.
Are you looking for hardware support?
GD32F103 Processor Support for Voxelab Aquilla (Ender 3 V2 Clone)
Describe the feature you want
Support for GD32F103 based motherboards.
For info, i have been having the same issue compiling for the GD32F103, specifically the RCT6 version in the same situation as the OP. I have found the solution, the issue is caused by the memory difference from the original STM32F103RET6 that was on these boards. The GD32F103RCT6 has 256kB flash and 48kB RAM vs the STM32F103RET6's 512kB flash and 64kB RAM.
To compile for the GD32F103RCT6 you need to set the ldscript memory as such on the creality.ld set up:
MEMORY { ram (rwx) : ORIGIN = 0x20000000, LENGTH = 48K - 40 rom (rx) : ORIGIN = 0x08007000, LENGTH = 256K - 28K }
Have been able to successfully compile and flash with this.
Bigtreetech has been shipping SKR mini E3 boards using the GD32F103 microcontroller, the change was made without prior notice. https://twitter.com/3dpNero/status/1425121771406204932
Bigtreetech has been shipping SKR mini E3 boards using the GD32F103 microcontroller, the change was made without prior notice. https://twitter.com/3dpNero/status/1425121771406204932
Nero doesn't know what he's talking about. This has been gone over already. No point in spreading false information once again.
Nero doesn't know what he's talking about. This has been gone over already. No point in spreading false information once again.
Not when a person buys 3 boards, all of them have the GD32 microcontroller, ask for replacement, and gets more boards with GD32 microcontroller. Call that whatever you want, it's in the wild and reported by multiple users.
Granted, BTT have released a recall on these boards, because that's a PR nightmare to release a product change without prior notice in such a specialized niche market. That doesn't change the fact that the change was made, is in the wild, and soon many users will start complaining about Marlin not working on their boards.
But, given your defensive attitude of blaming the messenger instead of trying to know what's happening, I should have stayed shut and just wait for the fireworks instead of trying to help. 'No good deeds goes unpunished', indeed. Have a nice day.
I'm very confused by his statement of "Not fully compatible with Klipper". How? I've been running my GD32 Voxelab Aquila with Klipper for MONTHS just fine.
For the sake of completeness, Bigtreetech issued an official statement: https://twitter.com/BigTreeTech/status/1425478829867294722
For the sake of completeness, Bigtreetech issued an official statement: https://twitter.com/BigTreeTech/status/1425478829867294722
Thank you for posting the official statement
Possibly helpful: https://github.com/platformio/platformio-core/issues/3927#issuecomment-888465652
Possibly helpful: platformio/platformio-core#3927 (comment)
I am on the pursuit of gaining information on the GD32 series of microcontrollers specifically the GD32F303RET6. Creality has been sending their newest shipment of Ender 3 Pro 3D printers with this MCU. Honestly, I feel like this task is far beyond my reach. I am not sure how one would use platformio to implement this new environment given the STM32 series environments have been established already.
I believe that Creality3D has posted a GD version of their firmware source code, but at the moment I don't have the link. I'll try to dig it up from my Discord history.
uh so... where are people at with this?
I got one the GD32F303RET6 setups
uh so... where are people at with this?
I got one the GD32F303RET6 setups
+1
Does anyone know where I can download the bugfix-2.0.9.3 release? I want to use H5labs's config files from #23806 but need to configure a couple things.
This Issue Queue is for Marlin bug reports and development-related issues, and we prefer not to handle user-support questions here. (As noted on this page.) For best results getting help with configuration and troubleshooting, please use the following resources:
- Marlin Documentation hosted on MarlinFW.org
- Marlin Forum hosted on RepRap.org
- Marlin Firmware Facebook Group
- Marlin Firmware for 3D Printers Facebook Group
- Marlin Configuration on YouTube
- Marlin Firmware Discord server
For info, i have been having the same issue compiling for the GD32F103, specifically the RCT6 version in the same situation as the OP. I have found the solution, the issue is caused by the memory difference from the original STM32F103RET6 that was on these boards. The GD32F103RCT6 has 256kB flash and 48kB RAM vs the STM32F103RET6's 512kB flash and 64kB RAM.
To compile for the GD32F103RCT6 you need to set the ldscript memory as such on the creality.ld set up:
MEMORY { ram (rwx) : ORIGIN = 0x20000000, LENGTH = 48K - 40 rom (rx) : ORIGIN = 0x08007000, LENGTH = 256K - 28K }Have been able to successfully compile and flash with this.
As far as I can tell, the clock frequency difference between GD32 and STM32 is also significant and causing some timing issues. The difference in cpu frequency is 120MHz vs 72MHz. This may be why there is a lot of salmon skin artifacts on STM builds run on GD boards, when that effect is not noticeable in creality GD board V4.2.2 with GD32F303RET6 and stock 2.0.8.2 FW The difference in cpu frequency is 120MHz vs 72MHz. F_CPU needs to be set to 120000000 and and BOARD_RCC_PLLMUL should be defined to RCC_PLL_MUL15 in boards_setup.cpp, but I don't know what all is needed to get that working the 'right' way. Even just setting F_CPU to 128,000,000 should be closer than 72MHz, and it seems like some work is already in place to make that frequency an option. This is assuming that they are using the GD32F303 CPU at full frequency. There is also the GD32F103 popping up, which is specced to 108MHz. I don't want to kludge anything together until I find a way to revert back to stock Creality firmware, which nobody seems to have a copy of. At least, I can't find a non-BL touch version. It's very frustrating that so many companies like Creality are allowed to sell closed forks of Marlin.
It looks like Creality posted 2 new firmware builds, including one specifically calling out GD chips if someone has a good way to reverse engineer the values out: https://www.crealitycloud.com/software-firmware/firmware?type=2&keyword=&system=0&subType=60067926229435d86f60789a&hardware=0
Binaries are useless, PLL info we can get much easier from GD datasheet. GD 303 chip works fine at it is now, even if not up too full potentioal. It'll be other story if creality publish sources that don't rely on ST libs, now that'll be useful.
Basically Creality is violating the ST license currently, right?
Met vriendelijke groet, Sebastiaan Dammann
Van: EvilGremlin @.> Verzonden: Monday, August 8, 2022 12:22:52 PM Aan: MarlinFirmware/Marlin @.> CC: Sebastiaan Dammann @.>; Comment @.> Onderwerp: Re: [MarlinFirmware/Marlin] [FR] (GD32F103 Processor Support) (#21473)
Binaries are useless, PLL info we can get much easier from GD datasheet. GD 303 chip works fine at it is now, even if not up too full potentioal. It'll be other story if creality publish sources that don't rely on ST libs, now that'll be useful.
— Reply to this email directly, view it on GitHubhttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMarlinFirmware%2FMarlin%2Fissues%2F21473%23issuecomment-1207939246&data=05%7C01%7C%7Ced1b54d674a946a234a008da7927f3b3%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637955509751203860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=nt%2FDdU6Uh9ys64Pz8XkaKfc4w8r6oktbQg5Qw0BA3Gc%3D&reserved=0, or unsubscribehttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAK4FMIAICI7C7O6HFPSB5DVYDNXZANCNFSM4Z6RPD2Q&data=05%7C01%7C%7Ced1b54d674a946a234a008da7927f3b3%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637955509751203860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yMG1gkLjpNhhALBNqKVvKQ8TavWW%2FP%2Fdaix3Qega6po%3D&reserved=0. You are receiving this because you commented.Message ID: @.***>
Not really, ST lib license only state USB part explicitly. But China wouldn't care anyway i think, unless ST will bribe customs.
Maintainer of platform-gd32 and ArduinoCore-GD32 here -- how can we help the efforts? What's the current state? Any people actively working on it?
I believe that Creality3D has posted a GD version of their firmware source code, but at the moment I don't have the link. I'll try to dig it up from my Discord history.
Hm not sure about that, but there's a fork with https://github.com/vovan888/ArduinoCore-GD32/commits/main and there's some commits referencing a "BIGTREE_GD_TFT35_E3_V3_0"... TFT and Ender 3 with GD32?
Their official touch screen repo also uses our platform, but with the SPL framework instead of Arduino.
How can I get a printer that for sure has a GD32 chippy on it?
Any overview on what exact GD32 chips that are around in 3D printer? Just replacements for STM32 (like GD32F20x) or genuinine new GD32 chips that don't have a STM32 counterpart?
What exact functionality do the Marlin devs need from the Arduino core? Note that we already have all the general stuff, like GPIO, Serial, I²C, SPI, PWM, interrupts and even included Gigadevice's BSD 3-clause licensed USB stack (expanded in the "Pluggable USB" style) for a USB CDC on the GD32F30x (e.g. GD32F303CC) series -- that means 0 copyright issues with ST Microelectronics. Plus the code of course makes full use of the maximum frequency of the GD32 chips and doesn't treat them like STM32 chips.
Does it make sense to start adding GD32 support right now with these features implemented?
F103/303 and F407 As of now, only 303 chip works perfectly, so priority need is to patch up 103 and add 407 USB parts aren't really urgent as most (all?) the affected boards still use CH340
As of now, only 303 chip works perfectly,
And with what config is that? Do people use the Maple core with a STM32 chip to compile for a GD32F303 that just happens to work?
F103/303 and F407 As of now, only 303 chip works perfectly, so priority need is to patch up 103 and add 407 USB parts aren't really urgent as most (all?) the affected boards still use CH340
How do we know the GD 303 chip is working perfectly? If it's being clocked down to 72MHz then maybe. But if it's running at 120MHz, there would a clock mismatch that is likely causing problems with peripherals. That's what I was trying to say, before. I've heard of issues with surface artifacts/micro stepping and LCD incompatibility, but I can't try confirming anything until later this weekend.
How can I get a printer that for sure has a GD32 chippy on it?
A GD32F303RET6 is being used in the Creality 4.2.2.2 board currently being shipped inside the Ender 3 Pro B. I got mine at Microcenter and most shipping E3 pros are probably this model, but I have not seen any store pages updated. I can't find a "Ender 3 Pro B" version in any of Creality's official sites, but that's what was on the tiny sticker on the box. You can identify this model because it's power supply is not from MeanWell. It is a lookalike with a larger fan vent. I think Creality used the faster 303 (Cortex M4) over the 103 (M3) because the GD32F103 has significantly less memory than a ST32F103. For the GD32F103 itself, I believe this this the chip used in the AnyCubic Vyper. I don't have a Vyper board to confirm. https://www.anycubic.com/collections/for-vyper/products/motherboard-for-vyper Anycubic's newer Kobra Max (which I do have) uses HC32F460.
My Ender 3v2 from May (not the newest Neo version) has a 303. I can't say for sure if all of them do, but from other posts it seems like the recent builds of Ender 3v2 all have it.
i mean build with standard stm32f103re_creality env works just fine, reportedly, no extra bugs yep forgot HC460 chip, but this one is not by GD, not sure if libs will apply as is
i mean build with standard stm32f103re_creality env works just fine, reportedly, no extra bugs
Yeah and since that is using STM32Duino with STMicro's USB stack, everyone running that on GD32 chips is doing a license violation :/ I see room for improvement there too.
They don't really - because boards don't have native USB. But end user wouldn't care anyway about STs arbitrary whims. So it's exclusively developers problem.
You're right, although USB is by-standard enabled in stm32_common, the linker cleanly throws out all USB code in the final linker stage (I can see that in the .map file), so nothing of them is left in it. At least with the latest Creality\Ender-3 Pro\CrealityV422 config I just tested. That's good to know.
I've run some tests and can confirm that the print quality on the GD ender3 pro is unchanged with custom firmware compared to stock. There is some very minor salmon skin artifacts, but on closer inspection the stock firmware also had this issue. It's not very noticeable, at least not with my board. My attempts to fix the CPU frequency didn't make a difference, but there's a very good chance I did it wrong. I think the 'right' place is some where in the HAL and I couldn't find it. I couldn't think of a good way to step through the code with it running on the board, or to verify if anything changed.
If you are using the STM32F103RE_creality environment, that is using the MARLIN_F103Rx board, and its clock init code would be in https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.1.x/buildroot/share/PlatformIO/variants/MARLIN_F103Rx/variant.cpp#L114-L130. Of course, the extra bits in the PLL register aren't available in the STM32 API, so you would have to do direct register writes to the RCU. 120MHz from HSE + PLL is for reference here.
But that is only half the rent -- the othe side is making the code recognize it now is running on e.g. 120MHz. Deep in the STM32 HAL there is a function (here) that retrieves the current system speed in Hz, which other parts of the code use to calculate the prescalers for timers or baudrate generators etc. Of course it has no idea about additional GD32 PLL capabilities, so it needs to be modified to recognize the correct speed of the MCU. Otherwise things like UART and PWM timers will be very off.