Forum Replies Created
-
AuthorPosts
-
engicoderParticipant
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
engicoderParticipantAh, my mistake, it is generated, it just doesn’t have a .elf extension. The elf file has no extension.
engicoderParticipantHow do I generate an elf file with an MSBuild based project, like the ones created by the template?
engicoderParticipantThank 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.
engicoderParticipantThanks 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.
engicoderParticipantI 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 (;;) {} }
engicoderParticipantI 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.
engicoderParticipantWhere 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.
engicoderParticipantNote: 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.
engicoderParticipantWell, 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.
engicoderParticipantI 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.
engicoderParticipantInteresting. 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.
engicoderParticipantMore 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.
-
AuthorPosts