We have a DFU bootloader in low memory, configuration data at 0x9000 and operational code at 0xa000. We are using Freescale CodeWarrior 10.6 IDE. We are using the JLink embedded chip that comes on the KwikStik to connect to our own external board (using a header on the KwikStik to connect JTAG on our board).


Every time we debug the operational code (base address at 0xa000), we find that flash memory is zeroed out at least 0x1000 BELOW the program we are loading into flash with JLink (through the debugger) up to the operational code at 0xa000. This is deleting our configuration data in flash memory (0x9000-0x9fff), so it is difficult to debug because we must change the code to return hardcoded values in place of what should be in the configuration area of flash.


I have converted the .elf to a .s using the Freescale utility to confirm there is nothing contained in the .elf file that would be loading below the operational code base address of 0xa000.


I have downloaded and installed the latest JLink driver 5.02f, with exactly the same result as the JLink driver that comes with CW 10.6.

Any thoughts or suggestions on how to resolve this? It seems to be a bug in the JLink software.

Hi Niklas,
1.) Which target device is used on the external board?
We are specifically using the MK51DN512CLL10_LQFP100.


2.) If possible, can you try to reproduce this behavior on an eval board instead of custom hardware?
We are not aware of any eval board that comes with the MK51 processor. The KwikStik comes with a K40, which has the closest pinout to the MK51 that we could find on an eval board. We replaced the MK40 with the MK51 for our initial software development before our boards were ready.


3.) Can you provide us with an ELF-File and / or project for reproduction purposes?
I can't post the .elf on a public forum. I may be able to email you the .elf directly if you can provide your email address. I'll try to reproduce the problem with a test project that I can provide.

I selected the option for CW to output an srec file and then I dumped the address ranges with srec_info.exe (public domain utility):
Format: Motorola S-Record
Header: "IAdapter.hex"
Execution Start Address: 0000D08D
Data: 00A000 - 00A1BB
00A3FE - 0489FF


4.) Can you provide us with the output of J-Link Commander (jlink.exe) [while your J-Link is connected to your PC and the external board is connected to J-Link)
Here is the output from J-Link Commander:temp.txt

Compiled Oct 2 2015 20:52:00
DLL version V5.02f, compiled Oct 2 2015 20:51:34
Firmware: J-Link Lite-FSL V1 compiled Jun 25 2012 16:40:07
Hardware: V1.00
S/N: 430110131
Emulator has Trace capability
VTarget = 3.474V
Info: TotalIRLen = 4, IRPrint = 0x01
Info: Found Cortex-M4 r0p1, Little endian.
Info: FPUnit: 6 code (BP) slots and 2 literal slots
Info: CoreSight components:
Info: ROMTbl 0 @ E00FF000
Info: ROMTbl 0 [0]: FFF0F000, CID: B105E00D, PID: 000BB000 SCS
Info: ROMTbl 0 [1]: FFF02000, CID: B105E00D, PID: 003BB002 DWT
Info: ROMTbl 0 [2]: FFF03000, CID: B105E00D, PID: 002BB003 FPB
Info: ROMTbl 0 [3]: FFF01000, CID: B105E00D, PID: 003BB001 ITM
Info: ROMTbl 0 [4]: FFF41000, CID: B105900D, PID: 000BB9A1 TPIU
Info: ROMTbl 0 [5]: FFF42000, CID: B105900D, PID: 000BB925 ETM
Info: ROMTbl 0 [6]: FFF43000, CID: B105900D, PID: 003BB907 ETB
Info: ROMTbl 0 [7]: FFF44000, CID: B105900D, PID: 001BB908 CSTF
Found 1 JTAG device, Total IRLen = 4:
#0 Id: 0x4BA00477, IRLen: 04, IRPrint: 0x1, CoreSight JTAG-DP (ARM)
Cortex-M4 identified.
Target interface speed: 100 kHz


5.) Can you provide us with an J-Link Logfile of an CW-Debug Session?
I've captured what I can from the CW Console and attached as temp.txt. I couldn't find an option to capture the entire debug session. Do you have instructions of how to capture the entire debug log?


Regards,

Ken

Complete J-Link log file attached.

I used arm-none-eabi-readelf.exe with the -a (all) option to dump the .elf information and may have discovered what may be leading to the write from 0x8000-0xa000.

Look at first line of the "Program Headers" section below that I've colored in blue.

I see the alignment is showing 0x8000, but the only align statements in the .ld file are ALIGN(4).

