Link errors not reporting

[davidsherman]

We are using KDS 3.0.0, and we are seeing something odd.  We have the same .cproject, source, and linker files, but when we build, I see an error reporting that the code configuration exceeded the flash space, but my colleague does not.  If it's a clue, he can change his optimization level to none (-O0) and he does see the error, although it still exceeds the available flash space even with -Os.  Is there some setting we should be looking for to make sure the error is reporting?

[davidsherman]

Well, we figured out what was different between us; I had a configuration switch that was different making my image significantly larger.  Now I don't see the overflow and our images are the same size, however, it's interesting that there's still a hangup that has us puzzled.  According to the map file, we see:

.preinit_array  0x0001fe50        0x0
                0x0001fe50                PROVIDE (__preinit_array_start, .)
 *(.preinit_array*)
                0x0001fe50                PROVIDE (__preinit_array_end, .).preinit_array  0x0001fe50        0x0
                0x0001fe50                PROVIDE (__preinit_array_start, .)
 *(.preinit_array*)
                0x0001fe50                PROVIDE (__preinit_array_end, .)

.init_array     0x0001fe50        0x4
                0x0001fe50                PROVIDE (__init_array_start, .)
 *(SORT(.init_array.*))
 *(.init_array*)
 .init_array    0x0001fe50        0x4 c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/armv6-m/crtbegin.o
                0x0001fe54                PROVIDE (__init_array_end, .)

.fini_array     0x0001fe54        0x4
                0x0001fe54                PROVIDE (__fini_array_start, .)
 *(SORT(.fini_array.*))
 *(.fini_array*)
 .fini_array    0x0001fe54        0x4 c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/armv6-m/crtbegin.o
                0x0001fe58                PROVIDE (__fini_array_end, .)
                0x0001fe58                ___ROM_AT = .

.mtb            0x1ffff000        0x0
                0x1ffff000                . = ALIGN (0x8)
                0x1ffff000                _mtb_start = .

.init_array     0x0001fe50        0x4
                0x0001fe50                PROVIDE (__init_array_start, .)
 *(SORT(.init_array.*))
 *(.init_array*)
 .init_array    0x0001fe50        0x4 c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/armv6-m/crtbegin.o
                0x0001fe54                PROVIDE (__init_array_end, .)

.fini_array     0x0001fe54        0x4
                0x0001fe54                PROVIDE (__fini_array_start, .)
 *(SORT(.fini_array.*))
 *(.fini_array*)
 .fini_array    0x0001fe54        0x4 c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/armv6-m/crtbegin.o
                0x0001fe58                PROVIDE (__fini_array_end, .)
                0x0001fe58                ___ROM_AT = .

.mtb            0x1ffff000        0x0
                0x1ffff000                . = ALIGN (0x8)
                0x1ffff000                _mtb_start = .

And we would guess from that that the flash image fits within the 128K flash size since it supposedly ends at 0x1fe58.  However, the end of the s-record it generates tells another story:

21402017820A0034028A0034030A003400CA0034060
S21402018814A003401CA0034024A003402CA0034054
S21402019858FE010000F0FF1F4003000000000000A8
S20C0201A8000000000000000048
S80400047186

Apparently there is a problem because we can't debug.  I suspect it can't program the flash because it's actually overflowing even though the map doesn't seem to indicate that.

[BlackNight]

It could be that your error/message parser settings are different. Can you share the message you see in the console view from the build process?

Erich

[davidsherman]

Hi Erich, this is what I see in the console:

