Question on compiling for GD32 Voxelab Aquila.

[bstork0807]

Not sure this is the correct place for this but I believe I have tried all options when compiling. I have a Voxelab Aquila G32 and I can take you pre-compiled which works great. I just wanted to tweak some stuff and set it in the firmware so I wouldnt have to fix all the settings after reflashing.. What is your recommendation to do this.. I have VScode setup ready to go..

[classicrocker883]

hey @bstork0807, yes you can use VS code to compile if you know how to do all that you should be good to go.

However some things to take note. The Configuration.h and Configuration_adv.h files directly in the Marlin folder should be replaced with the ones under Configurations. you'll see MM and UBL or default.

Then you may have to change the default_env in the platformio.ini file to your correct chip. just be aware that some tweaks (enabling options) cause the file to be too big and you won't be able to flash it properly.

I'm curious as to what sort of things you'd like changed?

[bstork0807]

I have most of what you said... Copied the Configuration.h and Configuration_adv.h files for ubl.. When it comes to the platformio file I have the GD32 chip and have used your GD32-UBL_ProUI_BLT.bin and it works great.. Any info on how you set the platfirmio.ini and what you pick when you autobuild would be greatly appreciated. As far as what i want to change, at this point want to make a bin file that will configure all my settings so I dont have to go in after the fact. For example extruder esteps..

I don't know if it is possible, could you share your config files along with platformio that I could use to try and compile for the GD32-UBL_ProUI_BLT.bin

[classicrocker883]

STM32F103RC_voxelab_maple_GD32 this is what i put after the default_envs= in platformio.ini personally i dont use the Marlin Auto Build extension. if you want to change the settings with your own just go into the Configuration.h file do ctrl-f and type whatever you'd like to change. my config files are saved in the configurations folder under Andrew427. however that is specifically for the 427 board which if you want the UBL with ProUI, i suggest going into those specific Config files, copy and paste into the main marlin folder, the ones youre looking for have Pro at the end, so copy those but dont forget to remove "Pro". because for the Aquila Boards, they can only hold upto 256k memory, not 512k like the 427. that is why some options or features aren't enabled for the _UBLProUI.

so if youre looking to reenable some things, you would have to disable some other things, or have some features removed from the UI, if that makes any sense. are u good? anything else u need?

[bstork0807]

OK seems to be getting closer and thank you for all your help so far.. For the board I have put in BOARD_VOXELAB_AQUILA and in the platformio I have tried both STM32F103RC_voxelab_maple_GD32 and GD32F103RC_voxelab which resulted in the following.. thinking maybe a config with in vscode.. any ideas would be appreciated.

[bstork0807]

Ignore the previous message.. it turns out the aquila256k.ld script is named aquila_256k.ld in the directory for some reason.. but now that I got past that point I noticed the following error in the output section. I am thinking it has to do with removing the PRO.. how do I do that?

I am now getting this at the end of the compile with the maple

[bstork0807]

Getting closer, I used the Andrew Build and now it is saying not enough space.. What did you disable in order for it to fit for the GD32.

[classicrocker883]

i had disabled several things, not exactly sure which ones but like the nozzle clean, if you Select to Compare the files, the same configuration or configuration_adv files, and Compare with Selected you should be able to see the differences. the thing about the aquila is yeah it wont hold more than 89% of the 256k. i remember seeing that same or similar error, but im not remembering what the cause or fix is.

can you attach your configuration.h and configuration_adv.h files so i can look? or was there any other file you changed (besides the platformio.ini)

[classicrocker883]

ok i recreated the issue by commenting out #define ProUIex 1 in configuration.h line 3191.

that should be enabled. that is the ProUI, if it is disabled, you will have to also disable HAS_GCODE_PREVIEW

[bstork0807]

Attached are the configurations and platformio configs.zip

[Lord-Memester]

I was so close to being done. Then I got this: Some sort of ROM overflow. I truly don't know what to do about that.