This is only the beginning of the file. Do you have any thoughts on why the alignment would be 0x8000, and how to change it?

Regards,
Ken


==================================================================================


Here is the beginning of the file:

ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0xd08d
Start of program headers: 52 (bytes into file)
Start of section headers: 55681008 (bytes into file)
Flags: 0x5000002, has entry point, Version5 EABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 6
Size of section headers: 40 (bytes)
Number of section headers: 25
Section header string table index: 22

Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .interrupts PROGBITS 0000a000 002000 0001bc 00 A 0 0 4
[ 2] ._revision PROGBITS 0000a3fe 0023fe 000002 00 A 0 0 2
[ 3] .text PROGBITS 0000a400 002400 038a34 00 AX 0 0 8
[ 4] .ARM.extab PROGBITS 00042e34 03ae34 003050 00 A 0 0 4
[ 5] .ARM ARM_EXIDX 00045e84 03de84 001910 00 AL 3 0 4
[ 6] .init_array INIT_ARRAY 00047794 03f794 0000b8 00 WA 0 0 4
[ 7] .fini_array FINI_ARRAY 0004784c 03f84c 000004 00 WA 0 0 4
[ 8] .data PROGBITS 1fff0200 040200 00119c 00 WA 0 0 512
[ 9] .bss NOBITS 1fff13a0 0493a0 001e70 00 WA 0 0 8
[10] ._user_heap_stack NOBITS 1fff3210 0493a0 00a800 00 WA 0 0 1
[11] .romp PROGBITS 20000000 048000 000024 00 WA 0 0 1
[12] .ARM.attributes ARM_ATTRIBUTES 00000000 048024 000035 00 0 0 1
[13] .debug_info PROGBITS 00000000 048059 0c321d 00 0 0 1
[14] .debug_abbrev PROGBITS 00000000 10b276 0157a1 00 0 0 1
[15] .debug_loc PROGBITS 00000000 120a17 0349d5 00 0 0 1
[16] .debug_aranges PROGBITS 00000000 1553ec 007af0 00 0 0 1
[17] .debug_macinfo PROGBITS 00000000 15cedc 33319a5 00 0 0 1
[18] .debug_line PROGBITS 00000000 348e881 046394 00 0 0 1
[19] .debug_str PROGBITS 00000000 34d4c15 029606 01 MS 0 0 1
[20] .comment PROGBITS 00000000 34fe21b 000079 01 MS 0 0 1
[21] .debug_frame PROGBITS 00000000 34fe294 01bc58 00 0 0 4
[22] .shstrtab STRTAB 00000000 3519eec 000103 00 0 0 1
[23] .symtab SYMTAB 00000000 351a3d8 01a980 10 24 4912 4
[24] .strtab STRTAB 00000000 3534d58 010ac5 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)

There are no section groups in this file.

Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x00008000 0x00008000 0x021bc 0x021bc R 0x8000
LOAD 0x0023fe 0x0000a3fe 0x0000a3fe 0x00002 0x00002 R 0x8000
LOAD 0x002400 0x0000a400 0x0000a400 0x3d450 0x3d450 RWE 0x8000
LOAD 0x040200 0x1fff0200 0x00047850 0x0119c 0x0119c RW 0x8000
LOAD 0x048000 0x20000000 0x000489ec 0x00024 0x00024 RW 0x8000
LOAD 0x0493a0 0x1fff13a0 0x000489f0 0x00000 0x0c670 RW 0x8000

Section to Segment mapping:
Segment Sections...
00 .interrupts
01 ._revision
02 .text .ARM.extab .ARM .init_array .fini_array
03 .data
04 .romp
05 .bss ._user_heap_stack

There is no dynamic section in this file.

There are no relocations in this file.

Unwind table index '.ARM' at offset 0x3de84 contains 802 entries:

0xb280 <selfrel_offset31>: 0x1 [cantunwind]

0xb324 <restore_non_core_regs>: 0x80a8b0b0
Compact model index: 0
0xa8 pop {r4, r14}
0xb0 finish
0xb0 finish

0xb37c <get_eit_entry>: 0x8002a9b0
Compact model index: 0
0x02 vsp = vsp + 12
0xa9 pop {r4, r5, r14}
0xb0 finish

0xb41c <_Unwind_decode_typeinfo_ptr.isra.0>: 0x1 [cantunwind]

Niklas,
I found and resolved the problem.

I needed to add the '-n' option to the GCC linker in order to remove the default program segment page size, which is 0x8000 by default.

Thank you for your help!

Regards,
Ken