STM32F4 upload questions

Hello guys!

I have few questions about STM32 and Arduino IDE. Before anything else I want to apologize if my questions are stupid but I just want to make sure whether I get it right or not.
I have two boards – with STM32F103RB (Olimexino-STM32) and with STM32F407ZG (STM32-E407).

For the STM32F1 board I follow these instructions and I managed to make it work. I uploaded the bootloader. After that in Arduino IDE I selected board: “Generic STm32F103R series”; variant: “STm32F103RB”; upload method: “STM32duino bootloader”. Then I unplugged the the board, started compiling and uploading, then plugged the USB again and the uploading started. I tried this with blinking LED and button scanning. Everything works fine. So far so good.

But before I go any further I decided to try the same with STM32F4 board. Which unfortunately wasn’t so easy. I red a little bit around the forum and I found these topics: STM32F4 boards – limited support and Creating a Bootloader for generic boards. Where basically I red that doing the same as I did with STM32F1 is far more difficult (if not impossible) at this stage. And in the second topic I saw Roger Clark recommended STLink for STM32F4 microcontrollers.

So here are my questions about STM32F4:
1) Did I get it right? Is it indeed difficult/impossible to upload via USB at this stage of development?
2) Is there any alternate way to upload besides STLink? For example via RX and TX or something like that.
3) If STLink is the only way for now – is it necessary a bootloader for that? What kind of bootloader? Where can I get it? How should I upload it? Maybe it was mentioned in one of these topics but I didn’t find it.

Best regards!
Stan

Stanimir5F wrote:
1) Did I get it right? Is it indeed difficult/impossible to upload via USB at this stage of development?

Thanks for your response, Martin!

I totally forgot to mention about this. Yes, I have tried starting the bootloader by placing BOOT0 to 1 and BOOT1 to 0. And yes, I see the DFU device in Device manager. But for some reason it is displayed in the “Universal Serial Bus Controllers” section . I remember that few days ago I saw it in a separate section “libusb-win32 devices” (or something like that) but maybe because of some drivers update I don’t see it like that any more. I’m not sure if that’s an issue at all (the fact that it is in different section of device manager) but now when I tried to run the dfu-util as you suggested with ‘-l’ option I see no devices listed. And also I have used this bootloader only with “STMFlashLoader” so far.

So I have another questions.
Is it possible to use this default bootloader to upload Arduino sketches?
Should I look for another driver so the device be displayed in a separate section in device manager?
Is this the reason why I can’t see it in the list of DFU devices in the DFU-util?

Once again, please excuse me for my lame questions but these are my first steps working with STM32 in Arduino IDE. Before that I have worked with STM a little bit in Maple and mostly with IAR Embedded Workbench. As for Arduino IDE all my experience is with AVR processors. So combining these two is something new to me.

Stan

@Stanimir5F

It sounds like you don’t have the driver loaded for the DFU device.

It sounds a bit like you are running Windows, but you don’t seem have said which OS you are running.

Anyway. Assuming you are using Windows, if you run dfu-util.exe -l from the arduino_stm32\tools\win folder it should list all the dfu devices that are available

(make sure your F4 is in DFU mode when you do this)

Hello, Roger!

Indeed I forgot to mention the OS I’m using. It’s Windows 7.

You confirmed my suspicions about wrong driver being installed. So I uninstalled it and start looking around. I found the program zadig 2.2 and I installed the “libusb-win32 (v1.2.6.0)”. Now the device is displayed in separate section of the Device manager menu – “libusb-win32 devices” and when I list the devices in the command prompt I see this:

C:\Arduino\hardware\Arduino_STM32\tools\win>dfu-util -l
dfu-util - (C) 2007-2008 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Found DFU: [0x0483:0xdf11] devnum=1, cfg=0, intf=0, alt=0, name="@Internal Flash /0x08000000/04*016Kg,01*064Kg,07*128Kg"
Found DFU: [0x0483:0xdf11] devnum=1, cfg=0, intf=0, alt=1, name="@Option Bytes/0x1FFFC000/01*016 e"
Found DFU: [0x0483:0xdf11] devnum=1, cfg=0, intf=0, alt=2, name="@OTP Memory /0x1FFF7800/01*512 e,01*016 e"
Found DFU: [0x0483:0xdf11] devnum=1, cfg=0, intf=0, alt=3, name="@Device Feature/0xFFFF0000/01*004 e"

for me on debian jessie, using tools/linux/dfu-util;
dfu-util -h gives the options

this is for reading back device memory regions, that’s the -a using the number in the -l output
stephen@i7:~/sketchbook/hardware/Arduino_STM32/tools/linux/dfu-util$ dfu-util -R -a 1 -U xyz

-R is a reset
-a nn -U filename -- read dev alternate nn region to file


The problem may be dfu-util.exe.

We dont have the source for it, and I vaguely recall that it may be a special version that was created / modified by leaflabs to work with their DFU bootloader code.

You could try looking for the original dfu-util and see if that works.

Note. I think Martin uses Linux, so he would be using a standard version of dfu-util, not a customised version

Yes, I’m working on Linux, and never got issues with dfu-util, except with v0.8 when “dfuse_addr” was not provided. But this has been fixed months ago in plateform.txt and maple-upload script.

For the error mentioned above, I have really not idea !
Maybe faulty Windows driver, maybe faulty cable…

Thanks to all of you for your responses!
I appreciate that!

First I tried Stephen’s suggestion. But the result was the same. Still I got an error when I try to upload. But your suggestion led me to another idea that caused a chain of new things to try.

I thought about trying the different devices that I see when run dfu-util with ‘-l’ option. Then I saw they have different address (seems logical). Then I decided that maybe the problem is that I’m trying to upload the binary into an address which is forbidden (or at least protected for something else). So I tried to upload to a specific address. I checked in the web what is the option. Here I saw it is ‘-s’.

But unfortunately this dfu-util doesn’t support ‘-s’ option. I’m using the one provided from the GitHub. Which is “dfu-util version 0.1+svn” (based on the log in command prompt). I’m not sure what exactly that “+svn”. But I decided to follow Roger’s suggestion and look around for another (maybe newer) version hoping it will support address selection.

When I googled about it I found these instructions. The top 1.1 and 1.0 links were broken so I abandoned them and continued searching. The next link I found was releases folder . But when I extracted the files in the archive I didn’t find executable file (or at least in 0.9 archive). Anyway I kept looking and I found 0.8. ‘-s’ option is supported here and I tried to upload on address shown when I list the devices (0x08000000). But without success so far.

I don’t even know whether this (the address issue) could cause all the troubles. But that was my only idea.

Also I tried to change the driver from the zadig software. Instead of “libusb-win32 (v1.2.6.0)” I decide to upload “libusbK (v3.0.7.0)”. This doesn’t help as well.

I begin to fear that I’m missing “the elephant in the picture”. Something which is really obvious and lame. But still I have no idea how to proceed.

Anyway once again thank you for your responses. If you have ideas I will try anything you suggest me.

Stan

Oh ! The fact that a newer version 0.9 came out can be interesting (I will try it under Linux).

For your issues that still present, I still don’t have any ideas …

In the mean time we figure that out, do you have access to a Linux machine ?
(because that can be a workaround to get your first sketch uploaded)

Thanks to all of you! I think I managed to make it upload!
Thanks to Martin for suggesting me the dfu-util. I knew about the bootloader but not how to use it properly!
Thanks to Stephen for telling me about altsetting option. I would never thought about that.
Thanks to Roger for the advice to look for another version of the dfu-util and the driver issue.
You all helped me a lot!

The problems were two things.
First the dfu-util version. The one in this doesn’t support the DfuSe (specify address) option. Dfu-util 0.8 support it. I guess with newer version would work as well.
The other thing was the driver. With “libusb-win32 (v1.2.6.0)” and “libusbK (v3.0.7.0)” the uploading failed. But with “WinUSB (v6.1.7600.16385)” (also installed via zadig) it did!

