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:
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).
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?
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).
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.
it looks like the .bss section is already aligned on 4 bytes:
/* This is used by the startup in order to initialize the .bss section */
. = ALIGN(4);
__START_BSS = .;
__bss_start__ = .;
. = ALIGN(512);
USB_RAM_START = .;
. += USB_RAM_GAP;
. = 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.
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?
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.
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.
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.
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).
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
0x00000000200006fc 0x4 ./freertos/heap_4.o
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 0x0000000020005c00 0xb8 ./middleware/wireless/nwk_ip_1.2.1/core/lib/thread/thread_gcc_cm4.a(thread_manager.o)
COMMON 0x0000000020005cb8 0x4 ./middleware/wireless/nwk_ip_1.2.1/core/lib/thread/thread_gcc_cm4.a(meshcop.o)
COMMON 0x0000000020005cbc 0x4 ./middleware/wireless/nwk_ip_1.2.1/core/lib/thread/thread_gcc_cm4.a(meshcop_utilities.o)
COMMON 0x0000000020005cc0 0x1 ./middleware/wireless/nwk_ip_1.2.1/core/lib/thread/thread_gcc_cm4.a(coap.o)
*fill* 0x0000000020005cc1 0x3
COMMON 0x0000000020005cc4 0x30 ./middleware/wireless/nwk_ip_1.2.1/core/lib/thread/thread_gcc_cm4.a(sixlowpan_tbl.o)
COMMON 0x0000000020005cf4 0x4 /usr/arm-none-eabi/lib/thumb/v7e-m/libg_nano.a(lib_a-reent.o)
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 0x0000000020005800 0x200 ./usb/device/source/khci/usb_device_khci.o
0x0000000020005a00 USB_RAM_BDT_END = .
.dummy 0x000000001ffffffb 0x8
0x0000000020000003 . = (. + 0x8)
*fill* 0x000000001ffffffb 0x8 90909090