Skip to main content
ERhod.1
Associate II
August 16, 2021
Solved

ERROR common.c: addr too high

  • August 16, 2021
  • 8 replies
  • 2280 views

I am getting this error after I modify my linker script (which I got from a project created with CubeIde):

$arm-none-eabi-objcopy -O binary Prog_test_H735.elf Prog_test_H735.bin

$arm-none-eabi-size Prog_test_H735.elf

  text     data      bss      dec      hex   filename

 35596      188     2108    37892     9404   Prog_test_H735.elf

$st-flash write Prog_test_H735.bin 0x8000000

st-flash 1.7.0

2021-08-16T15:18:11 INFO usb.c: Unable to match requested speed 1800 kHz, using 1000 kHz

2021-08-16T15:18:11 INFO common.c: H72x/H73x: 128 KiB SRAM, 1024 KiB flash in at least 128 KiB pages.

file Prog_test_H735.bin md5 checksum: 73e68311fa7a2f7533a11e4b1a1ca47, stlink checksum: 0x0039488a

2021-08-16T15:18:12 INFO common.c: Attempting to write 469762112 (0x1c000040) bytes to stm32 address: 134217728 (0x8000000)

2021-08-16T15:18:12 ERROR common.c: addr too high

stlink_fwrite_flash() == -1

make: *** [Makefile:130: flash] Error 255

Bellow follows the link script file. that I included the section ".d1_dma_buffer".

/*
******************************************************************************
**
** File : LinkerScript.ld
**
** Author : STM32CubeIDE
**
** Abstract : Linker script for STM32H7 series
** 1024Kbytes FLASH and 192Kbytes RAM
**
** Set heap size, stack size and stack location according
** to application requirements.
**
** Set memory bank area and size if external memory is used.
**
** Target : STMicroelectronics STM32
**
** Distribution: The file is distributed as is, without any warranty
** of any kind.
**
*****************************************************************************
** @attention
**
** Copyright (c) 2020 STMicroelectronics.
** All rights reserved.
**
** This software component is licensed by ST under BSD 3-Clause license,
** the "License"; You may not use this file except in compliance with the
** License. You may obtain a copy of the License at:
** opensource.org/licenses/BSD-3-Clause
**
****************************************************************************
*/
 
/* Entry Point */
ENTRY(Reset_Handler)
 
/* Highest address of the user mode stack */
_estack = 0x20020000; /* end of RAM */
/* Generate a link error if heap and stack don't fit into RAM */
_Min_Heap_Size = 0x200 ; /* required amount of heap */
_Min_Stack_Size = 0x400 ; /* required amount of stack */
 
/* Specify the memory areas */
MEMORY
{
 ITCMRAM (xrw) : ORIGIN = 0x00000000, LENGTH = 64K
 RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
 FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1024K
 RAM_D1 (xrw) : ORIGIN = 0x24000000, LENGTH = 320K
 RAM_D2 (xrw) : ORIGIN = 0x30000000, LENGTH = 32K
 RAM_D3 (xrw) : ORIGIN = 0x38000000, LENGTH = 16K
}
 