[Lord-Memester]

I was successfully able to build it! I cloned the repository, so I'll upload my works as a fork.

[classicrocker883]

the overflow means it is too big, there are somethings you would have to disable, start with the least used like the options under where ProUIex is: the lockscreen, esdiag, ect...

there are a couple other ways to save space like commenting out some things in the dwin.cpp file under src/lcd/e3v2/proui i know that is pretty vague if you dont know much about code, but basically how the UI user interface looks and how the menus are constructed are coded in that specific file. such as being able to view the PID plot graph while printing, that can be commented out to save space, also it has two different ways to view the Mesh grid, you can save space by having just one.

since you have almost 86% meaning u can squeeze 3% more space, there are some things you can go back to enable, but honestly its more trial and error figuring out how much byte size youre adding or taking away. 8600 bytes over can be one or two things, or several small things. so its good to start with disabling the larger ones first, because you can keep the smaller type options, you know the more options youre able to keep the better, so you at least have them.

[Lord-Memester]

Sorry, but what lines would those be in dwin.cpp? Having some trouble finding them.

Edit: Is it lines 267-348?

[bstork0807]

Good evening. Just curious if you were able to compare your files to mine. If you could share your config files that you used to build the gd32 proui bin files I would have no issue building it myself and comparing. Thank you again.

[Lord-Memester]

Good evening. Just curious if you were able to compare your files to mine. If you could share your config files that you used to build the gd32 proui bin files I would have no issue building it myself and comparing. Thank you again.

Do you mean me or @classicrocker883 ? I'll take a look if you'd like.

[bstork0807]

I was asking classicrocker883 but looking for help on what was commented out to save the space.

[classicrocker883]

Sorry, but what lines would those be in dwin.cpp? Having some trouble finding them.

Edit: Is it lines 267-348?

I was thinking more like lines 1626-1664 //Temperature (PID Tuning Graph) Plot During Printing

you'd have to comment out the two menu options under draw_tune_menu PID Plot bed+nozzle

also if you want just one mesh grid viewer, if u want the newer one I think all u have to do is comment out 'MESH_VIEWER' - - that may not be the exact #define but I'll have to look for it.

edit: it's USE_UBL_VIEWER, not sure which folder it's in but if you comment it out then you'll just have the one new mesh viewer. which should save space.

[bstork0807]

Andrew. When you compiled the gd32 version of the bin files did you reduce to 256k or 512k? I heard even though the gd32rct version has 256k it can handle the 512k software

[classicrocker883]

@bstork0807 yes it had to be reduced to 256k, its true these chips should be able to handle 512k as the specs say, however that is not the case when flashing the firmware. for whatever reason, voxelab has probably set a limit on these chips and they cant be compiled to be more than 89% of 256k. you can see for yourself and in platformio.ini set default_envs= it to STM32F103RE_voxelab_maple_GD32 just by changing the C to an E. the reason why I had put GD32 or N32 at the end was so its easier when compiling using the WORKFLOWS actions.

that was initially a problem for me - getting the firmware to flash properly. I didn't realize it had to do with size of the file until after lots of trial and error.

but if youre able to somehow get more memory to work with these chips that would be great. it may have something to do with the bootloader, I think it was something voxelab hard coded in their chips because if the firmware file is too big it could brick the chip, so their thinking is its a safeguard. for that, u may need special STM32 CubeMX software or similar.

anyway, ill take a look at the files if youre still having trouble compiling.

[Lord-Memester]

@bstork0807 yes it had to be reduced to 256k, its true these chips should be able to handle 512k as the specs say, however that is not the case when flashing the firmware. for whatever reason, voxelab has probably set a limit on these chips and they cant be compiled to be more than 89% of 256k. you can see for yourself and in platformio.ini set default_envs= it to STM32F103RE_voxelab_maple_GD32 just by changing the C to an E. the reason why I had put GD32 or N32 at the end was so its easier when compiling using the WORKFLOWS actions.

