[BUG] FLY_D5 does not appear via usbserial after flashing

[oliof]

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

Yes, and the problem still exists.

Bug Description

I am currently trying to build configuration for the FLY D5 board, but it seems that at least with the katapult bootloader in place it does not become available after successfully flashing via dfu mode with the katapult flashtool (see #27580 (comment), but with the addresses adjusted to 0x2000 and 0x08002000 to coincide with the address reported by the katapult flashtool).

SERIAL_PORT is set to -1

Regarding my experimentation with shrinking build size, I tried flashing builds both with -flto and without (foregoing FT_MOTION to get the build fit into available flash).

Bug Timeline

This is my first attempt at building and flashing this board, so it may be new, may be old.

Expected behavior

If the board is reset / reconnected after successul flashing, it should show up as a serial device on /dev/ttyACM0

Actual behavior

Board cannot be seen.

Steps to Reproduce

1. Build with the configs attached and the modified stm32f0.ini also attached
2. Set board to flash mode (hit reset button twice in fast succession()
3. double check that the board is attached

 lsusb | grep stm
Bus 003 Device 077: ID 1d50:6177 OpenMoko, Inc. stm32f072xb

4. Flash using the katapult flashtool (checkout the katapult repo at https://github.com/arksine/katapult)

$ ~/github/katapult/scripts/flashtool.py -d /dev/ttyACM0 -f ~/M-Minion/MarlinFirmware/Marlin/.pio/build/FLY_D5/firmware.bin 
Connecting to Serial Device /dev/ttyACM0, baud 250000
Detected USB device running Katapult
Attempting to connect to bootloader
Katapult Connected
Software Version: ?
Protocol Version: 1.0.0
Block Size: 64 bytes
Application Start: 0x8002000
MCU type: stm32f072xb
Flashing '/home/hwa/M-Minion/MarlinFirmware/Marlin/.pio/build/FLY_D5/firmware.bin'...

[##################################################]

Write complete: 59 pages
Verifying (block count = 1885)...

[##################################################]

Verification Complete: SHA = 07C493BFF8A89FC68E1E727AEC7D21BE89AE0DFB
Programming Complete

5. Fully reset the board by disconnecting and reconnecting the USB cable.

Version of Marlin Firmware

bugfix-2.1.x, commit id 29ad078

Printer model

V-Minion

Electronics

FLY D5

LCD/Controller

None

Other add-ons

None

Bed Leveling

No Bed Leveling

Your Slicer

None

Host Software

Other (explain below)

Don't forget to include

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

Additional information & file uploads

Serial port does not show up in lsusb, so no host software nor a simpe serial terminal can connect.

Zip file contains Configuration*h and the stm32f0.ini adjusted for use with katapult.

d5-noshow.zip

[oliof]

I found the "official" Marlin source by Mellow3D (https://mellow.klipper.cn/en/docs/ProductDoc/MainBoard/fly-d/fly-d5/marlin/ links to a ZIP file on Google Drive, but that is completely broken ... trying to build ends up in

Fly_D5-MARLIN$ pio run -e FLY_D5
Processing FLY_D5 (platform: ststm32; board: marlin_STM32F072; framework: arduino)
-----------------------------------------------------------------------------------------------------------------------------
UnknownBoard: Unknown board ID 'marlin_STM32F072'
Fly_D5-MARLIN$ 

copying the Configuration files from that zip file yields a build, but flashing it via flashtool.py still works. I'll need to find a way to try and run STM32CubeProgrammer -- the Linux stlink package doesn't seem to like flashing to USB directly.

[ellensp]

buildroot/share/PlatformIO/boards/marlin_stm32F072.json has wrong case should be marlin_STM32F072.json
Clearly a windows user made this archive ...

[oliof]

doesn't matter -- using the Configuration files with current bugfix I can do a build, but the board still doesn't come up after flashing with katapults flashtool.py (and dfu-util is stuck on the ERASE step). And to re-iterate, this is without the -flto -fno-move-loop-invariants build options I am discussing elsewhere.

[ellensp]

Give this a try. a new buildroot/share/PlatformIO/variants/MARLIN_FLY_D5/variant_MARLIN_STM32F072.cpp

variant_MARLIN_STM32F072.cpp

I've activated CRS
"The CRS (Clock Recovery System) keeps the HSI48 oscillator synchronized to USB Start-of-Frame (SOF) packets from the host."
"With CRS active, the MCU uses the USB SOF frames (1 kHz) to keep the HSI48 perfectly locked at 48 MHz."

This is just a somewhat educated guess, I don't have hardware to test it

[oliof]

Thank you, I will test that right away. In the meanwhile I gave STM32CubeProgrammer on Linux a try, and it detects the board, then tells the user to turn it off and on again, and then crashes. What it did seem to manage before all that at least once was to disable some write protection. And now dfu-util writes a binary .... slow though. I will report back.

EDIT: Seems to fit this issue: https://community.st.com/t5/stm32cubeprogrammer-mcus/dfu-mode-read-out-protection/td-p/682719 but without the diversion through STM32CubeProgrammer, dfu-util didn't work. Please note that I wasn't able to flash successfully through that (I didn't try using a powered hub though, I just found this issue after)

[oliof]

@ellensp with the unlocked board, marlin comes up with or without your change.

This is not a Marlin bug per se, but the Fly D5 boards just come in a weird default state which probably could be fixed in factory. Something for @Fly3DTeam to consider on future batches of this board or others similar to it.

[oliof]

Now that I have a non-broken computer with a working USB serial, I have had more capacity to test the board. Right now I can reset it once after flashing and it comes up on USB Serial, but not after resets or power cycles after that. Testing the variant file from #28165 (comment) unfortunately brings no improvement.

[oliof]

and before I forget: Main change is that I did put in the PINS for UART Support for the TMC2209s I am using.

Configuration as below. Please be aware that this is a dirty branch with #28187 and some additional local changes applied (to save flash by disabling most shaper algorithms and POLY5/6, which should not have any effect on the serial port bringup).

noserialafterreset.zip