KDS Linker script section overlap

[romainbazile]

Hey everyone,

I got some troubles with the latest version of the 1.0.2 version of the Kinetis Connectivity Software.

More specifically, I'm trying to compile the host_controlled_device_freertos_frdmkw24 demo, for use with a custom board using an i.MX6UL processor. (This error also happens with the hcd_ota_server example).

I run into a snag with the linker:

/usr/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/bin/ld: section .dummy VMA [000000001ffffffb,0000000020000002] overlaps section .bss VMA [000000001fff8938,0000000020006507]

This happens whether I set gUseBootloaderLink_d to 1 or to 0 in the pre-build step, so I do not believe it's linked to this.

Apparently, a dummy section is generated in the linker file by a script. However, as the error says, there is a section overlap.

The only way to get rid of this is to change the script a:

MKW2xD_ConnSw_1.0.2/middleware/wireless/framework_5.0.5/Common/devices/MKW24D5/gcc/MKW24D512xxx5_connectivity.lld

and to remove the part about the dummy section.

Apparently, this section is there to

/* [...] prevent the linker from placing any variables across the SRAM_L to SRAM_U boundary */

So I'm not sure it's a great idea to remove it.

Any thoughts on what could be causing this, and more importantly how to solve this problem?

I'm using KDS 3.2.0, in a Linux, with the latest arm-gcc toolchain (not the one from KDS, but the problem is the same when I use this one).

[gerardo_rodriguez]

Hi Romain,

I am trying to set up a Linux environment to replicate your issue. Can you share which Linux distribution and version are you using?

The demo you are trying to compile is the default demo with no modifications, right?

Regards,
Gerardo

[romainbazile]

I'm using Manjaro (an Arch Linux derivative), latest up to date version (it's a rolling release).

I have also installed the latest GNU Arm tools (6-2017-q1-update), and using either this version or the default one included with KDS.

This is the default project cloned with the tool provided in the Thread stack (v1.0.2).

