Spike DFU mode to flash firmware

[dnlschmidt]

I’ve already flashed the firmware on a few Spike Controllers to test various things. Now I’ve received a few new Spike Controllers that already have the latest LEGO firmware installed, but DFU mode is no longer available. So, when I press the Bluetooth button and plug it in, there’s no response. However, I can enter DFU mode via REPL using “machine.bootloader()”. However, the DFU-Util then displays the message “ERASE_PAGE not correctly executed”.
Here is the version:
MicroPython v1.20.0-1742.gf212bbe83 on 2025-03-27; SPIKE Prime with STM32H562!

sys.version
‘3.4.0; MicroPython v1.20.0-1742.gf212bbe83 on 2025-03-27’

Does anyone know about this issue?

[laurensvalk]

There appears to be a new batch of SPIKE Prime hubs with different electronics. See #2659.

We have to make a new firmware for this hub, but it is not ready yet.

[dnlschmidt]

Okay, thanks for the reply. I didn't know there was new hardware available.

[eternogyn2010]

Hi guys. I have a lego spike prime here with a big problem. He burnned the stm32f413. I replaced with a new one but I don't have the firmwares to programm. I created some with repositories from the github on the https://github.com/micropython/micropython
But not worked. With the files that I created the hub turn on with Usb Mass Storage, didn't work with battery and no light.
Someone have this problem?

[laurensvalk]

The version you tried from the MicroPython project isn't very complete. It doesn't have lights or motors/sensors.

You can just restore the original LEGO firmware or install the Pybricks firmware via https://code.pybricks.com/

That will bring back full functionality.

[dlech]

I guess it isn't clear. Did you replace the entire hub or just the STM32F413 chip?

[laurensvalk]

Sorry, I misread. I did not anticipate anyone actually replacing the physical chip. 😮

[eternogyn2010]

Hello. Thanks for the answers. I replaced only the stm32 with a new one. With a good board I tried to read the firmware via stlink but the chip is protected with rdp2. With this protection the stlink can't read the firmware. I tried now to read the good board via dfu utilities and now I have the 2 firmwares, the mboot and the app firmware. But not the first firmware. He is placed in 0x08000000 address. After programmed the new stm32 I created a stub firmware only to jump the address 0x08000000 to 0x08008000. Now the board lights up. Only lego DFU didn't work. But all others functions worked.

[dlech]

Happy to here you got it working.

Everything sounds as expected. Except I thought we could read the bootloader (firmware between 0x0800000 and 0x08007fff) using DFU from a good board. Maybe we read it using MicroPython memory access functions.