that was initially a problem for me - getting the firmware to flash properly. I didn't realize it had to do with size of the file until after lots of trial and error.

but if youre able to somehow get more memory to work with these chips that would be great. it may have something to do with the bootloader, I think it was something voxelab hard coded in their chips because if the firmware file is too big it could brick the chip, so their thinking is its a safeguard. for that, u may need special STM32 CubeMX software or similar.

anyway, ill take a look at the files if youre still having trouble compiling.

Should we attempt to contact Voxelab support about this? At least in the past, they've been responsive enough that they might be able to offer an explanation for this.

[bstork0807]

I havent tested as of yet but was able to compile using the non-maple library because it takes up less space.. what is the reason the maple library is used?? Below is the successful compile.

[classicrocker883]

I havent tested as of yet but was able to compile using the non-maple library because it takes up less space.. what is the reason the maple library is used?? Below is the successful compile.

yeah it does use less, because it doesn't use as many libraries. I'm honestly not exactly sure the differences, all I know is the Aquila boards won't flash with non-Maple firmware.

did you try flashing it? and how did it go?

because in my tests I haven't been able to get it to flash properly. so I stuck with the Maple for default_envs

[classicrocker883]

Should we attempt to contact Voxelab support about this? At least in the past, they've been responsive enough that they might be able to offer an explanation for this.

you can try and ask them, you might get an answer. but I doubt it will be one to unlock the chips potential. even so, it may not be worth the hassle. sure go ahead and ask why they limited the chips memory or ram or rom whatever it was. or it could be something with the chips manufacturer. while you're at it, ask why can only Maple environments work for the chip, and if there is a way to use non-Maple. if that makes sense.

I think a good source of knowledge would be Mr Alex alexqzd himself. he was in contact with Voxelab for a while and was able to get all the chips working. I'm sure he would know the answers, but I haven't heard or seen a lot of him around lately...

[bstork0807]

Well figured it out.. looks like it was my mistake the entire time.. The files have not been put in the released folder and that has been where I have been pulling the directories from.. I was able to compile successfully using the Pro files below. I just need to load them on the printer and had a print job running this morning. I will let everyone know how it works. Looks like the following had to be disabled: //#define G26_MESH_VALIDATION //#define EEPROM_CHITCHAT //#define NOZZLE_CLEAN_FEATURE //#define HAS_ESDIAG 1 //#define SET_PROGRESS_MANUALLY //#define POWER_LOSS_RECOVERY

[Lord-Memester]

I actually haven't had much luck compiling for ProUI. If that's what you're going with, please let me know how it goes.

[bstork0807]

So what issues did you have compiling.. just so I know what I am looking for..

[Lord-Memester]

Rom overflow.

[bstork0807]

did you copy the configuration pro.h and configuration_adv pro.h and rename them to configuration.h and configuration_adv.h?

[Lord-Memester]

No, I wanted them to be custom, so I'm just messing about with the normal config files. I suppose comparing the two couldn't hurt.

[bstork0807]

yes.. i was trying to customize as well but if you use those files as starting points it should work for you

[Lord-Memester]

@classicrocker883 I just compiled the firmware with a non-maple build and the output was a file less than 201 KB! I haven't tested it yet, but the file size at least seems promising. I'll edit this comment to let you know how it goes.

It did not work. Not sure why, but I'm going to recompile it with the maple build and use that to see what (if any) difference there is.

So, the difference is that the maple build proceeded past the upload screen. The non-maple build did not, but it appeared to upload something.

I haven't compared the two files bit-to-bit or byte-to-byte, but it might be interesting to see exactly what changes.

[bstork0807]

I was able to do the same just haven't had time to load on the printer as my son is printing parts for school robotics competition.

[Lord-Memester]

I was able to do the same just haven't had time to load on the printer as my son is printing parts for school robotics competition.

Wait, that wouldn't happen to be a FIRST Robotics competition, would it?

