Look in the table below. This is from the map file. ZI data is reported to be 62792 byte, it should be 3414 byte.
Is this a bug?
------ 8< ------------
Image component sizes
Code (inc. data) RO Data RW Data ZI Data Debug Object Name
908 8 0 552 0 0 aes128.o 352 8 0 6 270 0 cobs.o 52 8 0 0 0 0 dma.o 588 58 0 0 0 0 fpga.o 148 12 0 0 0 0 led.o 1556 118 16 8 2056 0 main.o 44 10 0 0 0 0 ram_functions.o 288 38 0 4 64 0 sight_uart.o 76 38 1024 0 1024 0 startup_mk10d10.o 296 56 0 0 4 0 system.o 148 20 0 4 0 0 timer.o
---------------------------------------------------------------------- 4466 374 1120 576 62792 0 Object Totals 10 0 80 0 0 0 (incl. Generated) 0 0 0 2 59374 0 (incl. Padding)
I'm using:
IDE-Version: µVision V5.10.0.2 Copyright (C) 2014 ARM Ltd and ARM Germany GmbH. All rights reserved.
License Information: Marko Prevas Microsoft LIC=D0D8Z-JK152-250EQ-LR7BT-NJ0C2-Q16LU
Tool Version Numbers: Toolchain: MDK-ARM Standard for Freescale Version: 5.10.0.0 Toolchain Path: C:\Keil_v5\ARM\ARMCC\bin\ C Compiler: Armcc.Exe V5.04.0.49 Assembler: Armasm.Exe V5.04.0.49 Linker/Locator: ArmLink.Exe V5.04.0.49 Librarian: ArmAr.Exe V5.04.0.49 Hex Converter: FromElf.Exe V5.04.0.49 CPU DLL: SARMCM3.DLL V5.10.0.0 Dialog DLL: DCM.DLL V1.10.0.0 Target DLL: UL2CM3.DLL V1.152.4.0 Dialog DLL: TCM.DLL V1.14.1.0
The table again (better formatting)
Image component sizes Code (inc. data) RO Data RW Data ZI Data Debug Object Name 908 8 0 552 0 0 aes128.o 352 8 0 6 270 0 cobs.o 52 8 0 0 0 0 dma.o 588 58 0 0 0 0 fpga.o 148 12 0 0 0 0 led.o 1556 118 16 8 2056 0 main.o 44 10 0 0 0 0 ram_functions.o 288 38 0 4 64 0 sight_uart.o 76 38 1024 0 1024 0 startup_mk10d10.o 296 56 0 0 4 0 system.o 148 20 0 4 0 0 timer.o ---------------------------------------------------------------------- 4466 374 1120 576 62792 0 Object Totals 10 0 80 0 0 0 (incl. Generated) 0 0 0 2 59374 0 (incl. Padding)
Ok, bit of a narrow view there. Is there anything else in the .MAP that would suggest what's in the region, or a scatter file that describes a sparse data area?
It looks consistent to me: 270+2056+64+1024+4=62792-59374
Something that was aligned to a 64K boundary (AREA X, DATA,ALIGN=16) could cause padding like that.