hello,
i want to know how i can modify the build of my program this way, the compiled software is linked to a specific flash address. i try roger´s bootloader, set core to MAPLE and upload method to DFU. the firmware then is buld to set start adress to x08004000. i then connect my board via usb to the pc and enable connection betweend this side and my stm32 board:
https://twisted-electrons.com/update/
iam able to upload the firmware bin (looks like iam able cuz there is a progress bar and info popup)
my code dont work. no test blink sketch is possible. do i need to change something? which bootloader is needed? the small one starting from 0x08002000 and the one from 0x08004000.
there also exist this bootloader from uTasker:
https://www.utasker.com/stm32/BluePill.html
if flashed with this i plug my board via usb to the computer and it is recognized as USB-DISK.
iam then able to put my bin on the board but the flash start adress differs from the uTasker needed ones. so how can i change by build this way i get able to upload a bin via USB-DISK starting my application firmware from 0x08003080 as mentioned on the uTasker website.
i already tried to change some file´s content which seems to be the right place but it doesnt lead me to success. which are the right files i need to change?
i use the real STM32f103CB (128k) mcu on my board, not the bluepill. platform.ini is setup to
maple core and genericSTM32f103CB
do i miss something? any help would be wonderful. thank you
One step at a time. Why use a WebDFU website to upload the firmware and not PlatformIO? In the project tasks and the taskbar you have “upload” available.
You should start by flashing the generic_boot20_pc13.bin to the board via an ST-Link (and e.g. ST-Link utility or STM32CubeProgrammer).
If you plug the board in via USB after having flashed the bootloader, you must get a new USB CDC and a “Maple DFU” device in the windows device manager (if using Windows). Otherwise you haven’t flashed it correctly. See e.g. this topic
Then use a platformio.ini like
[env:genericSTM32F103CB]
platform = ststm32
board = genericSTM32F103CB
framework = arduino
board_build.core = maple
upload_protocol = dfu
with a src\main.cpp code
#include <Arduino.h>
void setup() { pinMode(PC13, OUTPUT); }
void loop() {digitalWrite(PC13, digitalRead(PC13) ^ 1); delay(500); }
for a basic blinky on the builtin PC13 LED. Upload it normally with the “Upload” task.
max, thank you!!
the thing with webDfu is that we want to let customers update their machines firmware without the huzzle of arduino/pio framework. also there is no need of using the arduino framework for updating the device. so we are looking for a solution to let people updating their device easy as possible.
so we need to know where changes need to be made. connection sides everything works like you sayd. burned the bootloader and got maple in device list. so far so good. but how to change the start adress for the USB-DISK method?
if i use upload method dfu and the device is connected and realized by windows device manager, i cant upload from platformio directly cuz pio isnt finding the the dfu device.
The DFU upload with the Maple bootloader requires a reset-into-bootloader-mode by toggling the (virtual) DTR line of the USB CDC port. I don’t believe that website can’t do it – so the device would have to be reset at just the right time to be in DFU mode in the first place.
Well let’s get that fixed first. What do you see the device as in the Windows device manager and what’s the upload error?
device manager says: MAPLE
error message is: cant find device
i have another test firmware from a friend, making the deton8, and using that leads into a full working code after using the web dfu method
Do you see a “Maple Serial” device in the device manager?
I followed the exact procedure I have posted above and I have no problems uploading via DFU.
Checking size .pio\build\genericSTM32F103CB\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM: [== ] 21.1% (used 4312 bytes from 20480 bytes)
Flash: [= ] 14.9% (used 19544 bytes from 131072 bytes)
Building .pio\build\genericSTM32F103CB\firmware.bin
Configuring upload protocol...
AVAILABLE: blackmagic, cmsis-dap, dfu, jlink, serial, stlink
CURRENT: upload_protocol = dfu
Looking for upload port...
Auto-detected: COM3
Uploading .pio\build\genericSTM32F103CB\firmware.bin
maple_loader v0.1
Resetting to bootloader via DTR pulse
Searching for DFU device [1EAF:0003]...
Reset via USB Serial Failed! Did you select the right serial port?
Assuming the board is in perpetual bootloader mode and continuing to attempt dfu programming...
Found it!
Opening USB Device 0x1eaf:0x0003...
Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=2, name="STM32duino bootloader v1.0 Upload to Flash 0x8002000"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0400
bytes_per_hash=390
Starting download: [##################################################] finished!
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
error resetting after download: usb_reset: could not reset device, win error: Ein nicht vorhandenes Gerät wurde angegeben.
Done!
Resetting USB to switch back to runtime mode
======================= [SUCCESS] Took 11.60 seconds =======================
Environment Status Duration
------------------ -------- ------------
genericSTM32F103CB SUCCESS 00:00:11.603
======================== 1 succeeded in 00:00:11.603 ========================
What is the full output of the “Upload” project task execution?
1 Like
i think my problem here is that Maple doesnt show up as Serial device. maybe it caused by zaelog WinUSB driver i did. i will check this out tomorrow and will report back!
could take focus on the other question, were to edit the flash adress configuration for using the USB-DISK method were the program needs to adjust for 0x08003080 ?
In <home folder>./platformio/packages/framework-arduinoststm32-maple/tools/platformio-build-stm32f1.py you can see that the base address (i.e, where the vector table address is) is computed as…
CPPDEFINES=[
# ....
("VECT_TAB_ADDR", get_vector_tab_addr(board_name, upload_protocol))
]
def get_vector_tab_addr(board, upload_protocol):
# Some special cases
boards_8005000 = (
"maple",
"maple_ret6",
"microduino32_flash",
"maple_mini_origin"
)
if any(b == board for b in boards_8005000):
return "0x8005000"
# depending on upload method
if upload_protocol == "dfu":
return "0x8002000"
elif upload_protocol == "hid":
return "0x8001000"
else:
# for other upload methods (including serial)
return "0x8000000"
So by default and by having upload_protocol = dfu selected in the platformio.ini, the firmware is moved to 0x8002000.
To change this default behavior, the documentation shows how, through influencing the VECT_TAB_ADDR build flag / macro value.
Import("env")
# goodbye old one
env.ProcessUnFlags("-DVECT_TAB_ADDR")
# hello new one
env.Append(CPPDEFINES=("VECT_TAB_ADDR", 0x123456789))
So if the above script is saved as e.g. relocate_fw.py and you add
extra_scripts = post:relocate_fw.py
in the project’s platformio.ini, the script will be executed and the vector table address will be changed accordingly.
1 Like
In hindsight you may be able to do a simpler
build_unflags = -DVECT_TAB_ADDR
build_flags = -DVECT_TAB_ADDR=0x123456789
in the platformio.ini (docs) that should have the same effect, but I haven’t tested it.
if i do REBUILD INTELLISEN INDEX the c_cpp_properties file should update the VEXT_TAG_ADDR to the choose adress right? if using this “simple” method. that does not change to my wanted adress. i will try out the longer variant now 
nearby i tried the dfu upload via pio
i flashed the bootloader “generic_boot20_pc13” and in device manager the chip appears as libUSB device. if i then press upload, upload_protocol = dfu, i got errors.
** I NEED TO HELD DOWN RESET on my board, PRESS UPLOAD, and after the compilation i release the reset button which leads into a SUCCESFUL UPLOAD and RUNNING SKETCH **
it works for the first time in my life finally 
but now i want to get a solution working were customers can upload a new firmware a more elegant way as via pio.
Then there’s something wrong with the auto-reset into bootloader functionality. Does it, from thereon, work a second time without holding reset? Does the upload log show that the right COM port is selected which is opened by the board?
i read this topic:
and saw you also needed to un/replug the board to get dfu upload done.
i used Zadig - The Automated Driver Installer and set the driver to libUsb. now the device could get flashed without this reset stuff. bootloader wasnt changed
1 Like