DFU driver no more mounting - white led remains on

[vijay-packetp]

I tried to write custom firmware and first time i tried flash using rst button and user button to enter dfu mode worked but flash failed at very beginning. pyboard restart correctly (pyflash is mounted and com port also) but i can no more enter dfu mode... white led remains stuck
Any idea how to solve this ?

sudo dfu-util -D console.dfu
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Match vendor ID from file: 0483
Match product ID from file: df11
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash  "
file contains 1 DFU images
parsing DFU image 1
image for alternate setting 0, (1 elements, total size = 104904)
parsing element 1, address = 0x08000000, size = 104896
Download	[===                      ]  13%        14336 bytesdfu-util: Error during special command "ERASE_PAGE" get_status

Also I tried to execute below one on the console its resetting and entering to white led remains stuck

pyb.bootloader() 

[jimmo]

@vijay-packetp Which pyboard do you have? v1.x or Pyboard-D. The former uses the st bootloader, the latter uses a custom bootloader (mboot) but you can still enter the st bootloader if necessary.

What you're seeing could maybe be explained by a mixup with flashing firmware for the wrong bootloader type.

[vijay-packetp]

@jimmo Thank You for response,
I am using the Pboard D series.
https://store.micropython.org/product/PYBD-SF3-W4F2#image3

To address the issue and to get into DFU mode, I tried the following steps:

1. Connect the BOOT0 pin to VCC(3.3v) and power the device via USB. However, after doing this, there is no detection, and nothing seems to be working, including the Py console not appearing.

2. df utils commands says no DFU mode capable devices detected.

3. Connect the BOOT0 pin to VUSB. read that this boot pin tolerates 5V.

4. Connect the BOOT0 pin to 3.3V and reset the device. This is similar to the first point, and we are experiencing the same issue.

Need help getting back to DFU mode; your suggestions are welcome.

[jimmo]

@vijay-packetp

In DFU mode you won't see the REPL. It's possible that dfu-util won't see it if the udev rules (linux) or driver (windows) aren't configured properly. On linux, try seeing what dmesg says after connection, and lsusb. Windows... I'm not sure sorry.

In lsusb, you will see

Bus 001 Device 027: ID 0483:df11 STMicroelectronics STM Device in DFU Mode

for both mboot and the st bootloader.

But you can use lsusb -v and check the iManufacturer and iProduct. This will be MicroPython / Pyboard DFU for mboot, or STMicroelectronics / STM32 BOOTLOADER for the st bootloader.

However, which USB interface are you using?

The st bootloader only runs on the other (full-speed) USB interface (the one you can access via the WBUS headers, broken out on the WBUS-DIP28 adaptor. Not the one on the pyboard-d itself).

mboot runs on both.

