[BUG] Cannot compile with BLTouch enabled

[double-brown]

Did you test the latest bugfix-2.1.x code?

No, but I will test it now!

Bug Description

Cannot compile with BLTOUCH enabled. Compiles fine with BLTOUCH and Z_SAFE_HOMING disabled.

compile_error.txt config.zip

Bug Timeline

New

Expected behavior

I expected the firmware to compile.

Actual behavior

The firmware did not compile.

Steps to Reproduce

Compile firmware with given config files

Version of Marlin Firmware

2.1.2

Printer model

Voxelab Aquila X2 H32

Electronics

Stock

Add-ons

BLTouch

Bed Leveling

UBL Bilinear mesh

Your Slicer

Other (explain below)

Host Software

None

Don't forget to include

• [X] A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

No response

[shadow578]

Hi, first off, does the firmware compile (and print) without BLTouch enabled? if not, theres something wrong with your setup...

After that, you could try and rename the H32Servo class in 'https://github.com/shadow578/Marlin-H32/blob/aquila/Marlin/src/HAL/HC32F46x/Servo.cpp' and Servo.h to be libServo and see if that solves the issue. If yes, then i just forgot to change some HAL stuff...

since i don't own a BLTouch, I won't be able to help much with this, especially once the firmware compiles. But i'll look into it on the weekend and try to get it compiling at least.

[double-brown]

Hey,

Yeah it compiled fine without BLTouch, I'm been using that build as my daily driver for a couple days now. I've done several prints, all good on that front.

I did the changes you specified and got success! There was another compile-time error that came up, however from the discussions recently on this reddit thread, enabling BABYSTEP_ZPROBE_OFFSET in Configuration_adv.h got that sorted.

I successfully flashed the printer with the firmware, it took ok. I enabled options for mesh levelling menus, but for some reason the machine is ignoring it's endstops on X and Y. I'm currently troubleshooting that, this might take me a couple days. An issue is that I don't have the USB serial port available after an unfortunate incident involving a RPi and a faulty power adapter :o I may at some stage try soldering in a replacement CH340 or whatever it is.

I've been programming for awhile but new to github, unsure if I should make another bug report about the endstop issue or keep discussing it here.

[classicrocker883]

@double-brown are you also ttbnz? because im the other party in the convo.

anyway there is a thing called ST-Link V2 which is a cheap adapter that is able to communicate with the 3d printer boards using the 4 pin interface next to the display port on the mainboard. it should be labeled RX TX VCC GND. if you may have noticed in the .ini file debug_tool = or upload_protocol = just have that = stlink and you can select PlatformUI: Upload and it should be able to upload the firmware via the st-link v2 tool. aside from that since using platformio: build isn't available for the chip at the moment, it should be possible to use the same tool to communicate with the computer.

im not exactly sure the process, but I believe its possible, maybe even with an Arduino. its definitely interesting to see the printer can be communicated with via this way. cant say for certain, but i think it is.

[double-brown]

@classicrocker883 yip that's me lol.

I've got a ST-Link V2 around here somewhere... I should also have a UART <-> USB adaptor somewhere that should be able to connect to the RX and TX pins on the H32 board. I don't see any reason why it won't work (unless I spiked the serial port hardware on the micro). I'll have a play with it this weekend.

[shadow578]

i've now started to work on this, and the compile issue was caused because the STM32F1 HAL was included instead of the HC32 one.

sadly (or luckily, depending on who you ask), i was also able to reproduce @double-brown issue where the endstops no longer work.

---

Edit: I've narrowed this issue down to HAS_[X|Y|Z]_MIN definitions not beign set when marlin is compiled. for whatever reason marlin decided that the following statement should be true...

#if PB1 == PA5
  #error "PB1 == PA5 ?!"
#endif

Oh well, time to dive into macro hell

[shadow578]

