MSBuild makefile equivalent

[parsec67]

The ARM bootloader example step 16 references editing a Makefile. How does this translate to MSBuild, i.e. how/where should I enter the added rules? I assume the syntax also differs?

[support]

Hi,

The MSBuild system already supports embedding binary files into projects (e.g. see this tutorial), although the resources are normally added to the .rodata section.

We have added an option to specify the section name (e.g. .bootloader) for each binary resource file to this build: VisualGDB-5.2.14.1335.msi

Please try adding the .bin file to the project, opening file properties for it, switching the type to ‘Embedded Resource’ and then changing the section name in Embedded Resource->General to .bootldr. Don’t forget to update your linker script to actually place the .bootldr sections at the correct address.

 

[parsec67]

Hi,

Thanks, that is very neat, however, I encountered a couple of problems. First, I cannot find the type Properties->Embedded Resource, did you mean Embedded Binary which has a Section option?

Second, my bootloader consists of 2 parts, a boot reset vector that goes to the top of Flash memory and bootloader code which is placed at the bottom. When I first add the bootloader reset vector all is fine, e.g. linker script:

MEMORY
{
    FLASH (RX)   : ORIGIN = 0x08000000, LENGTH = 0xE0000 /* 1M */
    BOOTLDR (RX) : ORIGIN = 0x080E0000, LENGTH = 0x20000
    SRAM (RWX)   : ORIGIN = 0x20000000, LENGTH = 128K
    CCMRAM (RWX) : ORIGIN = 0x10000000, LENGTH = 64K
}

_estack = 0x20020000;

SECTIONS
{
    .bootrstv :
    {
        . = ALIGN(4);
        KEEP(*(.bootrstv))
    } > FLASH

    .isr_vector :
    {
        . = ALIGN(4);
        KEEP(*(.isr_vector))
        . = ALIGN(4);
    } > FLASH
...

This produces a correctly looking memory map:

                0x20020000                _estack = 0x20020000

.bootrstv       0x08000000       0x14
                0x08000000                . = ALIGN (0x4)
 *(.bootrstv)
 .bootrstv      0x08000000       0x14 VisualGDB/Debug/bootrstv.o
                0x08000000                _binary_bootrstv_bin_start
                0x08000014                _binary_bootrstv_bin_end

.isr_vector     0x08000014      0x188
                0x08000014                . = ALIGN (0x4)
 *(.isr_vector)
 .isr_vector    0x08000014      0x188 VisualGDB/Debug/startup_stm32f407xx.o
                0x08000014                g_pfnVectors
                0x0800019c                . = ALIGN (0x4)

Then, as soon as I also add the bootloader.bin file to the project, without doing anything else, the .bootrstv object file is not included in the build and entire section is set to zero length. So after inclusion of a second .bin file the memory map turns out like this:

                0x20020000                _estack = 0x20020000

.bootrstv       0x08000000        0x0
                0x08000000                . = ALIGN (0x4)
 *(.bootrstv)

.isr_vector     0x08000000      0x188
                0x08000000                . = ALIGN (0x4)
 *(.isr_vector)
 .isr_vector    0x08000000      0x188 VisualGDB/Debug/startup_stm32f407xx.o
                0x08000000                g_pfnVectors
                0x08000188                . = ALIGN (0x4)

• This reply was modified 7 years, 11 months ago by parsec67.

[support]

Hi,

This looks strange. Please double-check the following:

• The .link.rsp file in the Debug directory should mention object files for both binaries (bootrstv.o and the other binary)
• The bootrstv.o should contain one symbol in the .bootrstv section
• The second .o should contain one symbol in the other section. The symbol names for 2 binaries should be different to avoid conflicts between them.
• Your linker script should mention both section names using the KEEP syntax.

You can view the contents of a .o file with arm-eabi-objdump.

[parsec67]

Hi,

I think your points 2 and 3 are my problem, both object files contain only a .data section with different file offsets.

I have given up on trying to make this bootloader (made using another environment) work and will instead roll my own from scratch and in VisualGDB later.

Off to buy an embedded license, the evaluation period and support on this forum has convinced me that this is the right tool invest in.

O/T feature request: I’d personally love it if the online user documentation was in searchable/indexed format, (e.g. http://infocenter.arm.com). An added bonus would be a PDF user’s manual, to have something to read on the go. There is so much useful information available on the website but it is not always easy to find the relevant pages. I think this alongside projects with source code attached with each tutorial would make transitioning and/or learning this environment a whole lot easier.

• This reply was modified 7 years, 11 months ago by parsec67.

[support]

Hi,

Sorry about that. Normally the .o0 file (note the zero at the end) should contain the .data section, and the normal .o file should have it renamed according to the file properties. Anyway, if you decide to get back to this, let us know and we will gladly provide further help.

Regarding the documentation, we keep it online mostly for simplicity so that we could easily update it (e.g. use tags to group relevant tutorials) without rebuilding a huge collection of PDF files. You can easily search through all the documentation on our website by using the “site:” suffix on Google, e.g. https://www.google.com/search?q=bootloader%3A+site%3Avisualgdb.com

If this is not convenient, let us know why and we will look into making search more transparent.

[support]

We have published a detailed tutorial showing how to create bootloader projects with MSBuild here: https://visualgdb.com/tutorials/tutorials/arm/bootloader/msbuild/

[Author]

Posts