Ender3V2S1
Ender3V2S1 copied to clipboard
Voxelab Aquila printers support
Real quick summary: (I'll post more about it later)
there are issues having the firmware flash for G32 and N32 boards. it compiled OK, but sometimes they do not flash well, and get stuck on loading the boot.
the same settings work fine for a Creality 4.2.7 board with CR touch, but issues arise with G32 and N32 Aquila boards and with BL touch.
the BL touch does not work after rebooting / restart printer after initial flash. and sometimes the motors are noisy and loud.
I cannot get the Aquila G32 to load the firmware successfully without major changes, particularly to the Maple ini environment.
for the env:GD32F103RE_aquila
it has -DMCU_STM32F103RE
for build_flags
yet env:GD32F103RE_aquila_maple
has -DMCU_GD32F103RE
in buildroot/share/scripts/proui.py, gd32f10 = _GetMarlinEnv(MarlinEnv, 'MAPLE_STM32F1')
maybe instead of MAPLE_STM32F1
should it be MCU_GD32F103RE
?
and there is no MCU_STM32F1
for stm32f1 = _GetMarlinEnv(MarlinEnv, 'MCU_STM32F1')
instead should this be MCU_STM32F1*
?
so that can be MCU_STM32F103RC or -DMCU_STM32F103RE as defined? @mriscoc
Support for Voxelab Aquila printer is currently experimental, only configuration files for G32 were released. https://github.com/mriscoc/Special_Configurations/releases/tag/Aquila The ini files were recently updated, please test with the latest sources.
ive been able to get the G32 and N32 to work, however, having ProUIex and extra features works fine with Manual Mesh. but does not flash properly with UBL / BLtouch enabled. having a non-maple default-env does not flash properly.
using the maple environment currently works, but the initial flashing results with this.
after restarting, it boots and operates normally. however BLtouch (and clones) have trouble. CR touch works great as expected.
I believe this may have something to do with the stm32f1-maple.ini
file because the current uploaded release. using a previous release .ini with the GD32F103RE_aquila_maple worked instead of the current GD32F103RE_voxelab_maple
and also having aquila.ld
in the board_build.ldscript instead of crealiy.ld worked
Can you check the differences between the ld files? maybe it is related to flash position and bootloader. I post new Aquila versions in the special configurations repository
this file aquila.ld
with this code
MEMORY { ram (rwx) : ORIGIN = 0x20000000, LENGTH = 48K - 40 rom (rx) : ORIGIN = 0x08007000, LENGTH = 512K - 28K }
seems to work fine. technically the G32 chip should be identical to the stm32 like in the ender3v2, however it is not.
rom (rx)
could even be changed to 256K, because I experienced anything larger may not flash.
i recall an older version of the stm32f1-maple.ini
with the chip being name GD32F103RE_aquila_maple
worked, and when it was replaced with GD32F103RE_voxelab_maple
, it did not work.
all i did for the N32 to work was copy the contents of src/HAL/STM32F1/HAL.cpp from @alexqzd source code
i took everything after #ifdef VOXELAB_N32
and put it at the end of the newer file like Alex's.
then add -DVOXELAB_N32
to the stm32f1-maple.ini
[env:N32F103RE_voxelab_maple] extends = GD32F103Rx_aquila_maple board = genericSTM32F103RE build_flags = ${GD32F103Rx_aquila_maple.build_flags} -DMCU_N32F103RE -DVOXELAB_N32
so when you want to compile for the N32, just put N32F103RE_voxelab_maple
in platformio.ini
Thanks, I'll give it a look later
What is the current status of the support for all Voxelab printers, Is it worth it to keep trying the support? Or maybe is better to remove all extra configurations and environment and wait for official support from Marlin.
so far so good, it compiles fine and flashes fine, the G32 and N32 boards are all 256k - STM32F103RC - so the RE is not needed. also now for HC32 chips its possible to compile using PlatformIO thanks to shadow578. I was able to merge the files into my own repo which I have updated to more recent Marlin bugfix
all that is needed for N32 support is adding -DVOXELAB_N32
flag to the stmf1-maple.ini file and the code you can find here in my repo.
HC32 is something that does work, but I am going over the files and testing for now. GD32 support works great, however there has been an issue that I am not sure still remains or if it has been fixed, but some have reported noisy stepper motors. the differences between Alex's firmware source code and what has been changed in the newer Marlin is the ISR_BASE_CYCLES
and related ISR timings in the module/stepper files. it should be experimented more with what values work, if that is the cause at all. it might be worth looking into Alex's files.
I do not think official support will come from Marlin because it so far hasn't even though Voxelab and the Aquila have increasing community and following. maybe if there is more push or messages for Scott at MarlinFirmware to look into it. but for now this firmware works. I will do some testing to see if the noisy stepper motors are an issue anymore, and so far it seems not so.
This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.
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.