Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Use first flash sectors for user data?
I'm using a STM32F411VET6, which have 8 flash sectors. The first 4 sectors are 16 kbyte each.
I'd like to use two of these sectors for user parameters, preferably so that when downloading the application when debugging using the STLINK/V2 dongle, those user parameters are not overwritten.

I've done some initial attempts and modified the linker script so that ROM start from sector 2, like this:

/* Memory Spaces Definitions */
    ROM  (rx) : ORIGIN = 0x08008000, LENGTH = 480K
    RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K

I can see in map-file that code is now placed starting from sector 2.

I also modify STLINK/V2 debug interface setting in EmBitz, "Vector table start" to 0x08008000,
and in system_stm32f4xxx.c I set vector table offset to:

#define VECT_TAB_OFFSET  0x8000

But, it doesn't work. When i start the debugger, it downloads the program, but I am unable to start it.

What am I missing?
Is it possible at all?

I'm using EmBitz 1.11
OK, so the debugger is no completely dead.

The application is loaded starting from sector 2:

GDB Program Transfer:
EraseFlash - Sector:0x2 Size:0x4000
enabling 32-bit flash writes
WriteFlash - Size: 16384 @ 0x08008000
EraseFlash - Sector:0x3 Size:0x4000
enabling 32-bit flash writes
WriteFlash - Size: 16384 @ 0x0800C000
EraseFlash - Sector:0x4 Size:0x10000
Loading section .text, size 0x39e78 lma 0x8008000
Loading section .ARM.exidx, size 0x8 lma 0x8041e78
Loading section .data, size 0x214 lma 0x8041e80
Start address 0x8008000, load size 237716

Now when looking in Disassembly window, I can see pc is standing in the Reset_Handler.
I can single step there, BUT, it is executing at wrong address. 
pc is 0x08001B84 when it should be 0x08009b84 (according to the map-file, Reset_Handler is located at 0x08009b84).
I.e. the 0x00008000 offset is missing. 

Why is this happening, when gdb seems to load the program to the correct location?
OK, I figured out a workaround.

I keep the interrupt vectors in the first flash sector, so I don't have to sort out the relocation problems.
Then I use sector 1 and 2 for user parameters, and sector 3 and onwards for .text, .data, .bss etc.

So this is all solved in the linker script:

  SECT0  (rx) : ORIGIN = 0x08000000, LENGTH = 16K
  SECT1  (rx) : ORIGIN = 0x08004000, LENGTH = 16K
  SECT2  (rx) : ORIGIN = 0x08008000, LENGTH = 16K
    ROM  (rx) : ORIGIN = 0x0800C000, LENGTH = 512K-48K
    RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K

    .sector0 :
        /* Interrupt vectors moved from output section .text to this section */

        /* Flash sector 0 is 16kbyte, so lets add more stuff */
    } > SECT0

    .text :


        /* .ctors */

So I have created a "hole" for sector 1 and 2. I can see that debugger does not touch sector 1 and 2 when loading the program into flash.
Sector 0 now holds the interrupt vectors. Because the interrupt vectors don't fill up the whole 16 kbyte sector, there is room left for adding various code in there, in case I run low on flash memory.
This sounds a good idea - thanks for sharing.
Cheers, Ollie

Forum Jump:

Users browsing this thread: 1 Guest(s)