Assigning a fixed address to a section in the linker file causes debug error

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


I have a bootloader (BL) and an application (APP) that both live in flash.  I want to communicate between the two via a shared section of RAM that is not initialized upon a reset.  I previously had this working with an earlier revision of the project.  The APP has since undergone a radical redesign, and when I tired to add this functionality back in, I ran into an issue.

 

My code builds and links fine, but if I try to run the debugger I get this error:

 

I have a basic understanding of linker files, but they are by and large dark arts to me.  Here is my original addition where I reserve the last 4 bytes of RAM for the shared space:

 

...snip...
 _end = . ;
    _ram_end_ = ORIGIN(ram) + LENGTH(ram) - 5 ; /* MOD was -1 */

            /* Define heap symbols for heap_useNewlib.c */
    __HeapBase = _end;
    __HeapLimit = _ram_end_;
    HEAP_SIZE = __HeapLimit - __HeapBase;

	/* MOD added SharedSection */
	/* placing SharedSection section at given address: */
	 .SharedSection 0x20027FFC : 
	 { 
	 	KEEP(*(.SharedSection)) /* keep my variable even if not referenced */
	 } > ram 

I have since changed it to this, but I was grasping at straws, and it had no effect on my error:

...snip...
_end = . ;

	_ram_end_ = ORIGIN(ram) + LENGTH(ram) - 5 ; /* MOD was -1 */

	/* Define heap symbols for heap_useNewlib.c */
    __HeapBase = _end;
    __HeapLimit = _ram_end_;
	HEAP_SIZE = __HeapLimit - __HeapBase;

	/* MOD added SharedSection */
	/* placing SharedSection section at given address: */
	 .SharedSection 0x20027FFC :
	 { 
		. = ALIGN(4);
		_sSharedSection = . ;
	 	KEEP(*(.SharedSection .SharedSection.*)) /* keep my variable even if not referenced */
		. = ALIGN(4);
		_eSharedSection = . ;
	 } > ram 

 

The map file produced by building the project has this:

 

                0x200112e0                _end = .
                0x20027ffb                _ram_end_ = ((ORIGIN (ram) + LENGTH (ram)) - 0x5)
                0x200112e0                __HeapBase = _end
                0x20027ffb                __HeapLimit = _ram_end_
                0x00016d1b                HEAP_SIZE = (__HeapLimit - __HeapBase)

.SharedSection  0x20027ffc        0x4 load address 0x0049a3fc
                0x20027ffc                . = ALIGN (0x4)
                0x20027ffc                _sSharedSection = .
 *(.SharedSection .SharedSection.*)
 .SharedSection
                0x20027ffc        0x4 lib_shared/misc_core.o
                0x20027ffc                bootloader_shared_space
                0x20028000                . = ALIGN (0x4)
                0x20028000                _eSharedSection = .

The load address assigned to SharedSection is the same as the address range in the error, but beyond that I am lost.

 

The two major linker differences between this broken version and the previous working are:

1. In the broken one the entire heap section is commented out as I now use heap_useNewlib.c in conjunction with FreeRTOS to manage the heap. 

2. In the broken one there is an additional ".noinit" section used to preserve register information in the event of a hardfault and subsequent reset. 

I don't know if either of these this is the root cause, but felt they should be mentioned.  Neither cause any problems when the SharedSection is removed from the linker file.

 

The bootloader (which does not use heap_useNewlib.c) has the original addition posted above, and runs in debug just fine.

 

Any idea what is going on here?

Is there a better way to accomplish what I am trying to do? 

Last Edited: Tue. May 5, 2020 - 12:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What target is this for? doesn't look like an AVR!

 

and what tools are you using ?

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

What target is this for? doesn't look like an AVR!

Correct, it's an ARM Cortex M4 based chip.  

 

awneil wrote:

and what tools are you using ?

Atmel Studio v7.0.1645 and an Atmel Ice debug tool. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hillridge wrote:
ARM Cortex M4 

So why are you posting in the AVR section ?

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

Hillridge wrote:
ARM Cortex M4 

So why are you posting in the AVR section ?

 

Because this community has almost 200x the activity of the ARM one and I thought this was more of a linker question than an ARM specific question. 

The forum I posted in has the description  "A forum for discussions about compilers and general programming topics not specifically related to a particular microcontroller. "

 

Maybe I just like you guys more too.  I see it's already been moved though ¯\_(ツ)_/¯
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now that the post is on the ARM side, I'll probably get a reply 6 months after I've either figured it out on my own or given up entirely.  Happy to be proven wrong though!