Bootloader imported in SW4STM32 compiles but stuck after usb_init

Hi,
I have setup a SW4STM32 project from the bootloader directory so it is more convenient to work on it, it compiles fine but unfortunately the STM32 stucks at usb_init, precisely as soon as the usb NVIC are setup, if I comment out the usb NVIC setup or the whole usb_init then the STM32 doe not stuck and blink LEDs as it should.
I am pretty sure this is due to specific flags or settings in the makefile that are not reproduced in the SW4STM32 project, i tried to add few proprocessor flags but it did not have any effect so i removed them. The exact same code compiled with the makefile works and does not stuck after usb NVIC setup.
Does anyone have an idea on what i should try to make the SW4STM32 project work?
The SW4STM32 project

bootloader.zip

(99.07 KiB) Downloaded 23 times

sw4stm32 uses a newer version of the arm-none-eabi-gcc than arduino. You might try changing the optimization to -O1 or even -Og or even -O0 .. assuming it still fits in the first 8k

Thanks you for the hint, i tried with GCC 4.8 presumably shipped with XCode, but it didnt helped. I will try to find how to use the Arduino GCC instead. Regarding optimisations i already set to -O0, i wil try 01. Yes it still fits in the 8K

EDIT:Afer a check, current version of Arduino gcc is 4.8.3-2014q1, i have modified the project properties to use this gcc, it compiles fine, but problem persists. apparently it still uses Make from XCode, not sure if it matters

Building target: bootloader.elf
Invoking: MCU GCC Linker
arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mfloat-abi=soft -T"/Users/hoel/Documents/workspace/bootloader/LinkerScript.ld" -Wl,-Map=output.map -Wl,--gc-sections -o "bootloader.elf" @"objects.list" -lm
Finished building target: bootloader.elf

/Applications/Xcode.app/Contents/Developer/usr/bin/make --no-print-directory post-build
Generating binary and Printing size information:
arm-none-eabi-objcopy -O binary "bootloader.elf" "bootloader.bin"
arm-none-eabi-size "bootloader.elf"
text data bss dec hex filename
6564 1740 3184 11488 2ce0 bootloader.elf

We are talking about F103, right?
Which board do u use?

I checked out the bootloader source and tried a few things all on ubuntu 16.04.

My default arm-none-eabi-gcc is loaded in /usr/bin … it is version:
$ arm-none-eabi-gcc –version
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors 6-2017-q2-update) 6.3.1 20170620 (release) [ARM/embedded-6-branch revision 249437]

I used the makefile to build from the command line and did a make generic-pc13. I loaded the build/maple_boot.elf it created on a blue pill using a blackmagic probe. I then un-plugged and re-plugged the device and it enumerated as a maple leaf DFU device. I then used the Arduino IDE to compile and load (w/STM32duino bootloader) a blink sketch. It all worked fine. So I guess it doesn’t matter if you use a newer version of arm-none-eabi-gcc.

I then created a new SW4STM32 project selecting the “Make project from existing makefile”. I selected the directory of the github source . I was able to create a new build target ‘generic-pc13’ I did a clean and build. It also worked fine. It isn’t a “true” eclipse project but it allows you to use the eclipse environment to edit.

Again this was all on linux so I have no idea how it would work on OS/X

FWIW

Some changes were made to the bootloader source code to allow it to compiler and run on newer versions of gcc. The issues and commit history will have more information on this.

I only build from the makefile (on Windows) and generally use the same version of gcc that is installed by the Arduino IDE.

I did try a slightly newer version of gcc at one time and it also seemed to work OK.

However the bootloader code is not guaranteed to work with all versions of GCC hence in the readme, it states which version to use.

Also, if you want to build using some other environment, and it doesnt work, then the obvious conclusion is that there is some difference in your build environment, and that you need to change it to build the code in exactly the same way as the makefile does.

e.g. compiler options are likely to have a big impact on the way the code works (or doesn’t work)

wow nice, thanks for all the testing, yes we are talking of F103CBT6 here. My bootloader source is outdated so its maybe the problem, I will download last rev and try making a new makefile project.

I try to make a bootloader version for STM32L151C8 and STM32F303CC. I have defined the target rules and modified the makefiles, i also added some .ld files and startup files for the L1 and F3, i found where to reference the .ld files but nothing for others, also not sure where to find the .s and .h macro files for L1 and F3.
Other than referencing these files, do i need to adapt each and every registers reference in hardware.h, and possibly each function of the bootlaoder for L1 and F3?

