devanlai / dapboot Goto Github PK

I see in winusb.h:

/* Arbitrary, but must be equivalent to the last character in
   the special OS descriptor string */
#define WINUSB_MS_VENDOR_CODE 0x21

But I cannot see where is the OS descriptor string defined; I sed it only being used in winusb.h

    if (req->bRequest != WINUSB_MS_VENDOR_CODE) {
        return USBD_REQ_NEXT_CALLBACK;
    }

but I don't see the actual descriptor anywhere.

Hey,
First thanks for this great utility. Very useful.
I'm using a BluePill board with a 64Kbytes Flash memory.
I've used the last bootloader release (dapboot-v1.11) and i flashed it using serial adapter.
After turning boot0 to zero , i've successfully detect DFU device ( i ve used the dfu-utils commands to check device).
Once a upload the hex file the device freezes and don't run the application or show itself as a DFU device anymore .Once i turn the boot0 to 1 i can identify back the blue pill back at system memory boot.
Using a bin file i can see the application running once , after a sleep time in the application , i loose the bluepill again (no app running or DFU device).
My questions :
1- Is HEX file format handled by the DFU bootloader ?
2- How to switch back and forward between App & Bootloader (without adding a special code in the app ) ?

Regards

I did the following steps:

1. Flash https://github.com/devanlai/dapboot/releases/download/v1.11/highboot-v1.11-stlink-128.bin to my STM32F103 using st-flash
2. Use 'Firmware Download' on https://devanlai.github.io/webdfu/dfu-util/ for my own program
3. Enter bootloader mode from my program (which places the 'BOOT' code in the RTC backup registers)
4. Use the website's 'Firmware Upload' to obtain the firmware.bin file
5. Flash the firmware.bin using st-flash

After the following steps, I cannot enter bootloader mode from my program. I used st-flash read to get the .bin file that is now on the STM32, and it's identical to the firmware.bin file above.

Hello, while I porting DAPBoot on TS100 soldering iron, I discovered this problems:

• When I try to flash large binary, even it is larger then flash size of STM32, it doesn't fail.
• Flashing large enough binary could brick bootloader itself.

To mitigate this problem, I patched DAPBoot like this: eDesignOSS@e3a5a63

Before making PR with this patch, I want to hear some comments about this patch.

Thanks.

One common feature of bootloaders is that they try to leave the MCU's state as they found it, turning off interrupts, resetting clock config, etc.

I've tracked some weirdness I'm seeing in user applications down to dapboot not doing any of that. Is this a conscious choice or just something that hasn't been dealt with yet? I'm not experienced enough with opencm3 to propose a patch :/

Hi Devanlai,

Excellent work on dapboot.

We use chrome on Macos and it works flawlessly and on win10 using zadig.

Recently we used stm32duinos tools (wdi-simple.exe method) on a fresh windows 7 to try and make one bat file install vs. installing and configuring Zadig.

Originally the device shows up as an unknown device on windows.

After running the following command, the device shows up correctly.

wdi-simple.exe --vid 0x1209 --pid 0xdb42 --type XX --name "Test name" --dest "test-dfu"

Type 0:winusb and 1:libusb was tested. Same results.

Download works ok, but at the final stage it hangs and the message says

Error during final DFU download ControlTransferOut failed NetworkError A transfer error has occurred.

In chrome's console on Win7 it says

dfu-util.js:174 Sleeping for 100ms
dfu-util.js:174 Wrote 1024 bytes
dfu-util.js:174 Sent 612 bytes
dfu-util.js:174 Sleeping for 100ms
dfu-util.js:174 Wrote 612 bytes
dfu-util.js:174 Sending empty block  <<hangs here, device does not restart

In chrome's console on Mac it says

dfu-util.js:174 Sleeping for 100ms
dfu-util.js:174 Wrote 1024 bytes
dfu-util.js:174 Sent 612 bytes
dfu-util.js:174 Sleeping for 100ms
dfu-util.js:174 Wrote 612 bytes
dfu-util.js:174 Sending empty block
dfu-util.js:174 Final DFU status: state=7, status=0
dfu-util.js:174 Ignored reset error

Device restarts succesfully on Macos

Any thoughts on what might be going on? Is the bootloader not getting the final message? Is windows not receiving the final DFU status?

Thanks!

On dfu.c, in the STATE_DFU_IDLE we fall through, intentionally. This issues a warning on GCC:

dfu.c: In function 'dfu_control_class_request':
dfu.c:232:40: warning: this statement may fall through [-Wimplicit-fallthrough=]
                     current_dfu_offset = 0;
                     ~~~~~~~~~~~~~~~~~~~^~~
dfu.c:235:17: note: here
                 case STATE_DFU_UPLOAD_IDLE: {
                 ^~~~

GCC has an attribute to inform that this fall through is intentional, __attribute__ ((fallthrough)).

Will push a PR for this.

I've successfully flashed the high memory bootloader into my STM
however im having problem building a Binary for DFU
According to build for bootloader section
Where seems the only step for high memory bootloaders is to build the binary as normal and then upload it via dfu-util
However after the uploade complete, it seems that its not running my program and i've checked the boot1 pin is on low
But when i flash the binary with st-link normally, it works
Any step am i missing? Here i attach the blink led binary.
Thanks
BlinkPC13.zip

Hi, i think this question has to be in the discussions, but discussions are not open for this project.
I tried to flash https://github.com/devanlai/dapboot/releases/download/v1.20/dapboot-v1.20-maplemini.bin into my copy of mapple mini.

OOCD_INTERFACE=interface/stlink-v2.cfg
OOCD_BOARD=target/stm32f1x.cfg

openocd -f $OOCD_INTERFACE -f $OOCD_BOARD \
            -c "init" -c "reset init" \
            -c "stm32f1x unlock 0; reset halt" \
            -c "flash erase_sector 0 0 last" \
            -c "flash write_image erase ${DFU:?DFU is not set} 0x08000000" \
            -c "reset" 

Output

Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 1000 kHz
Info : STLINK V2J29S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.258394
Info : [stm32f1x.cpu] Cortex-M3 r1p1 processor detected
Info : [stm32f1x.cpu] target has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f1x.cpu on 3333
Info : Listening on port 3333 for gdb connections
[stm32f1x.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x20000108 msp: 0x20005000
Info : device id = 0x20036410
Info : flash size = 128 KiB
[stm32f1x.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x20000108 msp: 0x20005000
erased sectors 0 through 127 on flash bank 0 in 0.025608s

Warn : Adding extra erase range, 0x08001a5c .. 0x08001bff
auto erase enabled
wrote 6748 bytes from file /Users/engineer/Downloads/dapboot-v1.20-maplemini.bin in 0.477412s (13.803 KiB/s)

But after flashing when I connect stm32f103 board to the laptop over usb, I don't see any DFU device in lsusb list.
Could you help me with it?

Some hardware, like TS100, has vendor-provided firmware and bootloader pair. That vendor-provided firmware relies on their bootloader do some HW initialization for that firmware.

So, I suggest adding target-specific initialization routine on DAPBoot. It will help when someone wants DAPBoot as alternative bootloader and helps DAPBoot co-exists(boots) their stock firmware without applying hack on their binary builds.

I hacked DAPBoot like this, but I think this patch is much closer to "duct tape" solution rather than elegant one.

eDesignOSS@9966fbd
eDesignOSS@cf8b384

Could you mainline this feature in your (elegant) way?

For my application, we want to inhibit the ability for software to force the bootloader to reboot into programming mode without physical user interaction. To that end, I think I need to override target_get_force_bootloader. By default, that function isn't marked as weak. Is the right change as follows? If so, I'll submit a PR. (Come to think of it, I'll want to do this with target_clock_setup, too)

modified: src/target.h
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
@@ -26,7 +26,7 @@
 extern void target_clock_setup(void);
 extern void target_gpio_setup(void);
 extern const usbd_driver* target_usb_init(void);
-extern bool target_get_force_bootloader(void);
+extern bool target_get_force_bootloader(void)  __attribute__((weak));
 extern void target_get_serial_number(char* dest, size_t max_chars);
 extern size_t target_get_max_firmware_size(void);
 extern void target_log(const char* str);

Currently, if you want to override, for example, APP_BASE_ADDRESS, you have to create another target, as it is not guarded by #ifndef on generic.h file.

Would be nice if we could guard all config defines by #ifndef so we could run as:

make TARGET=STM32F103 LDSCRIPT='../../some.ld' CFLAGS='-DAPP_BASE_ADDRESS=0x08004000'

Which would relocate the app base without a new target or touching the repo. Helps when you have a board with some specificities that don't need to fork the dapboot repo.

generic/config.h would look like:

/*
 * Copyright (c) 2016, Devan Lai
 *
 * Permission to use, copy, modify, and/or distribute this software
 * for any purpose with or without fee is hereby granted, provided
 * that the above copyright notice and this permission notice
 * appear in all copies.
 *
 * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL
 * WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED
 * WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE
 * AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR
 * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
 * NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
 * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 */

#ifndef CONFIG_H_INCLUDED
#define CONFIG_H_INCLUDED

#ifndef APP_BASE_ADDRESS
#define APP_BASE_ADDRESS 0x08002000
#endif
#ifndef FLASH_SIZE_OVERRIDE
#define FLASH_SIZE_OVERRIDE 0x20000
#endif
#ifndef FLASH_PAGE_SIZE
#define FLASH_PAGE_SIZE  1024
#endif
#ifndef DFU_UPLOAD_AVAILABLE
#define DFU_UPLOAD_AVAILABLE 1
#endif
#ifndef DFU_DOWNLOAD_AVAILABLE
#define DFU_DOWNLOAD_AVAILABLE 1
#endif

#ifndef HAVE_LED
#define HAVE_LED 0
#endif

#ifndef HAVE_BUTTON
#define HAVE_BUTTON 0
#endif

#ifndef BUTTON_SAMPLE_DELAY_CYCLES
#define BUTTON_SAMPLE_DELAY_CYCLES 1440000
#endif

#ifndef HAVE_USB_PULLUP_CONTROL
#define HAVE_USB_PULLUP_CONTROL 0
#endif

#endif

If you are OK with it, I'm glad to provide a PR.

I compiled and uploaded the bluepill bootloader to the generic stm32f103c board.
The web page popped up, and I could flash my bin file into the board with no error.
Now, my application wants to see the board as a comport for communication.
What can I do to get the usb uart port to appear?
Any help is appreciated.

Hi, I want to use dapboot for my project. I fail to see a typedef for the usb_bos_descriptor structure and the defines used for this structure are missing too. I have looked in the openlibcm3 projects but nothing there either. Can you please direct me to an openlibcm3 which is working with dapboot? Thank you in advance.

Scantoutvite

Hi,

when playing around with the bootloader, I've stumbled upon the following problem:
When uploading code that was generated using CubeMX on a "Black Pill" board, if I do a blinky example like this:

HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_12);
HAL_Delay(100);

then the LED will remain lit and not flash. If I change the delay to a busy loop like this:

volatile uint32_t i = 900000;
while (i--);

then the LED blinks as expected. I assume this has something to do with HAL relying on the Systick!? Any idea as to what could be causing this?

Although using HSI as USB clock source clearly violates USB spec, some Chinese products are using HSI as their clock source. (I guess they skipping HSE because of their additional BOM cost or layout space.)

Would you mind adding an option allow using HSI as clock source like this patch? eDesignOSS@f3e98dc

Obviously, it needs clear warning sign on that option.

Hello,

would you consider adding PR from your fork of devanlai/libopencm3 to upstream?

It would be helpful to have the usbd_register_extra_string in upstream!

I don't want to add that, since it's your code.

(I thought this is on the main repo, but that's actually a github bug that shows forks wrong. :( libopencm3/libopencm3@90be020 )

In my board, I have a button with a debounce capacitor. The capacitor kind of delay the effective state of the button, so I cannot stay in the bootloader without a delay in the code that reads the button.

I'll submit a PR, will have impact zero on other areas.

Hello

I just want to thank you for this project,

we will be using code from here in bitcoin trezor - https://trezor.io/ , https://github.com/trezor/trezor-mcu

(This is not an issue, just a thanks)

Hi everyone!

I'm developing a HID Joystick with DFU on STM32F103C8T6 (Bluepill), and I have a question...

I'm fighting with some things, the first is the Internal flash of DFU, without this the dfu-util don't upload anything and get a error, but ok, i used "@internal Flash /0x08000000/8*001Kg,56*001Kg" to correct this on USB_INTERFACE_STRING.

After this, i receive this error on try upload my firmware: Error during special command "SET_ADDRESS" get_status

Any possibility to help me about this? Thanks!

I'm strongly leaning toward using dapboot for our new keyboard built around a GD32F303. Based on all available documentation, the GD32F303 is, essentially, a GD32F103, but with a Cortex M4, more flash, and more RAM. And so, in theory, should be pretty straightforward for dapboot to support.

It appears that we'd want GD32F303 support for opencm3. It also appears that https://github.com/nanovna/libopencm3-gd32f3/ has already done that work in their OpenOCD fork. It also looks like upstream rejected a PR to add that implementation.

Before I go off and potentially do something ill-advised, @devanlai, do you have any sage advice?