[FR] Add release/configuration for Aquila X3

[gcardoso22]

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

I want to use this firmware with my Aquila X3, but the bed probe doesn't work because it uses an inductive probe.

Are you looking for hardware support?

No response

Describe the feature you want

Add a configuration file for the Aquila X3 or add a new release firmware for this printer.

Additional context - Possible alternatives

No response

[gcardoso22]

Just got an alpha version of the configuration working. Will create a PR as soon as I have time to test it correctly

[classicrocker883]

I made a recent build release using the configurations you suggested.

any updates or if anything else needs changing just let me know

also if you compile your own firmware, please update your repo files.

[gcardoso22]

@classicrocker883 I only had time to test your build now, but it isn't loading. I tested the September branch with the configurations that I had in the PR and it worked. Can you tell me what were the configurations that you used so that I can do a couple more tests?

[classicrocker883]

yes I moved those configurations here configurations/Voxelab Aquila/X3

do you mean to say you tested this build here using this file Aquila-X3_N32_UBL-ProUI.bin?
or what isnt loading?

[gcardoso22]

Yes I tested the build Aquila-X3_N32_UBL-ProUI.bin from here and it isn't loading.

I checked the configuration present at configurations/Voxelab Aquila/X3 and it has all this values enabled

• Configuration.h

  • define G26_MESH_VALIDATION

  • define NOZZLE_CLEAN_FEATURE

  • define HAS_LOCKSCREEN 1

  • define PLR_TUNE_ITEM

  • define CCLOUD_PRINT_SUPPORT

• Configuration_adv.h

  • define POWER_LOSS_RECOVERY

  • define REALTIME_REPORTING_COMMANDS

  • define AUTO_REPORT_POSITION

  • define EXTENDED_CAPABILITIES_REPORT

  • define M114_DETAIL

  • define CANCEL_OBJECTS

and I had them all disabled in my PR. I think that enabling all of these is making the firmware too big fot the printer to handle. Tell mw which ones do you prefer me do add first and see if the firmware loads.

[classicrocker883]

OK, that might be it, I had enabled all those because I had thought the N32 is N32G455REL7, is it not?

otherwise if it is N32F103RC then it definitely cannot fit the extra options which were enabled.

we'd have to disable all those in order for it to fit on 256k

[gcardoso22]

Just realized it it's a 512Kb chip... weird. Gonna try some combinations and see if there's a specific option that breaks the installation and will provide feedback ASAP.

[classicrocker883]

I know it should work. ill reopen this for now.

[gcardoso22]

I tried some option combinations, and independently of the ones I choose, I was unable to upload the firmware when it got to around 230Kb. Any ideas what can be causing this and how can I solve it? Feel free to ask me if you need me to make any tests.

[classicrocker883]

that is odd to say the least

I was unable to upload the firmware when it got to around 230Kb.

so I know 256k chips cannot flash files larger than about 228k, because it is 228k plus the bootloader which is 256k.

but having an N32 with 512k you should technically be able to load that. The only thing I can think of is perhaps Voxelab somehow limited the size from factory.

have you tried changing the .ld in the .ini file?

I mean using N32G455RE_aquila_maple as the default_envs should work at compiling for over 256k.

[gcardoso22]

but having an N32 with 512k you should technically be able to load that. The only thing I can think of is perhaps Voxelab somehow limited the size from factory.

Is there any way that I can check that?

have you tried changing the .ld in the .ini file?

Change to what?

I mean using N32G455RE_aquila_maple as the default_envs should work at compiling for over 256k.

It's this that you are telling ?

If so, it didn't work

When compiling I saw this on the logs So theoretically it's compiling for 512Kb

EDIT: This is my first time using PlatformIO, so I'm still trying to understand how it works

[classicrocker883]

everything in the last comment looks correct

have you tried changing the .ld in the .ini file?

Change to what?

I was referring to this here in ini/stm32f1-maple.ini
board_build.ldscript = aquila512k.ld

but since you are using N32G455RE_voxelab_maple then it is using the 512k, as you confirmed in the log showing Flash and RAM bytes.

Is there any way that I can check that?

to check if Voxelab limited the chip somehow to 256K from factory? not sure how, and who knows the reason why a chip that is supposed to be 512K is acting more like a 256K, I think that firmware .bin files larger than 228kb wont flash for the N32 chip basically confirms that. I only think Voxelab may have done so because how else?
However, we can see if anyone else with an N32 chip can flash firmware meant for 512K, maybe this is a thing for all voxelab's N32 boards.