So now when I run the dfu-util with this line of options:
C:\Arduino\hardware\Arduino_STM32\tools\win>dfu-util -a 0 -s 0x08000000 -D "C:\Blink_STM32F4.cpp.bin"

stan

@ddrown has done a boards manager package version (I think of the F103). If you look at what he did, you should be able to work out what you need to do to get the F4 to work with 1.6.8

Actually, you can probably change the core without using the board manager,

Take a look in the platform.txt file, I think thats what needs to be changed to get it to work with 1.6.8

Note. The reason I have not updated the core to work with 1.6.8 is that I don’t think its possible to make a version which works with 1.6.5 (and older) and also with 1.6.8 and I didnt want to force everyone to update their copy of the IDE, since 1.6.5 works fine.

Re: Uploading from the IDE

If you look in platform.txt (at the bottom), you’ll see how it currently does the upload (various types of uploads are defined)

Sorry, I can’t be more help, but I only have time to point you in the correct direction

Thank you for you advices, Roger!
I will try them. For this moment they are more than enough.

And you don’t have to apologize. After all, this is my work to do not yours. So it’s up to me to make efforts to make it work.

Stan

Stanimir5F wrote:
Since I want to make it easier for uploading (simply by clicking on the “upload” button) I know I should add board’s description in board.txt as well as I should add a set of files in the variant folder. But I guess I should do the same with the platform.txt in order to trigger the uploading via dfu-util. Am I right? Or it’s more complicated than that?

Guys

As tools are shared across processor variants, the new dfu- util would need to be tested with the bootloader ( both old and new versions) on the F103

So if you create a PR can you do it for the Development branch of the repo, so that people can test it without breaking things for new users.

Thanks

I followed your advices but I didn’t work. I saw about the maple upload defined in platform.txt. So I replaced the initial stlink method with maple upload. Also the IDs. But maybe I miss something in the board.txt file that also should be changed.

The discovery_f407 upload section now looks like this:
discovery_f407.upload.tool=maple_upload
discovery_f407.upload.protocol=maple_upload

#discovery_f407.upload.use_1200bps_touch=false
discovery_f407.upload.file_type=bin
discovery_f407.upload.ram.maximum_size=17000
discovery_f407.upload.flash.maximum_size=1048576
discovery_f407.upload.maximum_size=1048576

discovery_f407.upload.usbID=0483:df11
discovery_f407.upload.altID=0
discovery_f407.upload.auto_reset=true
discovery_f407.upload.dfuse_addr=0x8000000

This “Invalid Signature” is the error shown when no dfu_address is provided, it try to load *.dfu instead of *.bin.
Did you turn ON verbose to see the arguments passed to dfu-util ?
Looking at Windows version of maple_upload.bat script, it looks completely different from the one on Linux, it is using maple_upload.jar, which is completely unknown to me. The problem is maybe there …
A workaround would be to write a new maple_upload.bat that would work identically to the one from Linux without any *.jar involved.

Martin, you are right. It was because of the content of “maple_upload.bat” file.
So I replace the line:
java -jar maple_loader.jar %1 %2 %3 %4 %5 %6 %7 %8 %9

Did you compare with the maple_upload script of Linux ?
It is actually receiving the project name as argument, so you can add echos to figure out, but according to Linux version, the project bin is in %4 while the dfu-address is in the %5 argument.

if [ $# -lt 4 ]; then
echo "Usage: $0 $# <dummy_port> <altID> <usbID> <binfile>" >&2
exit 1
fi
dummy_port="$1"; altID="$2"; usbID="$3"; binfile="$4"; dummy_port_fullpath="/dev/$1"
if [ $# -eq 5 ]; then
dfuse_addr="--dfuse-address $5"
else
dfuse_addr=""
fi


Thank you again!
I followed your suggestion and I did it!
With this I think I finished the first part!