[BUG] Ender-3 V2 Neo with SKR V3 / ProUI not booting

[vrooze]

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

Yes, and the problem still exists.

Bug Description

Any commit since 2024-03-28 will not boot on my system.
They compile fine but when uploaded to the board it takes the firmware via the bootloader, renames it to firmware.cur and noting else happens.

I have bisected from the most recent commit all the way back to 1759429
This is the last commit that works correctly.

I have raised a PR with the specific changes needed in order to get the board working at #27061

Bug Timeline

2024-03-28

Expected behavior

The compiled firmware to boot and work on the board.

Actual behavior

Firmware compiles, but does not boot.

Steps to Reproduce

Apply changes from the PR mentioned in the comments.
Set the board to #define MOTHERBOARD BOARD_BTT_SKR_V3_0_EZ
Compile the STM32H723VG version
Upload to the board

Version of Marlin Firmware

bugfix-2.1.x

Printer model

Creality Ender 3 V2 Neo

Electronics

SKR 3 EZ

LCD/Controller

DACAI

Other add-ons

No response

Bed Leveling

UBL Bilinear mesh

Your Slicer

None

Host Software

OctoPrint

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

Marlin-Configs.zip

[thisiskeithb]

I have bisected from the most recent commit all the way back to 1759429
This is the last commit that works correctly.

That would make 466282f / #26928 the breaking commit.

[ellensp]

Please confirm, is this the board not talking or is it just the display not working so it seems dead. (ie do gcodes over usb to the controller work?)

[vrooze]

Please confirm, is this the board not talking or is it just the display not working so it seems dead. (ie do gcodes over usb to the controller work?)

Hi,

This is the board not working.
The usual boot sequence blinks another LED on the board. This doesn't happen and its not accessible via serial.

I could live with it only being the display not working till its fixed but alas its the whole board :(

[dbombz]

I've encountered this issue as well. I determined that previous functional compilations were done with the environment STM32H743Vx_btt in VScode. Now, that environment is no longer an option in ABM despite being set in platform.io. There are two options for environment now: STM32H743VI_btt and STM32H723VG_btt. Compiling with ABM with either option results in a perpetually loading printer.

If I attempt to compile with the check mark at the bottom of VSC, I get an error stating that 43Vx is incompatible, and I should use one of the other two (see pic).

Flashing with either binary, VI or VG, env results in a non-functional printer. I was able to reflash with my Vx binary and it works. The Vx I am using is 02010201.

[ellensp]

@dbombz

You don't randomly choose an environment. You pick the one that matches the chip on your controller.
You have to look at the chip and read the number off the top, then use that build environment

This is why there are now two options, this board now comes with two different chips a STM32H743VI or a STM32H723VG

So which chip is on your controller?

[ellensp]

PROUI has known startup issue see
#27141

[ellensp]

Tested current bugfix using updated Configs from first post on a STM32H743VI
It will not boot with PROUI enabled, even with patches mentioned in #27141 and #26917
Change it to Marlin UI and it boots fine.

[dbombz]

I have the STM32H743VI. Recompiled, flashed, printed...all good.
Thank you for the enlightenment, and apologies for convoluting OP's issue.

[vrooze]

I'm going to see if mines building for the wrong thing now!
I've got a 723Vx I hadn't noticed they were renamed without the x. Might explain why none of the UI options worked.

Will report back as soon as I can test!

[vrooze]

Update.

Latest bugfix pulled.
Still broken.
Swapped to MarlinUI and this time it did work!

I didn't check if serial comms worked with the first test as (as per) the initial issues when I raised this; No UI option worked and serial was also broken.

Looks like this issue has been semi resolved and is now just an issue with ProUI.

Will leave issue open so I can confirm a fix for as when the ProUI issue is solved, unless of course the powers that be would prefer it closed :)

[thisiskeithb]

Will leave issue open so I can confirm a fix for as when the ProUI issue is solved, unless of course the powers that be would prefer it closed :)

We already have an open bug report for ProUI, so I’m going to close this.

[ellensp]

On this controller its really dead..

changed SERIAL_PORT to 1 and attaching a 3.3v serial to usb adapter (-1 usb can lose data on startup and POSTMORTEM_DEBUGGING should also use this)
I change the display over to LCD_SERIAL_PORT 3 so it didn't doesn't interfere with 1 the TFT port (this is the wifi module UART)

It doesn't say anything, not even a character!

Other GUI's it boots up as expected logging to serial

[ellensp]

Im reopening this.

If I reduce the config to basically just the motherboard and the proui and sdsupport and eeprom and it boots again.

So im fairly sure this is something else

[ellensp]

@rzboril REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER is not a serial device is a SPI device

[ellensp]

@rzboril a Serial tft is the nothing like the e3v2 serial dwin display running proui of this issue.

Serail tfts talk standard gcode and are really just a dedicated control computer with display and touch interface. (and in this case 128x64 mono emulation)

The e3v2 serial dwin display uses its own serial protocol, has it own user interface, and doesn't have touch interface it only has an encoder, and cannot emulate a 128x64. Ie compleatly different.

[github-actions]

Greetings from the Marlin AutoBot!
This issue has had no activity for the last 90 days.
Do you still see this issue with the latest bugfix-2.1.x code?
Please add a reply within 14 days or this issue will be automatically closed.
To keep a confirmed issue open we can also add a "Bug: Confirmed" tag.

Disclaimer: This is an open community project with lots of activity and limited
resources. The main project contributors will do a bug sweep ahead of the next
release, but any skilled member of the community may jump in at any time to fix
this issue. That can take a while depending on our busy lives so please be patient,
and take advantage of other resources such as the MarlinFirmware Discord to help
solve the issue.