I have also tried with MCUXPresso (and it's working well, except for that glitch with the linker).

[romainbazile]

So I checked a little around, and stumbled upon several questions posted around here.

Notably, this post ( Why is SRAM split, and what does it mean?  ) and this one ( Best way to deal with split RAM configuration on Kinetis K series?  ).

From what I understood, the problem lies in having a variable crossing the limit, where the read would fail.

BUT

it looks like the .bss section is already aligned on 4 bytes:

  .bss :
  {
    /* This is used by the startup in order to initialize the .bss section */
    . = ALIGN(4);
    __START_BSS = .;
    __bss_start__ = .;
    *(.bss)
    *(.bss*)
    . = ALIGN(512);
    USB_RAM_START = .;
    . += USB_RAM_GAP;
    *(COMMON)
    . = ALIGN(4);
    __bss_end__ = .;
    __END_BSS = .;
  } > DATA_region

In that case we would be safe, however, it seems like the :

. = ALIGN(4);

is arriving a bit late.

I manage to compile by removing the dummy section though. So maybe, maybe... I'm fine?

Anyway, some light is appreciated.

[romainbazile]

I want to yell stupid at myself. Since, obviously, the command I thought was aligning the section, only aligns the address.

Anyway, I've check the map file to try and find what was sitting at the boundary of 0x2000000. It appears it's the freertos heap.

Since the heap is going to be used by a lot of things (and especially not necessarily 4-bytes aligned variables), I reckon this is a problem.

Any thoughts or ways going forward?

[gerardo_rodriguez]

Hi Romain,

I believe you are correct, the gcc linker is placing data from the .bss section in the SRAM boundary and could be a problem if a misaligned variable stored in this boundary is accessed. 

I have reported this issue to the development team and will update on this thread the status of this issue.

Thank you,
Gerardo

[romainbazile]

Hi Gerardo,

Do you have any news from the dev team on this front?

Sincerely,

Romain

[gerardo_rodriguez]

Hello Romain,

The development team has provided me with a new linker file and a startup file to fix this issue. You can find this files attached in this reply.

The fix is supposed to split the RAM in two segments and configure the linker file to place variables in sections placed in declared segments. One section could remain as default, the second section can contain large variables as the framework memory blocks (memHeap).

The startup file was updated to clear the new bss section placed in the first RAM segment.

This is a quick fix and needs to be verified carefully. We performed some tests and have had no issues so far.

Let me know if this fix works on your side.

Regards,
Gerardo

[gerardo_rodriguez]

Hello Romain,

Sorry for the late response.

We are still running tests on this issue and haven’t found problems so far. I will update you if we find something.

Regards,

Gerardo

[romainbazile]

Hi Gerardo,

Any update on this subject?

We are almost ready to ship our product and we would like to make sure this won't cause any problems in the future (even if in our testing no problem was found yet).

Sincerely,

Romain

[romainbazile]

Great, thanks a lot!

How long do you think it will take?

I also found out that this problem also appears on other examples, for example for the router eligible device example for USB-KW24D512.

The same original error appears:

section .dummy VMA [000000001ffffffb,0000000020000002] overlaps section .bss VMA [000000001fff8a80,0000000020005cf7]

As well as a different one when I try to remove the dummy section:

section m_usb_bdt VMA [0000000020005800,00000000200059ff] overlaps section .bss VMA [000000001fff8a80,0000000020005cf7]

It looks like the linker is attempting to do the same thing as for the first error.

Here are the relevant map fragments for these builds:

 .bss.ucHeap    0x000000001fffc2fc     0x4400 ./freertos/heap_4.o
 .bss.xBlockAllocatedBit
                0x00000000200006fc        0x4 ./freertos/heap_4.o

[...]

 .bss.heap_end.4116
                0x00000000200057f8        0x4 /usr/arm-none-eabi/lib/thumb/v7e-m/libnosys.a(sbrk.o)
                0x0000000020005800                . = ALIGN (0x200)
 *fill*         0x00000000200057fc        0x4
                0x0000000020005800                USB_RAM_START = .
                0x0000000020005c00                . = (. + USB_RAM_GAP)
 *fill*         0x0000000020005800      0x400
 *(COMMON)
 COMMON         0x0000000020005c00       0xb8 ./middleware/wireless/nwk_ip_1.2.1/core/lib/thread/thread_gcc_cm4.a(thread_manager.o)
                0x0000000020005c00                mThreadInstance
 COMMON         0x0000000020005cb8        0x4 ./middleware/wireless/nwk_ip_1.2.1/core/lib/thread/thread_gcc_cm4.a(meshcop.o)
                0x0000000020005cb8                gThrInstId
 COMMON         0x0000000020005cbc        0x4 ./middleware/wireless/nwk_ip_1.2.1/core/lib/thread/thread_gcc_cm4.a(meshcop_utilities.o)
                0x0000000020005cbc                mpBrIpAddr
 COMMON         0x0000000020005cc0        0x1 ./middleware/wireless/nwk_ip_1.2.1/core/lib/thread/thread_gcc_cm4.a(coap.o)
                0x0000000020005cc0                mCoapRetransTimer
 *fill*         0x0000000020005cc1        0x3
 COMMON         0x0000000020005cc4       0x30 ./middleware/wireless/nwk_ip_1.2.1/core/lib/thread/thread_gcc_cm4.a(sixlowpan_tbl.o)
                0x0000000020005cc4                mTxNormalQueue
                0x0000000020005cd0                mTxPriorityQueue
                0x0000000020005cdc                mRxFragQueue
                0x0000000020005ce8                mIndTxQueue
 COMMON         0x0000000020005cf4        0x4 /usr/arm-none-eabi/lib/thumb/v7e-m/libg_nano.a(lib_a-reent.o)
                0x0000000020005cf4                errno
                0x0000000020005cf8                . = ALIGN (0x4)
                0x0000000020005cf8                __bss_end__ = .
                0x0000000020005cf8                __END_BSS = .

.heap           0x0000000020005cf8        0x0
                0x0000000020005cf8                . = ALIGN (0x8)
                0x0000000020005cf8                __end__ = .
                0x0000000020005cf8                PROVIDE (end, .)
                0x0000000020005cf8                __HeapBase = .
                0x0000000020005cf8                . = (. + 0x0)
                0x0000000020005cf8                __HeapLimit = .

.stack          0x0000000020005cf8      0x400 load address 0x000000000004ec78
                0x0000000020005cf8                . = ALIGN (0x8)
                0x00000000200060f8                . = (. + 0x400)
 *fill*         0x0000000020005cf8      0x400

m_usb_bdt       0x0000000020005800      0x200
 *(m_usb_bdt)
 m_usb_bdt      0x0000000020005800      0x200 ./usb/device/source/khci/usb_device_khci.o
                0x0000000020005a00                USB_RAM_BDT_END = .

[...]

.dummy          0x000000001ffffffb        0x8
                0x0000000020000003                . = (. + 0x8)
 *fill*         0x000000001ffffffb        0x8 90909090

Cheers,