How do I get rid of a memory hole(in cortexm0plus)?

There are a few linkers that can work with split output sections automatically, but it is not common practice on toolchains for bigger processors (because it is not often needed, and it is combinatorially hard to do optimally). Your best bet is probably to handle it manually

- figure out how much space you have free, make a code section that you put there in the linker, and assign some read-only data table or function to that section explicitly (with the __attribute__((section)) compiler attribute).

Il giorno domenica 30 ottobre 2016 09:29:30 UTC+1, Johann Klammer ha scritto:

You can delete the . = 0x400; line, so .fconf will be just after the .isr_vector_noncore section. But then the .fconf will not be at a fixed address so it really depends how you access the .fconf bytes in your code. There is a way to know the starting (and ending) address of every section, check the linker file manual. The best (and easiest) thing I think is is to put them at a fixed address, but at the end of the flash.

Bye Jack

The "fconf" section here must be at that specific address. Although the OP doesn't say so, I expect this is a Freescale/NXP Kinetis microcontroller. The microcontroller uses the configuration at that specific address to determine things like flash security.

o:

I supposed so. But if I remember correctly the place is not fixed and can be changed.

you should be able to to something like:

__start_fconf = .; #this is the address where fconf begins KEEP(*(.fconf)) __end_fconf = .; #this is the address after the end of fconf

maybe some ALIGN() before or after is needed. And use __start_fconf as address in C code to access the needed bytes.

For more info (for example):

Bye Jack

Certainly you can use the linker file to place the flash configuration segment somewhere else. But then it will not work as the flash configuration - because the Kinetis reads the values are addresses 0x400 to 0x40f at reset, with a total disregard for whatever linker file you use. The issue is the Kinetis hardware, not the linker file.

o:

If it's HW then ok, didn't know that. If on the other hand is a value hardcoded in the startup routine then it ca n be changed...

Bye Jack

can be changed...

just checked, it's really HW. anyway I find odd that they put it at 0x400.. .

Bye Jack

Well, the interrupt vectors are hard-coded at 0x0, so 0x400 is the start of the next 1K block that was available.

The idea works quite well, except for one mind-bogglingly stupid decision. Erasing that area (setting it all to 0xff) locks the device and its flash. To /unlock/ it, so that you can program the thing with real code, you have to first program byte 0x40f to 0xfe. It is an insane idea that makes it easy to accidentally brick your devices if you are using simple standard ARM JTAG tools, and offers no benefits whatsoever.

Apart from that, the Kinetis devices are very nice chips.