Once the bootladers are ok i will add the Arduino cores for L151 and F303, current stm32duino F303 core is too outdated to be useful, i found some core that seem complete and working (https://github.com/avikde/koduino for F3 and http://library.radino.cc/Arduino_1_8/ra … .1.tar.bz2 for L1)

The fix for the compiler versions was done quite a while ago, but I would recommend downloading the latest version

Re: Versions for F3 etc

I think a lot of people would be interested in a version for the F4, but from what I understand, quite a few things are different on the F4

I did see a port to F4 on a Chinese website, but it was one of those site where you have to pay to view the code, so I didn’t bother (especially as its an unknown Chinese site, so there was no way I’m giving them my credit card details)

yes F3 and F4 should be very close, once these L1 and F3 are done i will try to make L4. Please show the URL of chinese website, i may find a way to get it. Regarding the bootloader, after few tests i can see the registers are different on F3 than those used in bootlader so nothing works, i am in the slow process to rewrite bootloader using stdfperiph function instead of direct register access, once finished if the size is too large (which is not sure) i will rewrite the functions with direct access to avoid stdperiph, but in the end i find a bootlader based on stdperiph would be far more convenient for porting to various targets.
N.B this port already includes F4 https://github.com/avikde/koduino but i am still interrested to know the one you found in case it is more recent

Re: Code for F4 booloader

I posted a thread about it

viewtopic.php?f=3&t=2104

I suspect the code is completely out of date and would not work unless its with the old version of the compiler and without optimisation turned on, and it will also be larger, as the original LibMaple bootloader was 12k not 8k.
But I merged in some fixes to allow size optimastion to work, and that brought it down to just below 8k

Re: Koduino

I’m aware of Avik’s repo. (Koduino) , but its primary focus has was initially just F3 and the F4 was added later, but it doesnt have any support for the F1 (which is what most people use because they are ultra cheap)

As well as Avik’s repo, there is the official STM core on github.com/stm32duino, but that uses the HAL, and there is @danielef’s core which is also HAL based.

Re: Using SPL for the bootloader.

You may be able to get it to fit in 8k, the bare metal version that we currently use, only just squeezes into 8k, so any bloat at all will push it over that boundary.

PS.

There is some code for a F4 booloader using the HAL that @victor_pv wrote.

But the problem with it is that its not DFU, its DFUSE and needs a different version of dfu-util to support it and completely different DFU drivers on Windows to the ones we currently use.
Those drivers need to be manually installed using Zadig, which is a pain

Hence something that just works with conventional DFU would be a lot better as it would mean people could upload to the F1 and F4 without needing to have separate copies of dfu-util etc etc

ohh, i was not aware of this https://github.com/stm32duino/Arduino_C … r/variants its probably the most up to date for F3/F4 and L4.
OK the Chinese core is very very old, useless to check.
I but that uses the HAL, and there is @danielef’s core which is also HAL based.
Is it a problem to use HAL? i dont particularly like HAL for itself but for arduino STM32 core it could help unification of targets.
But the problem with it is that its not DFU, its DFUSE and needs a different version of dfu-util to support it and completely different DFU drivers on Windows to the ones we currently use.
Those drivers need to be manually installed using Zadig, which is a pain
yes i dont want to go that way neither, i think the current DFU bootloader is good, i only modified it to have 100% success on OSX and added a function to stay in perpetual bootloader mode with double tap on reset so no IO used for user key

@danielef’s core https://github.com/danieleff/STM32GENER … 2/variants
Indeed everything is there for F1 F3 L1 and L4, i wonder if he made a bootlader as well

The Maple bootloader in my repo ( the one we all use), altready has a feature to hold if you put a magic number in backup register DR10.

I posted about this many times before.

Re: other bootloader

I don’t think @danielef has written a bootloader

@jcw wrote one ages ago, but it does not implement DFU, I think it uses a serial data format.

The Blackmagic probe has a DFU bootloader and uses LibOpenCM3, but it only supports F1.
They used to also support F4, but dropped support for it ages ago, before they did a major code reorganisation

You should be able to modify their F1 bootloader to run in F4 etc, but it isn’t quite the same as the Maple bootloader as it expects a button to be pressed at boot time to switch it into DFU mode, rather than always going into DFU for a fixed period of time before jumping to the Application code.

The good thing about the Blackmagic Probe bootloader, is it will fit in 8k

[Rick Kimball – Tue Dec 05, 2017 10:02 pm] –

I then created a new SW4STM32 project selecting the “Make project from existing makefile”. I selected the directory of the github source . I was able to create a new build target ‘generic-pc13’ I did a clean and build. It also worked fine. It isn’t a “true” eclipse project but it allows you to use the eclipse environment to edit.

Again this was all on linux so I have no idea how it would work on OS/X

@Rick Kimball
Hi,
Would you mind to share the SW4STM32 project? when i use “makefile from exiting code” and then select AC6 STM32 MCU GCC the resulting project can build but it only make a hex file, and when i uplaod this hex file maually (with stlink binary) it writes 60 pages or 1K, i dont know why, also it doesnt work : the target doesnt blink.
I would be curious to test with the project you made, did you try to flash the resulting binary?

[RogerClark – Wed Dec 06, 2017 7:29 pm] –
The Blackmagic probe has a DFU bootloader and uses LibOpenCM3, but it only supports F1.
They used to also support F4, but dropped support for it ages ago, before they did a major code reorganisation
You should be able to modify their F1 bootloader to run in F4 etc, but it isn’t quite the same as the Maple bootloader as it expects a button to be pressed at boot time to switch it into DFU mode, rather than always going into DFU for a fixed period of time before jumping to the Application code.
The good thing about the Blackmagic Probe bootloader, is it will fit in 8k

@RogerClark
thanks I will check into this, i dont like the perspective to use LibOpenCM3. Best option is probably to modifiy the current bootlader, but the makefile makes the task complicate, importing it in SW4STM32 as makefile project result in a non working binary.
I finally switched to the Arduino HAL core and the 3 boards variants are now fully working (F1, L1, F3), so bootlaoder for L1 and F3 is the last bit.

[RogerClark – Wed Dec 06, 2017 7:29 pm] –
The Maple bootloader in my repo ( the one we all use), altready has a feature to hold if you put a magic number in backup register DR10.
I posted about this many times before.

Yes bkp10, actually the point here was allow user to set bootloader in perpetual mode with a double press on rst push button. That solution avoid the need for user push button, it is also mandatory for Arduino since users tend to upload non working code which breaks the virtual serial port and thus prevent upload of new firmware due to the “reset over virtual serial port” design. I used BKP9 and it cannot be set by user directly (part of double press detection mecanism).