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?
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.
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
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.
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
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.
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