(For more context, the STM32F7 has two USB controllers, one that is FS-only, one that is HS(+FS). The HS-capable one is the one that the board's USB-micro-B connector uses, because it's...well...high speed and that's what most people want. However the st bootloader only runs on the FS-only interface. This is one of many reasons why we have a custom bootloader).

What is console.dfu -- when you say "custom firmware" do you mean unrelated to MicroPython? Initially I thought you meant you had build your own MicroPython firmware, but I'm guessing maybe you're actually compiling something completely unrelated? (In which case you either need to make your custom firmware mboot-aware, or you need to flash it using the st-bootloader on the FS usb interface.

Either way... mboot will refuse to overwrite itself (and would raise exactly the error you're seeing), so I think likely you're in a situation where you have a partially corrupted micropython installation, but hopefully a still-functional mboot installation.

But I'm confused why the hold-down-USR button at startup isn't working to get you back into mboot. What do you see when you hold the button down at power on? Does it do the red-green-blue-white sequence? What happens when you let go at white?

[vijay-packetp]

@jimmo Thank you for taking the time to respond. I have included my reply inline.

In DFU mode you won't see the REPL. It's possible that dfu-util won't see it if the udev rules (linux) or driver (windows) aren't configured properly. On linux, try seeing what dmesg says after connection, and lsusb. Windows... I'm not sure sorry.

Prior to flashing the custom firmware, I could successfully enter DFU mode, and dfu-util identified it correctly in lsusb:

In lsusb, you will see

Indeed, before updating with the custom firmware, it was in DFU mode as indicated in the message above.

for both mboot and the st bootloader.

But you can use lsusb -v and check the iManufacturer and iProduct. This will be MicroPython / Pyboard DFU for mboot, or STMicroelectronics / STM32 BOOTLOADER for the st bootloader.

lsusb -v does not showing any of this

However, which USB interface are you using?

The st bootloader only runs on the other (full-speed) USB interface (the one you can access via the WBUS headers, broken out on the WBUS-DIP28 adaptor. Not the one on the pyboard-d itself).

mboot runs on both.

(For more context, the STM32F7 has two USB controllers, one that is FS-only, one that is HS(+FS). The HS-capable one is the one that the board's USB-micro-B connector uses, because it's...well...high speed and that's what most people want. However the st bootloader only runs on the FS-only interface. This is one of many reasons why we have a custom bootloader).

I suspect this might be the issue; I'm using the USB-micro-B, not the WBUS header.

What is console.dfu -- when you say "custom firmware" do you mean unrelated to MicroPython? Initially I thought you meant you had build your own MicroPython firmware, but I'm guessing maybe you're actually compiling something completely unrelated? (In which case you either need to make your custom firmware mboot-aware, or you need to flash it using the st-bootloader on the FS usb interface.

Yes, it's unrelated to MicroPython, just a demo program for the STM32723 series console..

Either way... mboot will refuse to overwrite itself (and would raise exactly the error you're seeing), so I think likely you're in a situation where you have a partially corrupted micropython installation, but hopefully a still-functional mboot installation.

Ok, but am seeing the REPL and able to execute MP commands.

But I'm confused why the hold-down-USR button at startup isn't working to get you back into mboot. What do you see when you hold the button down at power on? Does it do the red-green-blue-white sequence? What happens when you let go at white?

Yes, holding the button during power-on triggers the red-green-blue-white sequence, but it remains on the white LED without the expected red LED blinking.

[jimmo]

@vijay-packetp I've updated your comment to use the correct reply formatting.

[jimmo]

Ok, but am seeing the REPL and able to execute MP commands.

If you can get to the REPL, can you try executing

>>> import machine
>>> machine.bootloader()

This should put you into mboot. From there you can re-flash the MicroPython firmware, and from MicroPython you can re-flash mboot (e.g. using fwupdate.py).

Yes, it's unrelated to MicroPython, just a demo program for the STM32723 series console..

OK I think you are going to need to break out the other USB interface (or use a different method of accessing the ST bootloader).

Unfortunately for your situation, these boards are designed to run MicroPython, which is why we include a custom bootloader etc. If you want to write custom firmware you can make it work with mboot.

[vijay-packetp]

Ok, but am seeing the REPL and able to execute MP commands.

If you can get to the REPL, can you try executing

>>> import machine
>>> machine.bootloader()

I did
pyb.bootloader()
but it remains on the white immediately LED without the expected red LED blinking.
I will try machine.bootloader() and update you.

This should put you into mboot. From there you can re-flash the MicroPython firmware, and from MicroPython you can re-flash mboot (e.g. using fwupdate.py).

Yes, it's unrelated to MicroPython, just a demo program for the STM32723 series console..

OK I think you are going to need to break out the other USB interface (or use a different method of accessing the ST bootloader).

Unfortunately for your situation, these boards are designed to run MicroPython, which is why we include a custom bootloader etc. If you want to write custom firmware you can make it work with mboot.

[vijay-packetp]

@jimmo
it remains on the white immediately LED without the expected red LED blinking.
after below commands

>>> import machine
>>> machine.bootloader()

[jimmo]

I don't completely understand this because mboot isn't supposed to be able to overwrite itself, but I suspect your best bet is to attempt to re-install mboot. Normally you'd do this via the st bootloader, but you can also do this from MicroPython using fwupdate.py

$ cd ports/stm32/mboot
$ make -j BOARD=PYBD_SF3
$ gzip build-PYBD_SF3/firmware.dfu
$ mpremote fs cp fwupdate.py build-PYBD_SF3/firmware.dfu.gz :
$ mpremote
>>> import fwupdate
>>> fwupdate.update_mboot('firmware.dfu.gz')

[jimmo]

@vijay-packetp Edit! Updated the above snippet, make sure you use update_mboot, not update_mpy like I first had.

[jimmo]

The output should look like this:

>>> import fwupdate
>>> fwupdate.update_mboot('firmware.dfu.gz')
Loading file firmware.dfu.gz
Found Mboot data with size 23760.
Programming Mboot, do not turn off!
New Mboot programmed.
Verification of new Mboot succeeded.
Programming finished, can now reset or turn off.

If you see an error about deflate, then grab an older copy of fwupdate.py, e.g. the v1.20.0 version here: https://github.com/micropython/micropython/blob/v1.20.0/ports/stm32/mboot/fwupdate.py

[vijay-packetp]

The output should look like this:

>>> import fwupdate
>>> fwupdate.update_mboot('firmware.dfu.gz')
Loading file firmware.dfu.gz
Found Mboot data with size 23760.
Programming Mboot, do not turn off!
New Mboot programmed.
Verification of new Mboot succeeded.
Programming finished, can now reset or turn off.

If you see an error about deflate, then grab an older copy of fwupdate.py, e.g. the v1.20.0 version here: https://github.com/micropython/micropython/blob/v1.20.0/ports/stm32/mboot/fwupdate.py

Many thanks for the provided solution! It was very helpful, above commands were successful and mboot updated

>>> fwupdate.update_mboot('firmware.dfu.gz')
Loading file firmware.dfu.gz
Found Mboot data with size 23944.
Programming Mboot, do not turn off!
New Mboot programmed.
Verification of new Mboot succeeded.
Programming finished, can now reset or turn off.

able to go for DFU mode,

Bus 001 Device 015: ID 0483:df11 STMicroelectronics STM Device in DFU Mode

How do I go about flashing my custom firmware now, using only the WBUS-DIP28 adaptor? Additionally, considering your mention that mboot cannot overwrite itself, is this a specific issue with PYBD_SF3?

[jimmo]

How do I go about flashing my custom firmware now, using only the WBUS-DIP28 adaptor?

If you have a WBUS-DIP28 then you just flash it like any other st board. Use the BOOT0 pin (which is a button on the DIP28 adaptor) and flash to the st bootloader via the FS usb port on the DIP28.

Additionally, considering your mention that mboot cannot overwrite itself, is this a specific issue with PYBD_SF3?

No this is by design. (I suspect you have a version of mboot prior to the bug fix in #10059 which is why it was able to be partially overwritten).

It shouldn't be too hard to make your custom firmware work with mboot though, you just need it to start at an offset of 32kiB.

[vijay-packetp]

@jimmo as suggested I tried to generate the DFU with following python command

python dfu.py -b 0x08008000:console-STM32F723.bin -D 0x0483:0xdf11 console-STM32F723.dfu

its DFU dump is below

File: "console-STM32F723.dfu"
DfuSe v1, image size: 106261, targets: 1
Target 0, alt setting: 0, name: "ST...", size: 105976, elements: 1
  0, address: 0x08008000, size: 105968
    DUMPED IMAGE TO "console-STM32F723.dfu.target0.image0.bin"
usb: 0483:df11, device: 0x0000, dfu: 0x011a, UFD, 16, 0x17f44a06
 

after this I flashed using

sudo dfu-util -D console-STM32F723.dfu

dfu-util 0.11

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Match vendor ID from file: 0483
Match product ID from file: df11
Multiple alternate interfaces for DfuSe file
Opening DFU capable USB device...
Device ID 0483:df11
Device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
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  "
File contains 1 DFU images
Parsing DFU image 1
Target name: ST...
Image for alternate setting 0, (1 elements, total size = 105976)
Setting Alternate Interface #0 ...
Parsing element 1, address = 0x08008000, size = 105968
Erase   	[=========================] 100%       105968 bytes
Erase    done.
Download	[=========================] 100%       105968 bytes
Download done.
Done parsing DfuSe file

(As the flashing is done, get the board out of DFU mode). I did following,

Hold down USR button and press the RESET button
The RGB LED flashes red, green, blue, white
Release the USR button as soon as the RGB LED flashes red, to come out of DFU mode.
Now here instead of  the RGB LED stop blinking  it is on Solid Red remain on and am not sure custom firmware us running or not
Could you please suggest if anything am missing here

[jimmo]

@vijay-packetp How have you configured your linker script? Does the code know that it's running with the correct offset? (Also things like configuring the interrupt vector table etc).

I'ts not enough to just flash the code to the desired location, the code has to know where it is.

[vijay-packetp]

Hi @jimmo

Thank you for your response, Yes I adjusted the ld file to 0x8008000 and flashed it onto the board. Subsequently, there was no response from the board; no LED lights were blinking. I attempted to enter DFU mode again by holding down the USR button and pressing the RESET button, but this time, DFU mode was not detected "