finally managed to find the issue, turns out it was a error in the arduino core implementation (who'd guessed that the c preprocessor does not like enum values :P)

---

@double-brown could you please test the changes at on the pio_bugfix branch? X and Y endstops should work, but i couldn't test Z since i do not own a BLTouch.

the pio_bugfix branch already uses the new (and somewhat unstable) pio buildchain, so if you run into issues building please contact me. I'll either try and fix the pio build or backport to the make buildchain.

also, i'm not quite sure if the servo library works as-is. if you find that the bltouch servo doesn't do anything at all, try and change the following line https://github.com/shadow578/Marlin-H32/blob/6fa6294a634f20027d65af72c2c9bb790ab09f92/Marlin/src/HAL/HC32F46x/Servo.cpp#L202 from stcIrqRegiConf.enIRQn = Int006_IRQn; to stcIrqRegiConf.enIRQn = Int008_IRQn;.

[double-brown]

@shadow578 well done on finding the bug!

I tried that branch, I got a few errors. I fixed a few but then I got a bit lost. This was using the non-pio method:

In file included from src/inc/../HAL/./HC32F46x/HAL.h:35,
                 from src/inc/../HAL/HAL.h:30,
                 from src/inc/MarlinConfig.h:31,
                 from src/MarlinCore.h:24,
                 from src/MarlinCore.cpp:31:
src/inc/../HAL/./HC32F46x/fastio.h:29:10: fatal error: io.h: No such file or directory
   29 | #include "io.h"
      |          ^~~~~~
compilation terminated.

and a bunch of other errors all missing the same io.h file.

I also tried compiling using PIO but it compiled for a mega2560.

[double-brown]

Also I should add github confuses me lol, I tried to push some changes but I don't know if it went through. I can point out any issues I find if it's easier that way.

[shadow578]

@double-brown please follow the new build instructions for the pio-build branch (see https://github.com/shadow578/Marlin-H32/tree/pio_build/bugfix#building).

You have to either:

• adjust the Mainboard entry in Configuration.h (with AutoBuildMarlin), or
• select the HC32F46x_AQUILA_X2 environment (with PlatformIO).

the makefile will not work in those versions, as the arduino core is no longer included. I honestly just forgot to delete the file.

---

if you still have issues with the pio build, it could be really helpful if you attach a screenshot of vscode (especially the pio panel in the bottom left) or even better the overview of AutoBuildMarlin.

---

Edit: attached a screenshot of the AutoBuildMarlin overview panel

[double-brown]

@shadow578 It works, well done! I copied your config files from here, I had to make a few changes to get it to compile. I've attached my configs that I used. BLTouch now works for Z endstop and machine respects X & Y endstops.

configs.zip

[classicrocker883]

in fastio.h it should find the file using this path #include <lib/h32_core/io.h> it seems everything is working fine for you did you leave fastio.h alone and it compiled fine after?

also in Servo.cpp, did changing Int006... to stcIrqRegiConf.enIRQn = Int008_IRQn; help or should it not be changed

[double-brown]

@classicrocker883 Before when I was getting the errors, I was compiling using the "old" make way. Now I've got it compiling in VSCode using AutoMarlinBuild.

[classicrocker883]

hey @double-brown its all great news, so u still getting issues with using the ProUI? in src/lcd/e3v2/proui/dwin_defines.h line ~35 look for #define DASH_REDRAW 1

change it so it looks like

if defined(STM32F1) || defined(STM32F1) || defined(TARGET_HC32F46x)

define DASH_REDRAW 1

endif

also (this may not matter as much but...) in file /proui/dwin.h line ~80

enum tempcontrol_t : uint8_t {

if DWIN_PID_TUNE

PID_DONE, PIDTEMP_START, PIDTEMPBED_START, PID_BAD_HEATER_ID, PID_TEMP_TOO_HIGH, PID_TUNING_TIMEOUT,

endif

remove the ' , ' at the end of PID_TUNING_TIMEOUT ill be posting my updates and tweaks I made and ill let you know so if you wanted to test the proui out, but those two changes may help for now.

and see if that fixes whatever glitch u been having

ill be looking over the files and tweaking so its like the proui in my main repo. however i really dont think all the extra bells and whistles like being able to adjust the bed size and what not is gonna work. i get rom overflow message that the flash is full by quite a few bytes, also some errors with the ProUIex which uses a library that only Mriscoc himself is able to change. for now well stick with what we got and if cant get the proui then jyersui it is. i was looking forward to basically "drag and drop" to make it easy, its just gonna take more time. and unfortunately i dont have an H32 board to test, so as long as it compiles ok, i should be able to test on my G32 for the most part, and it should run the same on the H32.

anyway, being able to compile the h32 in platformio is HUGE, its a milestone in the voxelab community. shadow should be proud for all the work done, this opens new doors to say the least.

[classicrocker883]

i uploaded a test for the ProUI here

if someone can let me know how it is, if there isn't any glitches and what not that happened before. and anything else worthy of note.

[double-brown]

@classicrocker883 It's no good, my machine bootloops. I'll create a bug report in your repo

[classicrocker883]

thanks it's a start at least. so otherwise the platformio; build works? so just JyersUI that runs fine still? it u have any other details I'd appreciate it in a bug report. the thing is I feel like I have to disable so much in the configuration/adv.h files just so it fits onto the Hc32 chip. I would like to think this chips library is "bloated", maybe there is a way to trim out unnecessary code, maybe not... I wouldn't know where to begin.

the good news JyersUI and proui are more similar than creality or Marlinui.

[classicrocker883]

got one more for u @double-brown , haven't been able to enable the gcode_viewer because of some undefined reference to fileprop i cant figure out. but this one should work fingers crossed

edit: when I tested the MM version for G32, the screen was glitchy as in some things didn't show up and some things kinda stayed and didn't 'update'. is that the same issue u had or was it something different?

[double-brown]

@classicrocker883 Sorry I just realised I forgot to make the new bug report in your repo. I'll do this shortly. I've got a video so I can show you what it's doing.

[shadow578]

@shadow578 It works, well done! I copied your config files from here, I had to make a few changes to get it to compile. I've attached my configs that I used. BLTouch now works for Z endstop and machine respects X & Y endstops.

@double-brown what kind of changes did you have to make? was it "only" in the configuration files, or also in the code?

[shadow578]

also, as a more general question: did you encounter issues with the platformio build process? if not, i'd like to quickly merge it into the main branch so the whole repo only uses one build system, i feel like it's gotten kinda confusing having two entirely different systems...

[classicrocker883]

@classicrocker883 Sorry I just realised I forgot to make the new bug report in your repo. I'll do this shortly. I've got a video so I can show you what it's doing.

I saw that it was not exactly loading the screen, I mean it would just wouldn't exactly refresh as everything kinda remained / not load. even though I wasn't able to get the ProUI to work even without any changes made, what I ended up doing what taking Mriscoc's source repo, added all the Hc32f46x stuff, and it worked! I haven't gone into any other kinda testing except show the UI is usable. but after copying over the ProUI code to shadows Hc32 pio_build, that is the result - screen loads but is garbled...technically it should work. next I will see how the ProUIex extra features handles - which requires the special library.

so @shadow578 I will say the platformio build/bugfix works as intended.

one more thing to note, a lot of options in the Configuration.h aren't enabled that would otherwise be for Aquila or Ender-3. even though I used my G32 board the encoder knob wasn't working if things under Encoder Settings like ENCODER_PULSES_PER_STEP were disabled. I wasn't sure if that's the same for the H32 or not.

[double-brown]

@shadow578 My apologies, the one small change I had to make was because I had enabled input shaping. If I disable input shaping it compiles without issue.

I found the AutoBuildMarlin platformIO build method works perfectly for me. Well done on your efforts, I'm stoked I can compile in VSCode now!

[shadow578]

My apologies, the one small change I had to make was because I had enabled input shaping. If I disable input shaping it compiles without issue.

@double-brown what did that change look like, i i might ask? Maybe it could be added to the firmware at some point.

otherwise, i'll merge pio_build/bugfix and close the issue for now.

[double-brown]

@shadow578 Of course. When I enabled input INPUT_SHAPING_X and INPUT_SHAPING_Y, I got

Marlin/src/gcode/feature/input_shaping/M593.cpp: In static member function 'static void GcodeSuite::M593()':
Marlin/src/gcode/feature/input_shaping/M593.cpp:75:91: error: the value of 'CPU_FREQ' is not usable in a constant expression
   75 |     constexpr float min_freq = float(uint32_t(STEPPER_TIMER_RATE) / 2) / shaping_time_t(-2);
      |                                                                                           ^
In file included from Marlin/src/gcode/feature/input_shaping/../../../inc/../HAL/./HC32F46x/../shared/Marduino.h:36,
                 from Marlin/src/gcode/feature/input_shaping/../../../inc/../HAL/./HC32F46x/HAL.h:31,
                 from Marlin/src/gcode/feature/input_shaping/../../../inc/../HAL/HAL.h:30,
                 from Marlin/src/gcode/feature/input_shaping/../../../inc/MarlinConfig.h:31,
                 from Marlin/src/gcode/feature/input_shaping/M593.cpp:23:
/home/ttb/.platformio/packages/framework-arduino-hc32f46x/cores/arduino/Arduino.h:13:21: note: 'uint32_t CPU_FREQ' is not const
   13 |     extern uint32_t CPU_FREQ;
      |                     ^~~~~~~~

So I changed line 75 in M593.cpp to

float min_freq = float(uint32_t(STEPPER_TIMER_RATE) / 2) / shaping_time_t(-2);

got it to compile. I have no idea if there are any other effects caused by making this change.

[classicrocker883]

so i find something odd about the HC32 and BLTouch_HS_MODE. using the most recent bugfix of Marlin, I merged the files from pio_build/bugfix and get this error "BLTOUCH_HS_MODE must now be defined as true or false, indicating the default state."

when BLTOUCH_HS_MODE is defined anything but " 1 " or " 0 ", like "true or false", it throws the error. yet if I select like a normal default_env and MB like for ender 3, the error doesn't show. it seems like the HAL or lib files affect whatever is #defined such as in configuration_adv.h where bltouch_hs_mode is.

so for whatever reason when platformio starts to compile everything, the HC32 stuff may be messing around with BLtouch parameters. I haven't noticed this in the previous version of Marlin, only specifically when src/inc/SanityCheck.h was updated to line ~1900

if HAS_BLTOUCH_HS_MODE

constexpr char hs[] = STRINGIFY(BLTOUCH_HS_MODE); static_assert(!(strcmp(hs, "1") && strcmp(hs, "true") && strcmp(hs, "0") && strcmp(hs, "false")), \ "BLTOUCH_HS_MODE must now be defined as true or false, indicating the default state.");

ifdef BLTOUCH_HS_EXTRA_CLEARANCE

static_assert(BLTOUCH_HS_EXTRA_CLEARANCE > 0, "BLTOUCH_HS_MODE requires a positive BLTOUCH_HS_EXTRA_CLEARANCE.");

endif

endif

just wanted to mention this incase BLtouch issues arise, since it seems as though it doesnt compile as it should if this error pops up only when building for the HC32 using pio_build/bugfix. just merge the files into the newest Marlin bugfix-2.1.x repo.

[shadow578]

@shadow578 Of course. When I enabled input INPUT_SHAPING_X and INPUT_SHAPING_Y, I got

Marlin/src/gcode/feature/input_shaping/M593.cpp: In static member function 'static void GcodeSuite::M593()':
Marlin/src/gcode/feature/input_shaping/M593.cpp:75:91: error: the value of 'CPU_FREQ' is not usable in a constant expression
   75 |     constexpr float min_freq = float(uint32_t(STEPPER_TIMER_RATE) / 2) / shaping_time_t(-2);
      |                                                                                           ^
In file included from Marlin/src/gcode/feature/input_shaping/../../../inc/../HAL/./HC32F46x/../shared/Marduino.h:36,
                 from Marlin/src/gcode/feature/input_shaping/../../../inc/../HAL/./HC32F46x/HAL.h:31,
                 from Marlin/src/gcode/feature/input_shaping/../../../inc/../HAL/HAL.h:30,
                 from Marlin/src/gcode/feature/input_shaping/../../../inc/MarlinConfig.h:31,
                 from Marlin/src/gcode/feature/input_shaping/M593.cpp:23:
/home/ttb/.platformio/packages/framework-arduino-hc32f46x/cores/arduino/Arduino.h:13:21: note: 'uint32_t CPU_FREQ' is not const
   13 |     extern uint32_t CPU_FREQ;
      |                     ^~~~~~~~

So I changed line 75 in M593.cpp to

float min_freq = float(uint32_t(STEPPER_TIMER_RATE) / 2) / shaping_time_t(-2);

got it to compile. I have no idea if there are any other effects caused by making this change.

ok, that is to be expected and caused because on the HC32, the value of F_CPU is only determined after the system boots. One way to solve this is, as you did, to change min_freq to not be a constant.

Alternatively, one could do a experiment to determine the actual cpu frequency and set F_CPU to that fixed value. I've experimented with this in https://github.com/shadow578/Marlin-H32/pull/5, but ultimately stopped to focus on other issues.