/* Define output sections */
SECTIONS
{
 /* The startup code goes first into FLASH */
 .isr_vector :
 {
 . = ALIGN(4);
 KEEP(*(.isr_vector)) /* Startup code */
 . = ALIGN(4);
 } >FLASH
 
 /* The program code and other data goes into FLASH */
 .text :
 {
 . = ALIGN(4);
 *(.text) /* .text sections (code) */
 *(.text*) /* .text* sections (code) */
 *(.glue_7) /* glue arm to thumb code */
 *(.glue_7t) /* glue thumb to arm code */
 *(.eh_frame)
 
 KEEP (*(.init))
 KEEP (*(.fini))
 
 . = ALIGN(4);
 _etext = .; /* define a global symbols at end of code */
 } >FLASH
 
 /* Constant data goes into FLASH */
 .rodata :
 {
 . = ALIGN(4);
 *(.rodata) /* .rodata sections (constants, strings, etc.) */
 *(.rodata*) /* .rodata* sections (constants, strings, etc.) */
 . = ALIGN(4);
 } >FLASH
 
 .ARM.extab : { *(.ARM.extab* .gnu.linkonce.armextab.*) } >FLASH
 .ARM : {
 __exidx_start = .;
 *(.ARM.exidx*)
 __exidx_end = .;
 } >FLASH
 
 .preinit_array :
 {
 PROVIDE_HIDDEN (__preinit_array_start = .);
 KEEP (*(.preinit_array*))
 PROVIDE_HIDDEN (__preinit_array_end = .);
 } >FLASH
 .init_array :
 {
 PROVIDE_HIDDEN (__init_array_start = .);
 KEEP (*(SORT(.init_array.*)))
 KEEP (*(.init_array*))
 PROVIDE_HIDDEN (__init_array_end = .);
 } >FLASH
 .fini_array :
 {
 PROVIDE_HIDDEN (__fini_array_start = .);
 KEEP (*(SORT(.fini_array.*)))
 KEEP (*(.fini_array*))
 PROVIDE_HIDDEN (__fini_array_end = .);
 } >FLASH
 
 /* used by the startup to initialize data */
 _sidata = LOADADDR(.data);
 
 /* Placing DMA data buffers at D1 region */
 .d1_dma_buffer : /* Space before ':' is critical */
 {
	 *(.d1_dma_buffer)
	} >RAM_D1
 
 /* Initialized data sections goes into RAM, load LMA copy after code */
 .data :
 {
 . = ALIGN(4);
 _sdata = .; /* create a global symbol at data start */
 *(.data) /* .data sections */
 *(.data*) /* .data* sections */
 *(.RamFunc) /* .RamFunc sections */
 *(.RamFunc*) /* .RamFunc* sections */
 
 . = ALIGN(4);
 _edata = .; /* define a global symbol at data end */
 } >RAM AT> FLASH
 
 /* Uninitialized data section */
 . = ALIGN(4);
 .bss :
 {
 /* This is used by the startup in order to initialize the .bss secion */
 _sbss = .; /* define a global symbol at bss start */
 __bss_start__ = _sbss;
 *(.bss)
 *(.bss*)
 *(COMMON)
 
 . = ALIGN(4);
 _ebss = .; /* define a global symbol at bss end */
 __bss_end__ = _ebss;
 } >RAM
 
 /* User_heap_stack section, used to check that there is enough RAM left */
 ._user_heap_stack :
 {
 . = ALIGN(8);
 PROVIDE ( end = . );
 PROVIDE ( _end = . );
 . = . + _Min_Heap_Size;
 . = . + _Min_Stack_Size;
 . = ALIGN(8);
 } >RAM
 
 /* Remove information from the standard libraries */
 /DISCARD/ :
 {
 libc.a ( * )
 libm.a ( * )
 libgcc.a ( * )
 }
 
 .ARM.attributes 0 : { *(.ARM.attributes) }
}

I have already read similar posts but none helped me understand how to fix this issue. It looks like it is a problem with my linker script construction. But I have used the same file in a CubeIde project that run with no problem.

Thank you for helping me understand the problem.

Regards,

E.

This topic has been closed for replies.
Best answer by Tesla DeLorean

Have you created a ridiculously large .BIN file due to the sparse placement of data?

st-flash is probably choking on Prog_test_H735.bin

You can't place d1_dma_buffer in the middle of everything, this either needs to be a NOLOAD, or the data behind the RAM content needs to be staged in FLASH properly. You'd also need to fix your startup.s code to accommodate multiple RAM regions.

8 replies

Tesla DeLorean
Tesla DeLoreanBest answer
Guru
August 16, 2021

Have you created a ridiculously large .BIN file due to the sparse placement of data?

st-flash is probably choking on Prog_test_H735.bin

You can't place d1_dma_buffer in the middle of everything, this either needs to be a NOLOAD, or the data behind the RAM content needs to be staged in FLASH properly. You'd also need to fix your startup.s code to accommodate multiple RAM regions.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
ERhod.1
ERhod.1Author
Associate II
August 16, 2021

Thanks for your reply.

"Have you created a ridiculously large .BIN file due to the sparse placement of data?"

Yes, its generating a 470MB .bin file.

"You can't place d1_dma_buffer in the middle of everything, this either needs to be a NOLOAD, or the data behind the RAM content needs to be staged in FLASH properly. You'd also need to fix your startup.s code to accommodate multiple RAM regions."

It works at the CubeIde workflow.

As far as I understand, If I mark it as NOLOAD, I will be telling the section must not be loaded to memory. But I want that data there (at D1 region) so that DMA1 can have access to it.

TDK
August 16, 2021

A BIN file is raw data. It has no way to indicate where different sections should go.

You should mark those buffers as NOLOAD so they are not stored in the image file.

.d1_dma_buffer (NOLOAD) :

"If you feel a post has answered your question, please click ""Accept as Solution""."
ERhod.1
ERhod.1Author
Associate II
August 16, 2021

It worked. @TDK​ and @Community member​  were correct.

I still do not understand. How does the MCU knows which data belongs to which region if ..."A BIN file is raw data. It has no way to indicate where different sections should go.".

Thank you!

TDK
August 16, 2021

The linker script tells the MCU what data gets stored where.

The issue here is you're trying to initialize that data, so the ELF file has that data initialized in it. When it converts ELF to BIN, it creates a huge file because the "where" information is lost.

The solution in this case is to not initialize it. But if you did need to initialize it, you would tell the linker to store it into flash, and then you would need to write your program such that it gets transferred from flash to RAM_D1 on startup.

"If you feel a post has answered your question, please click ""Accept as Solution""."
ERhod.1
ERhod.1Author
Associate II
August 17, 2021

Thank you for explaining the issue. Now I understand the consequences of my code. And yes, I do not need to initialize it. I just need to make sure that that vector will be placed at D1 region, where it can be accessed by DMA1.