[SOLVED] Bootloader and a non Arduino application build method

I have the “generic_boot20_pb9.bin” boot loader installed on an LC Studio STM32F103RBT6 development board.
To test this I used the generic STM32F103R Blink example after change the LED pin. This builds fine and I can use the boot loader to flash it under Arduino so appears this is working fine.

I have a program I wrote that is built with GCC and uses the STM32F10x_StdPeriph_Lib_V3.5.0 library and the USB drivers they provide. I can build and flash the binary using stm32flash over a serial port or using st-flash over an ST-Link and it flashes and works fine. My program uses a USB and when connected a /dev/ttyACMx device is created.

I have a couple of questions…

Before the boot loader passes control to the flashed application does it fiddle the PA12 bit to force enumeration? The Blink program appears to have the ttyACM support as part of the build and I can see that but with my GCC application I’m not seeing my ttyACM device.

The other question is and is probably the issue I’m having but I’m not sure what I need to do. As the boot loader runs at 0x08000000 does the Arduino change the code linking address so that sketches are compiled for another address when the programmer is set to use the boot loader? I find the Arduino IDE build information that is output very convoluted so difficult to know where to start looking to see what load address it uses.

My application uses the linker load file “stm32_flash.ld”. Inside this it has:

/* Specify the memory areas */
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 128K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 20K
}


You need to change the Vector table address and the base of flash to

0x8002000

i.e Its not just the linker file that needs to be changed

The linker file I’m using is from the STM32F10x_StdPeriph_Lib_V3.5.0 library.

STM32F10x_StdPeriph_Lib_V3.5.0/Project/STM32F10x_StdPeriph_Template/TrueSTUDIO/STM3210B-EVAL/stm32_flash.ld

This linker file is the only one that seems to be compatible with my tool chain (arm-none-eabi).

/* The startup code goes first into FLASH */
.isr_vector :
{
. = ALIGN(4);
KEEP(*(.isr_vector)) /* Startup code */
. = ALIGN(4);
} >FLASH


Vector table address is somewhere completely different in the SPL.

Just use your editor to search for VECTOR it should find something and its likely to be set to 0x8000000

Been at this all day and not getting anywhere really.

I can find plenty of matches for VECTOR using grep but the only ones I see that make any sort of sense are in “.lsl” files such as STM32F10x_StdPeriph_Template/HiTOP/STM3210B-EVAL/Settings/STM32F10x_md.lsl

In there it has:

#ifndef __VECTOR_TABLE_ROM_ADDR
# define __VECTOR_TABLE_ROM_ADDR 0x08000000
#endif


Typically you should have a -DVECT_TAB_ADDR=0x8002000 (or something similar) in your compiler command.

Edit: I’d say -D__VECTOR_TABLE_ROM_ADDR=0x08002000 for SPL

[edogaldo – Tue May 08, 2018 8:06 am] –
Typically you should have a -DVECT_TAB_ADDR=0x8002000 (or something similar) in your compiler command.

Edit: I’d say -D__VECTOR_TABLE_ROM_ADDR=0x08002000 for SPL

But isn’t that to just define a value for the source files to make use of? The whole idea of a linker I thought was to combine compiled lib code to execute at a specific address so should just be linker issue.

Ok, as I can see, the stm32duino core uses different .ld files for rebasing the code; i.e. the boards.txt for the maple mini variant (with new bootloader option) uses:
mapleMini.menu.bootloader_version.bootloader20.build.ldscript=ld/bootloader_20.ld

edogaldo wrote:
MEMORY
{
ram (rwx) : ORIGIN = 0x20000000, LENGTH = 20K
rom (rx) : ORIGIN = 0x08002000, LENGTH = 120K
}

mmmm…
I’m looking at SPL_F1 v. 3.5.0 and I can’t find any definition for __VECTOR_TABLE_ROM_ADDR..
Instead I can see:
#define VECT_TAB_OFFSET 0x0 /*!< Vector Table base offset field.
This value must be a multiple of 0x200. */
[...] #ifdef VECT_TAB_SRAM
SCB->VTOR = SRAM_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal SRAM. */
#else
SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH. */
#endif
[...]

[edogaldo – Tue May 08, 2018 1:02 pm] –
mmmm…
I’m looking at SPL_F1 v. 3.5.0 and I can’t find any definition for __VECTOR_TABLE_ROM_ADDR..

$ cd STM32F10x_StdPeriph_Lib_V3.5.0
$ grep -r __VECTOR_TABLE_ROM_ADDR *

118 matches found.

Ok, anyway this seems dedicated to the HiTOP IDE which seems to be an old IDE.

Edit: there is a vector table relocation example in the NVIC examples section..

BTW.

You do not need to change the RAM base address, it’s only there for the very old Maple bootloader which supported upload to RAM

This option was removed in the stm32duino bootloader , and that RAM was free’ed up and given to the application sketch

[edogaldo – Tue May 08, 2018 1:55 pm] –
Ok, anyway this seems dedicated to the HiTOP IDE which seems to be an old IDE.

Edit: there is a vector table relocation example in the NVIC examples section..

The (edit HiTop -> TrueSTUDIO) Load file was the only one that would work for me without any changes as I think it had used standard GCC Load files where as the others seem to do there own thing and/or used different tool chains.

Edit: No not “HiTop” was TrueSTUDIO load files that worked out of the box for me.

I’m going on memory as it was 7 years ago now and I never used any of the IDEs and only in recent times have used Arduino but won’t for this project. I don’t think ST ever supplied any command line building tools examples so I had to work out all my own Makefiles to suit GCC command line usage.

@RogerClark: Noted!

I’ll give it another go today. I really want to have a boot loader option even back 7 years ago.

edogaldo wrote:
Edit: there is a vector table relocation example in the NVIC examples section..

I think it’s working now. Part of the problem was my test code I added to flash LEDs I had not initialised the timer interrupt.
So far the only change has been to the Load file: FLASH (rx) : ORIGIN = 0x08002000, LENGTH = 128K-8K

I will mark this thread as [SOLVED] later after I have done some more testing.

staticmem wrote:I will mark this thread as [SOLVED] later after I have done some more testing.

Yes

Take a look in the libmaple core, you have to put PA12 into GPIO mode and drive it HIGH or LOW (I can’t remember which ), for something like 500uS

This is a hack, and not the official way to force enumeration, but it normally works

So far the only change has been to the Load file: FLASH (rx) : ORIGIN = 0x08002000, LENGTH = 128K-8K
Did you also notice the
#define VECT_TAB_OFFSET 0x3000


edogaldo wrote:
Did you also notice the
#define VECT_TAB_OFFSET 0x3000


Cool