Re: [OpenOCD-user] Relocating an stm32f407 image to 0x00000000 - no flash bank found

[Christoph K. <ku...@ku...>]

Thanks for helping.

I now tried with the following kernel.ld file:

MEMORY
{
        FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 1024K
        FLASH_ALIAS (rx)  : ORIGIN = 0x00000000, LENGTH = 1024K
        CCMRAM (rw) : ORIGIN = 0x10000000, LENGTH = 64K
        SRAM (rwx)  : ORIGIN = 0x20000000, LENGTH = 128K
}

SECTIONS
{
        .text   : {
                    flashend = 0x00100000 ;
                    ccmbgn   = 0x10000000 ;
                    ccmend   = 0x10010000 ;
                    srambgn  = 0x20000000 ;
                    sramend  = 0x20020000 ;
                    *(.text)
                  } > FLASH_ALIAS AT > FLASH
        .bss    : { *(.bss)  } > CCMRAM
        .sram   : { *(.sram) } > SRAM
}


$ arm-none-eabi-objdump -h ku.elf

ku.elf:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000005c0  00000000  08000000  00000074  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .bss          00000d34  10000000  10000000  00000634  2**2
                  ALLOC
  2 .ARM.attributes 00000025  00000000  00000000  00000634  2**0
                  CONTENTS, READONLY
  3 .debug_line   000000de  00000000  00000000  00000659  2**0
                  CONTENTS, READONLY, DEBUGGING
  4 .debug_info   00000041  00000000  00000000  00000737  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .debug_abbrev 00000014  00000000  00000000  00000778  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_aranges 00000020  00000000  00000000  00000790  2**3
                  CONTENTS, READONLY, DEBUGGING
$ 

Now I’m still getting this:

(gdb) mon flash write_image erase ku.elf
failed erasing sectors 0 to 0
auto erase enabled
(gdb) 

but omitting the „erase“ works. Actually don’t know whether flashing this way is required at all. Thought that flashing occurs automatically
when the load image (.elf) has changed.

I still can’t get, what the exact steps are to start the debugee. Assumed I have the following in my .gdbinit:

set mem inaccessible-by-default off
file ku.elf
tar extended-remote :4242

With openOCD startet, I’m getting the following:
$ ./GDB
GNU gdb (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 8.2.50.20181213-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
rstHandler () at ku.s:287
287	1:	bl	initSys			

Obviously something is still „sticking“? A bp still active?

(gdb) d
(gdb) 

No. Doesn’t seem so. Now I’m setting a BP right at the first instruction of my reset code.

(gdb) b rstHandler
Breakpoint 1 at 0x432: file ku.s, line 275.
(gdb) s
halted: PC: 0x00000470
initSys () at ku.s:499
499		cpsid	i			
(gdb) 

Actually I was expecting that the debugee starts and stops at rstHandler: but some history still seems to be active.
Is the debugee already running?

What are the exact steps to do a fresh start of the debugee and step into my program? 


Thanks in advance,

Christoph


> Am 26.05.2021 um 10:55 schrieb Andreas Fritiofson <and...@gm...>:
> 
> 
> 
> On Wed, May 26, 2021 at 10:35 AM Paul Fertser <fer...@gm... <mailto:fer...@gm...>> wrote:
> Hi,
> 
> On Wed, May 26, 2021 at 10:09:10AM +0200, Christoph Kukulies wrote:
> > How can I tweak OpenOCD of configure it such that I can flash .elf program that
> > are relocated to 0x00000000?
> 
> Have you tried defining a "virtual" flash bank? It's documented in the
> User manual, please give that a spin.
> 
> 
> You could also link the program such that LMA=0x08000000 and VMA=0x00000000, which is more true to reality. For example like this:
> 
> .text { ... } > FLASH_ALIAS AT> FLASH
> 
> with an additional memory region
> 
> FLASH_ALIAS (rx)  : ORIGIN = 0x00000000, LENGTH = 1024K
> 
> This should work without changes to the openocd config, although I haven't tried this specific use-case before.
> 
> /Andreas