[bstork0807]

It is the FRC 2023. Have a practice comp in about a week.

[Lord-Memester]

Ooh, what team number? Depending on where you live, we might end up facing off! (Although, if you'd rather not share it publicly for privacy reasons, I understand.)

[bstork0807]

We are going to SBPLI 1 @Hosfstra and then we will be in Pittsburgh PA

We did go to Houston last year.

Where are you from?

[Lord-Memester]

Far from there. I'm in the Midwest, and it's unlikely my team will make it far enough along in the competitions to meet. Oh well.

[bstork0807]

Did you try and load the new compile?

[Lord-Memester]

Depending who you're asking, I've since edited my comment. I haven't tried loading the new version yet as I've been calibrating input shaping.

[bstork0807]

I was asking you,sorry didn't see that you modified. I compiled with maple and it is working great. I am working on tweaking linear advance.

[Lord-Memester]

I am working on tweaking linear advance.

Oh, do let me know how it goes! I'm wary of going to more extreme measures to figure out the issue, so if it works for you on your (mostly stock) setup, I'd love to know.

[classicrocker883]

I was asking you,sorry didn't see that you modified. I compiled with maple and it is working great. I am working on tweaking linear advance.

for linear advance, I'd like you to know that in src/module/planner.h, you will see line ~200 typedef struct block_t

however in the MarlinFirmware files, it is typedef struct PlannerBlock.

it was at one time changed from block_t to PlannerBlock, but would not compile so I changed it back to block_t. now I don't know if it compiles correctly using the MarlinFirmware source code files, if it is deliberate or a mistake.

that is one of the only changes I had made regarding linear advance, so maybe this is something to look into.

[Lord-Memester]

Interesting. This is the new marlin you recently combined with the previous version, right? I may just go ahead and pull from source.

[classicrocker883]

I combined with the new Marlin under the branch 2023-Feb, haven't tested but it compiled fine. (it has the struct block_t - not PlannerBlock)

[Lord-Memester]

I combined with the new Marlin under the branch 2023-Feb, haven't tested but it compiled fine. (it has the struct block_t - not PlannerBlock)

Let me know when you've tested it, please!

[classicrocker883]

@Lord-Memester are you able to compile your own firmware? because I saw in the newest update to Marlin, I mean the very newest - newer than like a week ago since I last looked through it - there were specific changes to linear advance and to the extruder in the code. I just (on Mar-06) updated the 2023-Feb branch yet again and it compiles fine.

I'm sure this would fix something! I'll post some .bin files probably sometime today. care to share what you use so I'll have that ready first? like the chip/board and UBL, manual mesh, 5x5, 7x7, ect...

[Lord-Memester]

@Lord-Memester are you able to compile your own firmware? because I saw in the newest update to Marlin, I mean the very newest - newer than like a week ago since I last looked through it - there were specific changes to linear advance and to the extruder in the code. I just (on Mar-06) updated the 2023-Feb branch yet again and it compiles fine.

I'm sure this would fix something! I'll post some .bin files probably sometime today. care to share what you use so I'll have that ready first? like the chip/board and UBL, manual mesh, 5x5, 7x7, ect...

@classicrocker883 I can build my own firmware, but I haven't gotten around to it with the new version. I've been swamped with work, and I won't have much of a break until next week. For now, you can look through my fork, though I haven't incorporated the very latest changes into my build. I'll attempt to do that sometime today or tomorrow, but I can't guarantee anything.

[Lord-Memester]

Recent compilation error. I don't want to run ProUI, and this seems to be causing issues.

[classicrocker883]

@Lord-Memester I since fixed this, it should be working fine. Also i posted a couple quick pre releases for testing if you want to check it out.

[Lord-Memester]

@Lord-Memester I since fixed this, it should be working fine. Also i posted a couple quick pre releases for testing if you want to check it out.

I'll see if I have time to try the prereleases. If you're willing, would you specify what files you changed?