I believe @oloendithas uses the N32 and will know if it can use 512K firmware.

[oloendithas]

Hi! As I remember, for me the problem was it bootloader rejecting bigger files, while I was able (somehow) to build a file bigger than 228kB. Will the new .ls script affect any bootloader checks?

[gcardoso22]

@oloendithas how can I check if it's the bootloader rejecting the firmware or nor?

[classicrocker883]

here are the differences

creality.ld

{
  ram (rwx) : ORIGIN = 0x20000000, LENGTH = 64K - 40
  rom (rx)  : ORIGIN = 0x08007000, LENGTH = 512K - 64K
}

---

aquila512k.ld

MEMORY
{
  ram (rwx) : ORIGIN = 0x20000000, LENGTH = 128K - 40
  rom (rx)  : ORIGIN = 0x08007000, LENGTH = 512K - 64K
}

and there is a comment saying
(STM32F411RET6 / N32G455REL7) ram is set to 128K, even though it may be technically 144K for N32

differences in ram should not matter.
this isn't too much of an issue not being able to use more memory, but it is odd it should be loading. can this be something to do with the Maple environment?

haven't we already tried using a non-maple default_envs like STM32F103RE_creality, and that did not work?

[gcardoso22]

This is the behavior when I try to upload "big" firmwares

https://github.com/classicrocker883/MRiscoCProUI/assets/1576358/97faa2c5-848a-4477-81da-d8d714d8a2bb

The firmware version stays the same, and the .bin file is removed from the SD Card

[classicrocker883]

it ends at 10 seconds, sorry all I see is it loading normally.

[gcardoso22]

The previous video is what happens when I try to upload a 233KB firmware, and the video below is what happens when I upload a 227KB firmware.

https://github.com/classicrocker883/MRiscoCProUI/assets/1576358/26388fc0-8718-4cba-9a7b-83102910292d

As you can see it takes much longer to start the printer/screen and it shows the message "Starting please wait" before the progress bar.

I uploaded these videos just to help understand what I mean by "Upload not working"

[gcardoso22]

@classicrocker883 don't know if the question about STM32F103RE_creality was for me or for @oloendithas, but I tried to compile for it (added almost every option to get to the 230KB size) and it didn't flash (it stayed for over 5 minutes in the flashing screen) and after I turned off the printer, I had to flash a N32G455RE_voxelab_maple firmware to make it work again.

[oloendithas]

Well, for me, my printer just skips from splash to the menu, ignoring the file. So, the opposite of freezing.

[gcardoso22]

@oloendithas it skips from splash to the menu (for firmware compiled with STM32F103RE_creality) independently if the size is 220KB or 230KB?

[oloendithas]

No-no. It happens when file size iz higher than 228kB. That's why I take it, as bootloader's limit.

[gcardoso22]

But compiled for N32G455RE_voxelab_maple or STM32F103RE_creality?

[oloendithas]

For N32F103RE_voxelab_maple. I suppose, Andrew has removed it from configs, leaving only ...RC.

[classicrocker883]

For N32F103RE_voxelab_maple. I suppose, Andrew has removed it from configs, leaving only ...RC.

I replaced it with N32G455RE_voxelab_maple

N32F103Rxxx chips aren't existent on these boards are they?? all the N32 are N32G455 correct?

[oloendithas]

N32F103Rxxx chips aren't existent on these boards are they?? all the N32 are N32G455 correct?

That's true, the actual model is N32G455. I suspect, those N32F103Rxxx markings exist only for analogy with original STM32 controllers. I didn't know you've renamed it. Thought that you've removed it because the only difference between RC and RE is the flash memory size, and since we can't flash any file larger than 228kB, this config is useless 😳 Thus, I was building for F103RC since than 🤦🏻‍♂️😳

[classicrocker883]

exactly, I had always thought it was F103RC because this stems from Alex's firmware, which is how it was named then.

I think I will close this issue now.
at least we learned some things:

• N32 is N32G455RE on all boards ^{but does not register like other RE boards
  cannot flash like a 512k}
• N32F103RC does not actually exist ^{it is just an easy name to use when building firmware
  (through Github Actions workflow)}
• I may actually just get rid of the N32G455RE_voxelab_maple envs from stm32f1-maple.ini

[github-actions[bot]]

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.