[FR] GD32 512k build environment

[kagebarton]

Is your feature request related to a problem? Please describe.

No response

Are you looking for hardware support?

No response

Describe the feature you want

Hey classicrocker883, I'm finally getting around the compiling and working on the Aquila again. Just upgraded my board with an GD32F103RET6 for more flash space (need it for a full TMC2209 UART mode upgrade ).

What do I need to change to enable compiling for 512k?

Thanks!

Additional context - Possible alternatives

No response

[kagebarton]

I think I got it, added a build env in stm32f1-maple.ini, didn't know you also had to edit the comment on the aquila #include in pins.h to get auto build marlin to recognize the build env.

Thanks for keeping the maple code base alive! Seems like mriscoc has decided to drop support.

[kagebarton]

Seems like my 512k builds aren't flashing. This is the build env I put in:

#
# Voxelab (GD32F103RET6)
#
[env:GD32F103RE_voxelab_maple]
extends              = env:STM32F103RE_maple
build_flags          = ${env:STM32F103RC_maple.build_flags} -DTEMP_TIMER_CHAN=4
board_build.address  = 0x08007000
board_build.ldscript = creality.ld
board_build.rename   = firmware-{date}-{time}.bin
extra_scripts        = ${env:STM32F103RC_maple.extra_scripts}
                       buildroot/share/PlatformIO/scripts/custom_board.py
debug_tool           = jlink
upload_protocol      = jlink

I tried building the GD32F103RET6 build of mriscoc's code from March, only non-maple still compiles, and it flashed and works fine for some reason so not sure if I got anything in the build env wrong.

[kagebarton]

BTW, how did you manage to get maple to compile after mriscoc deprecated it?

[classicrocker883]

to keep the maple env I didnt keep up with some of Mriscoc's newer versions. I believe the May/June release was the latest regarding the ProUI library. I copied over whatever I could that didnt break the older(previous) May proui library (where all the untouchable Proui_ex code resides).

I think you can still use the current Mriscoc's version ProUI with a maple env but you have to change a couple things in the files BUT some things may have to be disabled for it to compile correctly. for instance, the proui.py file in buildroot/share/PlatformIO/scripts/
just change it to something like this, so when a GD32 env is detected, it loads the stm32f1 library.

      elif (gd32f10):
         arch = 'stm32f1/'
         print ('GD32F1 Architecture detected')

but you may get some warnings after compiling, I havent tested using with these warnings, but its easy to disable the runout sensor, and same for the Toolbar, you may get a warning about it, but it still may work.

anyway I copied over what I could so its "updated" and also works. it really is unfortunate he dropped support for Maple, because "its deprecated" yet for GD32, probably N32 and HC32 as well, non-maple env firmware doesnt work.

the main difference between the previous May/June version and the current of Mriscoc is he bascially brought some things over to the library so its more untouchable. such as the tramming wizard. another thing is the syntax and the naming of basically all the functions, which is insync with Marlin, so updating is easier in that way.

its whatever, we work with what we got. as long as it works, and theres no real problems.

[classicrocker883]

if you want to compile using 512K GD32 chip, all you have to do is change

board_build.ldscript = aquila512k.ld

or you could also use
Voxelab (N32G455REL7)
and remove -DVOXELAB_N32
or comment it out

#
# Voxelab (N32G455REL7)
#
[env:N32G455RE_voxelab_maple]
extends              = env:STM32F103RE_maple
build_flags          = ${env:STM32F103RE_maple.build_flags} -DTEMP_TIMER_CHAN=4
                       # -DVOXELAB_N32
board_build.address  = 0x08007000
board_build.ldscript = aquila512k.ld
board_build.rename   = firmware-{date}-{time}.bin
extra_scripts        = ${env:STM32F103RE_maple.extra_scripts}
                       buildroot/share/PlatformIO/scripts/custom_board.py
debug_tool           = jlink
upload_protocol      = jlink

im curious as how you upgraded your board with a larger capacity chip?
and also how you got TMC2209 as well

[classicrocker883]

I think I got it, added a build env in stm32f1-maple.ini, didn't know you also had to edit the comment on the aquila #include in pins.h to get auto build marlin to recognize the build env.

I dont use auto build marlin, but what exactly would I need to change so that may be able to help those who do?

[classicrocker883]

you could also just do for default_envs
GD32F303RE_creality_maple

that is the easiest since it requires no other modification.

[kagebarton]

Thanks for the much helpful info! Finally got some testing done with some interesting results. For my F103RE Aquila 1.0.1 board, I first tried the following build env's: GD32F103RET6_sovol_maple and GD32F303RE_creality_maple.

The board wouldn't flash either build (but would delete the bin file), until I fixed creality.ld:

-  rom (rx)  : ORIGIN = 0x08007000, LENGTH = 512K - 64K
+  rom (rx)  : ORIGIN = 0x08007000, LENGTH = 512K - 28K

The rom region might be a typo as all the other previous firmwares say 28k. Now it would flash and boot but would frequently freeze and reset itself as I go through the menus on the LCD.

This is where it gets weird, for fun I built using the non-maple env STM32F103RE_creality, and it flashes and works perfectly fine, no resets (this is all just on my bench power supply though, I haven't hooked everything up to the board).

Not sure if that's just a quirk of the RET6 but if you haven't tried non-maple maybe give it a go?

[kagebarton]

I think I got it, added a build env in stm32f1-maple.ini, didn't know you also had to edit the comment on the aquila #include in pins.h to get auto build marlin to recognize the build env.

I dont use auto build marlin, but what exactly would I need to change so that may be able to help those who do?

Auto build marlin seems to just pick up the comment after the board names in pins.h. So by and large everything you want to build is already listed:

#elif MB(VOXELAB_AQUILA)
  #include "gd32f1/pins_VOXELAB_AQUILA.h"           // GD32F1                               env:GD32F103RET6_sovol_maple env:GD32F103RC_voxelab_maple env:GD32F303RE_creality_maple env:STM32F103RE_creality

The only thing I would suggest is listing only one architecture in the comment as it cleans up the ABM display. Doesn't seem to affect anything as far as building goes as that's all handled by the env's listed in the comment I think.

[kagebarton]

im curious as how you upgraded your board with a larger capacity chip? and also how you got TMC2209 as well

Sourced the chips from china, and used a cheapo hot air station to replace them. The board isn't very big or thick so it didn't need a ton of heat; wasn't overly difficult if you've done some soldering before and took your time.

The bootloader binary and blank chip flashing instructions are here and will require a ST-Link V2 programmer (I used a cheap clone) connecting to the debug port above the LCD connector.

The hardest part was doing the UART mod (here and here) for the 4 drivers, turns out not all free pins can be used for that purpose and only figured out after it didn't boot to flash the revised firmware first to check before soldering.

[github-actions]

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.