dfu/upload not perfectly working

All distros
ag123
Posts: 742
Joined: Thu Jul 21, 2016 4:24 pm

Re: dfu/upload not perfectly working

Post by ag123 » Mon Apr 17, 2017 10:12 pm

hi aster,
is your boot loader the stock bootloader or the stm32duino bootloader?
to tell that you need to run dfu-util -l on the command line
search for that, goto the directory where you installed arduino ide, and run find . -name dfu-util

Code: Select all

find . -name dfu-util
./hardware/Arduino_STM32/tools/linux64/src/dfu-util
./hardware/Arduino_STM32/tools/linux64/dfu-util
./hardware/Arduino_STM32/tools/linux64/dfu-util/dfu-util
./hardware/Arduino_STM32/tools/linux/src/dfu-util
./hardware/Arduino_STM32/tools/linux/dfu-util
./hardware/Arduino_STM32/tools/linux/dfu-util/dfu-util
copy that to a convenient location so that you can run that easily

then set the maple mini in 'perpetual boot loader mode' and run dfu-util -l

if it is the maple (stock) bootloader you would only see 2 options: -alt=0 ram download 0x20000000 and -alt=1 flash memory download 0x08005000
if you see the response in my last post instead i.e. alt=0 ram not allowed, alt=1 flash 0x8005000, alt=2 flash 0x8002000
if it is the stm32duino bootloader ram download is no longer supported
https://github.com/rogerclarkmelbourne/ ... bootloader
hence you can only download that in flash

now to explain a little further u'd need to know a little about the hardware of the stm32f103 soc
ram is at 0x20000000
and flash is at 0x8000000
http://www.st.com/resource/en/reference ... 171190.pdf section 3.3.3 embedded flash page 54 and section 3.4 boot configuration page 59

Code: Select all

boot0=0, boot1=0 - boot from flash i.e. 0x8000000
this means that in the default settings boot0=0 and boot1=0, it would always boot from flash at 0x8000000
you place your program at any other location it is simply not going to run

if you want to use those boot pins (see section 3,4. boot configuration above, the stm32f103 will only allow you to 'boot' or more correctly install/flash/download the sketch/app using uart pins i.e you would need to get an external uart dongle and you need to install a separate program to do just that, download the sketch/app into flash. and that will install the sketch/app at 0x8000000, so that it will run when you set the pins in the default configuration (boot0=0, boot1=0 - boot from flash i.e. 0x8000000

if you don't have a usb-uart or an st-link dongle, you are 'out of luck' you can't install the sketch.

hence the vendor install the maple bootloader in flash (at location 0x8000000), it is this software maple bootloader (the app) that gives you the dfu install and create those fast and slow blinks to give you a response. once you get your st-link you can install/flash your own boot loader, because you would need to flash that at 0x8000000

and for the maple bootloader, it installs your program immediately after it at 0x8005000 and jumps to there and start your sketch
the stm32duino bootloader is an enhanced version of the maple bootloader which used less flash hence it install the sketch at 0x8002000 and jump there to start the sketch

the other alt=n options are actually features created by the maple or stm32duino boot loader which basically install your sketch/app at a different location e.g. ram 0x20000000 and jump there to start your sketch. note that there is actually no *address translation*, you need to specifically compile your sketch/app to work at that address, you do that by selecting the appropriate option in the ide before compiling it and downloading/installing the sketch

tip: the stm32f103 has only got 20k of ram, if you install your sketch there, normally the binary image itself is easily say15k in size, you would be left with 5k for everything else including for things like usb, initialization etc even before it reaches setup() to run your code, if you are lucky you may be able to blink a led say, but for most times, the sketch may just crash since there is no more memory. hence flash in most times is the realistic option, the mcu can run the binary directly from flash and use ram only for the variables/data

aster
Posts: 100
Joined: Thu Mar 30, 2017 2:41 pm
Location: bella italy
Contact:

Re: dfu/upload not perfectly working

Post by aster » Tue Apr 18, 2017 7:56 pm

I have the stm32duino bootloader 2.0. it was my inauguration sketch of the board since it was loaded as first
I already played a little bit with dfu-util, in the last post i wrote you that i wasn't able to upload a .bin using "-a 1" and i was wondering why this address is still there since using the stm32duino booatloader i should be able to upload at 0x8002000 and not 0x8005000

It is not something important it is just a stupid curiosity

zmemw16
Posts: 1421
Joined: Wed Jul 08, 2015 2:09 pm
Location: St Annes, Lancs,UK

Re: dfu/upload not perfectly working

Post by zmemw16 » Tue Apr 18, 2017 11:49 pm

well part A fits the title perfectly

i tend to use only a st-link egg for uploads on the jtag 20w
while trying the various F407 versions (HAL/libmaple) i noticed that the restart doesn't always happen.
then a reset always does, but not sure if an immediate recompile and download always does?

btw
black f4vet v f4zet, notation on the vet schematic says FSMC_A18 for vet, zet is mentioned twice, FSMC_A6 for zet and lcd_bl is only(wag) for zet on FSMC_NE4

stephen

aster
Posts: 100
Joined: Thu Mar 30, 2017 2:41 pm
Location: bella italy
Contact:

Re: dfu/upload not perfectly working

Post by aster » Wed Apr 19, 2017 7:25 am

About the st link, i just saw this topic: http://www.stm32duino.com/viewtopic.php?t=122
I am quite sure that even for the blackpill it would work, and in this way i should have a more powerful programmer than the st link (even if i don t have any idea how to do in-chip debugging, yet)

ag123
Posts: 742
Joined: Thu Jul 21, 2016 4:24 pm

Re: dfu/upload not perfectly working

Post by ag123 » Wed Apr 19, 2017 8:16 am

i think the open sourced Black Magic Probe is something good to try out, i've not tried that myself though, it works somewhat differently compared to the likes of st-link or those openocd ft2232 based jtag/swd dongles

i think the BMP runs a gdb server on the soc itself, which means that probably even things like openocd isn't needed, you can most likely connect to it directly from gdb

in a way the 'status quo debug/flash interfaces' are things like st-link (which is st propriety) and openocd ft2232 jtag/swd. but i'd think we'd not need to keep sticking with the 'status quo', BMP may be a good alternative in that sense. best of all it'd seem it can be flashed on any blue pill or maple mini
(but a small catch is that you may need a uart dongle or st-link firsthand to flash that at 0x8000000)

another way is to use a spare blue pill/maple mini and flash a 'sketch' that basically turns usb-serial to usb-uart :D

just 2 cents

aster
Posts: 100
Joined: Thu Mar 30, 2017 2:41 pm
Location: bella italy
Contact:

Re: dfu/upload not perfectly working

Post by aster » Thu Apr 20, 2017 8:18 pm

But a small catch is that you may need a uart dongle or st-link firsthand to flash that at 0x8000000
I thought i was able to flash the bmp software after the bootloader :?

ag123
Posts: 742
Joined: Thu Jul 21, 2016 4:24 pm

Re: dfu/upload not perfectly working

Post by ag123 » Fri Apr 21, 2017 5:33 am

you can try that though, just that u'd need to build from source and
in your ld scripts, you would need to update the origin for flash so that it would offset away from 0x8000000 leaving room for the bootloader
e.g.

Code: Select all

MEMORY
{
  RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 20K
  FLASH (rx) : ORIGIN = 0x08005000, LENGTH = 108K
...  

Post Reply