USB COM Port Not Persisting on Rumba32 – Possible Bootloader Issue

[samerjawadi]

I am trying to get GRBLHAL running on my Rumba32 board, which uses an STM32F446VETX MCU—the same as the FYSETC S6.

Here’s what I’ve done so far:

• I copied the FYSETC S6 [env] configuration and added HAS_BOOTLOADER=1 since the Rumba32 has a built-in bootloader.
• I tried all the .ld linker scripts. The only one that works for me is: FLEXI_STM32F446RETX_BL_FLASH.ld
• After flashing with this linker script, the board shows up as a COM port and communicates correctly with IO Sender.
• Other linker scripts (STM32F446RETX_BL32K_FLASH, STM32F446RETX_FLASH, STM32F446RETX_NO_BL_FLASH) flash fine but the board does not appear as a COM port.

Problem:

After flashing with FLEXI_STM32F446RETX_BL_FLASH.ld, the board works initially. However, when I reset or power-cycle the board, it no longer appears in Device Manager and the PC makes no connection sound.

Environment configuration used:

[env:fysetc_s6]
board = fysetc_s6
board_build.ldscript = FLEXI_STM32F446RETX_BL_FLASH.ld
build_flags = ${common.build_flags}
-D BOARD_FYSETC_S6=
-D HSE_VALUE=12000000
-D USB_SERIAL_CDC=1
-D HAS_BOOTLOADER=1
lib_deps = ${common.lib_deps}
eeprom
lib_extra_dirs = ${common.lib_extra_dirs}
upload_protocol = dfu

there is onther deffrence between fysetc_s6 and rumba32 : the eeprom
rumba32 : 24LC64T-I/OT -- 64 Kbit (8 KB)
fysetc_s6 : 24LC16BT-I/OT -- 16 Kbit (2 KB)

It seems like the USB is only functional immediately after flashing but fails to enumerate after a reset or power cycle.
I suspect this might be related to the bootloader or how the firmware handles startup and the vector table.

Any guidance on how to ensure the USB COM port persists after reset or power cycle would be greatly appreciated.

[terjeio]

It might be the EEPROM that causes this, at least change #define EEPROM_ENABLE 16 to #define EEPROM_ENABLE 64 in the map file.

Are you using a SD card to flash the board?

If so another option could be to overwrite the bootloader by entering DFU mode and flash a non-bootloader version. You can enter DFU mode from grblHAL via the $DFU command or via this procedure. Or alternatively use a ST-Link programmer.

If not you should flash a non-bootloader version since the inbuilt STM provided bootloaders are in ROM.

[samerjawadi]

So thanks for your suggestions. I’ve checked a few things:

• The EEPROM size on Rumba32 is 64 Kbit (8 KB). I did try changing #define EEPROM_ENABLE 16 → #define EEPROM_ENABLE 64
  but the issue persists. The firmware still does not survive a reset when flashed via PlatformIO.

• ’m not using an SD card for flashing — I’m flashing over DFU mode.

• The problem does not appear to be related to EEPROM or the bootloader itself, but rather to how PlatformIO performs the DFU upload.

What I observed:

DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash "
Downloading element to address = 0x08010000, size = 202908

When flashing the same .bin file with STM32CubeProgrammer, it correctly programs at 0x08000000, and the board works perfectly, even after power cycles.

👉 This strongly suggests the issue lies in PlatformIO’s DFU upload configuration, not the firmware itself.

What I tried:

I switched to the STM32F446RETX_NO_BL_FLASH environment, which has the correct memory map:

MEMORY
{
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 512K - 128K
EEPROM_EMUL(xrw) : ORIGIN = 0x08060000, LENGTH = 128K
}

I also tried adding upload flags in platformio.ini:

upload_flags =
-a 0
-s 0x08000000:leave

But PlatformIO still always writes to 0x08010000.

Conclusion / Fix Needed:

The immediate fix would be to adjust PlatformIO’s DFU upload so it flashes from address 0x08000000 instead of 0x08010000.