dfu format for firmware

[picpic020960]

Bonjour , I have convert your HEX to bin then to dfu , load with stm32-uart-dfu (*) to the chip ... but not works. Is it possible to obtain DFU format of firmware ? ( with DFU from 'mcauser' github it is ok ...but micropython v1.17) (the load address is to complex for me and dfuse-pack.py extracts address from DFU file)

thank's for help

(*) USB-DFU not reliable , WeAct board

[nspsck]

Now I've uploaded the .dfu file.

I have convert your HEX to bin then to dfu , load with stm32-uart-dfu (*) to the chip ... but not works.

The reason that did not work is because the .bin file should be splited into 2 files, one starts with the address at 0x8000000 and the other starts at 0x08030000. So if you were simply doing a conversion, the firmware won't work.

(*) USB-DFU not reliable , WeAct board

Have you purchased it at the official WeAct Studio store? You can find it here. The official ones are quiete reliable. Make sure you hold down Boot0 button during the boot/reset process for at least 0.5 sec.

[picpic020960]

Thank's erase all in chip. extracts 2 bin files from dfu and load with good address : success. but when reset , the alone blue led always light and no MSC popup. nothing on lsusb with USB cable and no /dev/ttyACM0. nothing in dmesg -T

`$ dfu-util -l 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/

Found DFU: [0483:df11] ver=2200, devnum=32, cfg=1, intf=0, path="1-1.1.2", alt=3, name="@Device Feature/0xFFFF0000/01004 e", serial="209C34875031" Found DFU: [0483:df11] ver=2200, devnum=32, cfg=1, intf=0, path="1-1.1.2", alt=2, name="@OTP Memory /0x1FFF7800/01512 e,01016 e", serial="209C34875031" Found DFU: [0483:df11] ver=2200, devnum=32, cfg=1, intf=0, path="1-1.1.2", alt=1, name="@Option Bytes /0x1FFFC000/01016 e", serial="209C34875031" Found DFU: [0483:df11] ver=2200, devnum=32, cfg=1, intf=0, path="1-1.1.2", alt=0, name="@Internal Flash /0x08000000/04016Kg,01064Kg,03*128Kg", serial="209C34875031" `

[nspsck]

The fact that the blue light lit up is a good thing. It is probably looking for a flash section but could not find it.

extracts 2 bin files from dfu and load with good address : success.

Could you please try:

sudo dfu-util --alt 0 -D firmware.dfu

[picpic020960]

sudo dfu-util --alt 0 -D nspsck.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 = dfuERROR, status = 10 dfuERROR, clearing status 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, (2 elements, total size = 307256) parsing element 1, address = 0x08000000, size = 408 Download [=========================] 100% 408 bytes Download done. parsing element 2, address = 0x08030000, size = 306832 Download [=========================] 100% 306832 bytes Download done. done parsing DfuSe file

but not better ! NB : dfu-util works fine ( 25 ° C is good for blackpill - cristal calibration accuracy)

[nspsck]

Hi, first of all, are you sure that you got the 8MB version which has a spi flash unit soldered on the back?

image for alternate setting 0, (2 elements, total size = 307256)

This size implies that you are using the 8MB version. And total size = 306744 is for the regular version.

EDIT: never mind, I am experiencing the same issue with the 8MB version board, let me check it out.

[nspsck]

@picpic020960 Now it should work.

EDIT: Now the LED issue is also resolved. It should no longer light up once finished booting.

[picpic020960]

Thanks I test this evenning

edit : thank's @nspsck

MicroPython v1.22.0-preview.54.g95d8b5fd5.dirty on 2023-10-23; WeAct Studio Blackpill v3.1 8MB with STM32F411CE Type "help()" for more information.

question : is mboot in the firmware ? dfu-util is unusable and mboot should be workarround .

[nspsck]

question : is mboot in the firmware ? dfu-util is unusable and mboot should be workarround .

The mboot is not in the firmware. Could you pleas give more hints about why you think that dfu-util is unusable, or which part of the tool does not function as intended?

mboot is mainly used for MCUs with only few KB of flash storage, it is probably a waste of internal flash that STM32F411CE provides.