'Building target: C3MainPM.elf'
'Invoking: Cross ARM C++ Linker'
arm-none-eabi-g++ -mcpu=cortex-m0plus -mthumb -Os -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections  -g3 -T "C:/KDSProjects/Git/C3MainPM/Project_Settings/Linker_Files/ProcessorExpert.ld" -Xlinker --gc-sections -L"C:/KDSProjects/Git/C3MainPM/Project_Settings/Linker_Files" -L"C:\KDSProjects\Git\KELibs\ServiceLib\Debug" -L"C:\KDSProjects\Git\KELibs\KEDeviceLib\Debug" -L"C:\KDSProjects\Git\KELibs\KEDriverLib\Debug" -Wl,-Map,"C3MainPM.map" --specs=nano.specs -specs=nosys.specs -o "C3MainPM.elf"  ./Static_Code/System/CPU_Init.o ./Static_Code/System/Peripherals_Init.o ./Static_Code/System/Vectors.o  ./Sources/C3.o ./Sources/C3Custom.o ./Sources/C3CustomStrings.o ./Sources/C3DTCMaps.o ./Sources/Events.o ./Sources/SpTables.o ./Sources/UiMenus.o ./Sources/UiMenusCustom.o ./Sources/exit.o ./Sources/main.o ./Sources/mqx_tasks.o  ./Project_Settings/Startup_Code/startup.o  ./MQXLITE/psp/cortex_m/core/M0/boot.o ./MQXLITE/psp/cortex_m/core/M0/dispatch.o  ./MQXLITE/psp/cortex_m/cortex.o ./MQXLITE/psp/cortex_m/int_gkis.o ./MQXLITE/psp/cortex_m/int_inst.o ./MQXLITE/psp/cortex_m/int_kisr.o ./MQXLITE/psp/cortex_m/int_pvta.o ./MQXLITE/psp/cortex_m/int_unx.o ./MQXLITE/psp/cortex_m/int_vtab.o ./MQXLITE/psp/cortex_m/int_xcpt.o ./MQXLITE/psp/cortex_m/mem_zero.o ./MQXLITE/psp/cortex_m/psp_iinit.o ./MQXLITE/psp/cortex_m/psp_supp.o ./MQXLITE/psp/cortex_m/psp_tiad.o ./MQXLITE/psp/cortex_m/psp_tinm.o ./MQXLITE/psp/cortex_m/psp_tipr.o ./MQXLITE/psp/cortex_m/psp_tisu.o ./MQXLITE/psp/cortex_m/sc_irdyq.o ./MQXLITE/psp/cortex_m/stack_bu.o ./MQXLITE/psp/cortex_m/stack_de.o ./MQXLITE/psp/cortex_m/stack_st.o  ./MQXLITE/kernel/idletask.o ./MQXLITE/kernel/int.o ./MQXLITE/kernel/klog.o ./MQXLITE/kernel/lwevent.o ./MQXLITE/kernel/lwlog.o ./MQXLITE/kernel/lwmem.o ./MQXLITE/kernel/lwmsgq.o ./MQXLITE/kernel/lwsem.o ./MQXLITE/kernel/lwtimer.o ./MQXLITE/kernel/mqx_utils.o ./MQXLITE/kernel/mqxlite.o ./MQXLITE/kernel/mutex.o ./MQXLITE/kernel/qu_test.o ./MQXLITE/kernel/sched.o ./MQXLITE/kernel/task.o ./MQXLITE/kernel/time_ticks.o  ./MQXLITE/config/task_template_list.o  ./Generated_Code/Cpu.o ./Generated_Code/MQX1.o ./Generated_Code/PE_LDD.o ./Generated_Code/Pins1.o ./Generated_Code/SystemTimer1.o  ./.metadata/.plugins/org.eclipse.cdt.make.core/specs.o   -lServiceLib -lKEDeviceLib -lKEDriverLibs
c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/bin/ld.exe: C3MainPM.elf section `.text' will not fit in region `m_text'
c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/bin/ld.exe: region `m_text' overflowed by 1352 bytes
collect2.exe: error: ld returned 1 exit status
make: *** [C3MainPM.elf] Error 1

I checked the error parser options for both of our environments, they are the same.  We have GNU gmake Error parser 7.0, pushd/popd CWD locator, GNU gcc/g++ error parser, GNU Assembler error parser, and GNU Linker error parser checked.

[BlackNight]

Hi David,

I know that some linker error messages might not be recognized by the error parser if the message is not formatted correctly.

I tried it on my side, and it gets properly recognized:

These are my error parsers:

It might be very well that your KDS 3.0.0 version causes a problem because of the different make utility? The difference is in the KDS 'bin' folder (see Solving the 8192 Character Command Line Limit on Windows | MCU on Eclipse ). I have attached for you the 'bin' folder of KDS V3.2.0. You can give it at try (rename your 'bin' and use the attached one), maybe this helps?

Erich

[davidsherman]

Thanks Erich, but we are both using KDS 3.0.0.  Now, on a somewhat related note, I have KDS 3.2.0 installed in a separate directory, could that make a difference?  I ask, because interestingly enough, I tried replacing the make utilities in 3.2.0 with the updated ones from your article, and it had a noticeable improvement on a separate issue I had with that one.  I have been having a problem with progressively slower builds in KDS 3.2 (different project entirely) which got slower and slower the more I built, to where the whole computer would just drag along until I rebooted.  Building that project would go from taking 10-20 seconds to taking 10-20 MINUTES to build for no apparent reason.  I can try having my colleague install these build utilities; perhaps when I installed KDS 3.2 then 3.0.0 was latching on to the ones in 3.2?  I can try having my colleague install the updated utilities to see if it fixes his issue.

[BlackNight]

Hi David,

KDS V3.0.0 and 3.2.0 have no interconnections, so you can keep them separate.

About that slow-down issue: I have seen a report in the forum about this, but I think I never saw a resolution or root cause. I do know that some firewalls and virus scanners can slow down things: they see that the compiler gets called again and again in short order, and think it is a virus and starts to slow it down. The other reason could be that the build/make utility got infected and is doing other things and slowing down the build process.

Erich