engicoder

Forum Replies Created

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • in reply to: Problem adding section to linker script #10300
    engicoder
    Participant

    I figured out the problem with having a separate memory command. The section command has to be marked with the (NOLOAD) section type as there is no data to load. GDB was telling me that with the error:

    
    One or more sections of the target image does not match the loaded file
    

    I just had to figure out what it meant. objdump clued me in when the .settings section was marked “CONTENTS, ALLOC, LOAD, DATA“, which indicated that the GDB would try to allocate the section and load its contents. With the (NOLOAD) section type the .settings section is only marked “ALLOC“.

    The corresponding linker script entries:
    For the MEMORY command:

    
    MEMORY
    {
        FLASH (RX)     : ORIGIN = 0x08000000, LENGTH = 64K - 1K
        SETTINGS(R)    : ORIGIN = 0x0800FC00, LENGTH = 1K
        SRAM (RWX)     : ORIGIN = 0x20000000, LENGTH = 8K
    }
    

    and for the SECTION command:

    
        .settings (NOLOAD) :
        {
            *(.settings)
        } > SETTINGS 
    
    in reply to: Problem adding section to linker script #10290
    engicoder
    Participant

    Ah, my mistake, it is generated, it just doesn’t have a .elf extension. The elf file has no extension.

    in reply to: Problem adding section to linker script #10288
    engicoder
    Participant

    How do I generate an elf file with an MSBuild based project, like the ones created by the template?

    in reply to: Problem adding section to linker script #10274
    engicoder
    Participant

    Thank you, that worked. I did have to compensate for the standard .isr_vector section that comes before text. In the default linker scrip there are also some sections that follow .text such as .ARM.extab, .init_array, .fini_array, etc. These seemed to be have sizes of zero, but I assume that is not always the case. Using your suggest as a hint, I was able to write a section definition that I placed after all other FLASH sections and calculate the current offset.

    
        _offset = .;
     
        .settings :
        {
            . = . + 0x0800FC00 - _offset;
            *(.settings)
        } > FLASH
    

    Oddly two other seemingly equivalent offset expressions generated a linker overflow error:
    . = 0x0800FC00;
    . = . + 0x0800FC00 - .;
    I assume this has to do with how the linker evaluates the expressions.

    For future readers, following is the FLASH section of the default linker script with the above addition.

    
    
    ENTRY(Reset_Handler)
    
    MEMORY
    {
        FLASH (RX)     : ORIGIN = 0x08000000, LENGTH = 64K
        SRAM (RWX)     : ORIGIN = 0x20000000, LENGTH = 8K
    }
    
    _estack = 0x20002000;
    
    SECTIONS
    {
        .isr_vector :
        {
            . = ALIGN(4);
            KEEP(*(.isr_vector))
            . = ALIGN(4);
        } > FLASH
    
        .text :
        {
            . = ALIGN(4);
            _stext = .;
    
            *(.text)
            *(.text*)
            *(.rodata)
            *(.rodata*)
            *(.glue_7)
            *(.glue_7t)
    
            KEEP(*(.init))
            KEEP(*(.fini))
            . = ALIGN(4);
            _etext = .;
    
        } > FLASH
    
        .ARM.extab :
        {
            . = ALIGN(4);
            *(.ARM.extab)
            *(.gnu.linkonce.armextab.*)
            . = ALIGN(4);
        } > FLASH
    
        .exidx :
        {
            . = ALIGN(4);
            PROVIDE(__exidx_start = .);
            *(.ARM.exidx*)
            . = ALIGN(4);
            PROVIDE(__exidx_end = .);
        } > FLASH
    
        .ARM.attributes :
        {
            *(.ARM.attributes)
        } > FLASH
    
        .preinit_array :
        {
            PROVIDE(__preinit_array_start = .);
            KEEP(*(.preinit_array*))
            PROVIDE(__preinit_array_end = .);
        } > FLASH
    
        .init_array :
        {
            PROVIDE(__init_array_start = .);
            KEEP(*(SORT(.init_array.*)))
            KEEP(*(.init_array*))
            PROVIDE(__init_array_end = .);
        } > FLASH
    
        .fini_array :
        {
            PROVIDE(__fini_array_start = .);
            KEEP(*(.fini_array*))
            KEEP(*(SORT(.fini_array.*)))
            PROVIDE(__fini_array_end = .);
        } > FLASH
    
        . = ALIGN(4);
        _sidata = .;
    
        _offset = .;
    
        .settings :
        {
            . = . + 0x0800FC00 - _offset;
            *(.settings)
        } > FLASH
    

    I would still like to understand why I could not create a separate MEMORY entry and associate a section with it.

    • This reply was modified 7 years, 9 months ago by engicoder.
    in reply to: Problem adding section to linker script #10267
    engicoder
    Participant

    Thanks for the quick replies!
    I tried what you suggested. Flash is 64K so should extend to 0x08010000. Subtracting 1K gives us 0x0800C00 as the address for the .settings section.
    Using the following linker script:

     
        .text :
        {
            . = ALIGN(4);
            _stext = .;
    
            *(.text)
            *(.text*)
            *(.rodata)
            *(.rodata*)
            *(.glue_7)
            *(.glue_7t)
    
            . = 0x0800FC00;
            *(.settings)
    
            KEEP(*(.init))
            KEEP(*(.fini))
            . = ALIGN(4);
            _etext = .;
    
        } > FLASH
    

    I get a linker error:

    
        ld.exe: [...] section '.text' will not fit in region 'FLASH'
        ld.exe: region 'FLASH' overflowed by 134217952 bytes
    

    I got the same result if I try to create a separate section declaration as follows:

     
        .settings :
        {
            . = 0x0800FC00;
            *(.settings)
            . = ALIGN(4);
        } > FLASH
     
    
    • This reply was modified 7 years, 9 months ago by engicoder.
    in reply to: Problem adding section to linker script #10248
    engicoder
    Participant

    I created a project using the Standard Peripheral template and replace LEDBlink.cpp with main.c

    Here is the source for main.c

    
    #include "stm32f0xx_flash.h"
    
    __attribute__((__section__(".settings"))) const uint16_t settings[64];
    
    int main()
    {
        uint16_t eep = settings[0];
    
        FLASH_Lock();
        FLASH_ErasePage((uint32_t)&settings[0]);
        FLASH_ProgramHalfWord((uint32_t)&settings[0], 0xDEAD);
        FLASH_ProgramHalfWord((uint32_t)&settings[1], 0xBEEF);
        FLASH_Unlock();
    
        eep = settings[0];
    
        for (;;)
        {}
    }
    
    in reply to: Problem adding section to linker script #10246
    engicoder
    Participant

    I don’t see a GDBServer Console under Debug->Windows

    The problem I am seeing occur when I select Debug->Program and Start without Debugging

    First I see this popup:

    When I click on View GDB log I see this popup

    If I select the GDB Server log tab I see this:

     

    If I remove any references to the array declared

    __attribute__((__section__(".settings"))) const uint16_t settings[64];

    It programs without problem.

    • This reply was modified 7 years, 9 months ago by engicoder.
    in reply to: Problem adding section to linker script #10238
    engicoder
    Participant

    Where do I find the OpenOCD window? If you mean the test OpenOCD settings, the runs successfully. The errors I am seeing are coming from GDB after OpenOCD connects successfully.

    • This reply was modified 7 years, 9 months ago by engicoder.
    in reply to: Problem adding section to linker script #10232
    engicoder
    Participant

    Note: There is a mismatch in the info above. The array dimension is 512, but should be 64. The error dump is when the array length was 64, hence the section size of 128. I tried both array sizes.

    in reply to: StdPeriph template for STM32 missing in 5.2 Beta 1 #9188
    engicoder
    Participant

    Well, today (after a windows update and reboot) it seems to be working fine. Not sure what was going on. I will assume the problem was between my ears somewhere. Thanks for all your help and quick responses.

     

    To follow up,  yes, the sample.xml file was at the location you specified.

    in reply to: StdPeriph template for STM32 missing in 5.2 Beta 1 #9173
    engicoder
    Participant

    I removed the STM32 Devices BSP and reinstalled (version  3.7r2) via the package manager, restarted Visual Studio, but still no StdPeriph sample project.

    On a different note: I keep seeing references to 5.2 Beta 2, but can only find a download for 5.2 Beta 1.

     

    in reply to: StdPeriph template for STM32 missing in 5.2 Beta 1 #9171
    engicoder
    Participant

    Interesting. This was for the STM32F072RB. Why would it depend on the device? In the past, I have created StdPeriph projects for this device with VisualGDB.

    in reply to: Beginner – 5.0 can't debug on STM32F072 discovery #6863
    engicoder
    Participant

    More clarification:

    The code seems to execute properly; i.e. LED does blink, but if I set a breakpoint, it never breaks on that breakpoint. If I select “Break All”, it always seems to break in NVIC_SetPriority(), but stepping from there behaves as if it is connected to the wrong source (i.e. does not advance or jumps to some other point in code that has no relation to the previous point).

    I tried both the Hal and StdPeriph versions of the project and while both ran properly on the device, in neither case did the debugging seem to work.

    I tried uninstalling Visual GDB and re-installing and saw no difference.

Viewing 13 posts - 1 through 13 (of 13 total)