[picpic020960]

at end of dfu-util :

sudo dfu-util --a 0 -D Downloads/'firmware (4).dfu' dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc. .... Device returned transfer size 2048 DfuSe interface name: "Internal Flash " file contains 1 DFU images parsing DFU image 1 image for alternate setting 0, (2 elements, total size = 307568) parsing element 1, address = 0x08000000, size = 408 Download [ ] 0% 0 bytesdfu-util: dfuse_download: libusb_control_transfer returned -9

with google , issue with cristal calibration accuracy with USB/DFU engine , componant on the WeAct board. And it is not possible to patch the DFU engine and calibration. Some time it's OK , some time KO. this after noon OK , this evenning KO. Other message with pydfu.py , KO.

my host is Raspberry pi.

with luck , firmware is now stable.

[nspsck]

Most likely you have a clone board. The original WeAct boards are pretty steady. You might want to check out on your supplier.

The only official store is here: https://de.aliexpress.com/item/1005001456186625.html

Maybe you can also get a original board from EC Buying, but I would not trust those. Especially, it's even sold cheaper in the officiao store.

EDIT: The above statements only holds true if you have purchased your board on AliExpress recently. Since back then, the problem as you described, was actually there.

[davefes]

To get into dfu-util try A10 to ground instead of connecting A9 to A10. Seems to work better on my old cloned boards.

[picpic020960]

hi @davefes , to get to dfu-util -l is OK , but -D KO ; start and then error above. thank's @nspsck , I will make with.

[davefes]

EDIT: Now the LED issue is also resolved. It should no longer light up once finished booting.

With the newest non-8M version and on a cloned-board it does stay on during program execution but goes out during deepsleep.

I noticed that turning PC13 on and off makes no difference. I will have some real BlackPill modules in 2 days.

[nspsck]

Hi,

If you were accessing files/data on the flash during your program, it's normal to have the LED(1) (C13) lighting up.

The C13 is the only LED we had, so if we want some debug (of the firmware itself) /booting/factory reset informations, we have to assigned it as MICROPY_HW_LED1. And you can not start with MICROPY_HW_LED2 since the whole led.c is with the following structure:

#if defined(MICROPY_HW_LED1)
/* Code */
#else 
/* Code */
#endif

So if you do not define MICROPY_HW_LED1, the entire LED module will not be present.

Here are 2 examples on how to work around this.

1. Do not define MICROPY_HW_LED1 at all and use Pin class to modify the LED. Note that Pin.on() will probably turn the led off and Pin.off() will probably turn the led on. Since the LED is pulled up.
2. Define 'MICROPY_HW_LED1' to another Pin that you would never access, e.g. PA13, PA14, these are used for SWD-debuging interface and define MICROPY_HW_LED2 with C13 and use LED(2) for controlling the LED.

Both way requires no additional leds but it also cost you a indicator.

You can also just plug in a LED on the breadboard and control it using Pin class. Probably the most pleasant way to fix the problem if you have some leds laying around.

[davefes]

Thank you for clarifying the low-level LED operation. So, the blue LED once booting has finished, can flash during program execution. Is it indicating flash access?

I have noticed that since I have got micropython-lib/micropython/lora running on the cloned-BlackPills that the blue LED does not flash.

[nspsck]

So, the blue LED once booting has finished, can flash during program execution. Is it indicating flash access?

Yes.

I have noticed that since I have got micropython-lib/micropython/lora running on the cloned-BlackPills that the blue LED does not flash.

Could you please share the link to the lib and a snipe of your code that contains the part where you want to flash the led?

[davefes]

To clarify ... I do not want to use the blue LED, I am only noticing that on some programs it does flash or stay on and on some it doesn't.

I will have some real BlackPill boards tomorrow and once I get the simple_rxtx.py example at https://github.com/micropython/micropython-lib/tree/master/micropython/lora running I will come back if I am still concerned about this behaviour.

[nspsck]

ok cool!

[davefes]

Probably worth mentioning that even with the WeACT boards A10 to ground seems more reliable. Also, tell people to use mpremote :)