variables initialization table badly loaded with LPCXpresso-6 (hole in binary file)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mjulier on Wed Nov 06 03:06:13 MST 2013
Hello,

I am using LPCXpress with LPC-Link and an LPC1769 CPU.
With LPCXpresso-5, it works correctly, except on the first use of LPC-Link (I have to disconnect it, connect it again, then it works).

With LPCXpresso-6 however, the initialization table of the static variables are not downloaded into the CPU. But the debugger works.

The HEX file is good: it is strictly identical to the file produced with LPCXpresso-5, and works when used independently.

Here is the relevant part of the HEX file, notice that there is a hole at 0x1962c-0x1962f due to alignment

:020000021000EC    <= goes to 0x10000
(...)
:1095F000660000000000003F000000BFD1F71737F1
:10960000D1F717B78071313F807131BF6937AC3105
:1096100068212233B40F14336821A2333863ED3E3E
:0C962000DA0F493F5E987B3FDA0FC93F2C         <= 0x1962c = end of code, before alignment
:1096300028000000000080004000C0002000A000C2 <= 0x19630 = _etext = start of table
:109640006000E000100090005000D0003000B0003A
:109650007000F000080088004800C8002800A8003A
:109660006800E800180098005800D8003800B800DA

And here is the content, as read by Flash Magic, notice junk starting from 0x1962c
[img=425x110]http://mjulier.free.fr/fichiers/mem.png[/img]

There is another hole in my hex file, but for a whole flash block (0x1000-0x1FFF), and that one seems not to cause problem.

Here is the debug log, with no obvious error (the "invalid reset vector" is also found of LPCXpresso-5 and causes no problem, and the table contains indeed 1632 bytes starting from 0x19630, unfortunately these byte are not correctly loaded:

LPCXpresso Debug Driver v6.0 (Oct 16 2013 02:04:27 - crt_emu_cm3_nxp build 1212)
Looked for chip XML file in E:/nxp/LPCXpresso_6.1.0_164/lpcxpresso/bin/LPC1769.xml
Looked for vendor directory XML file in E:/nxp/LPCXpresso_6.1.0_164/lpcxpresso/bin/nxp_directory.xml
Found generic directory XML file in E:/nxp/LPCXpresso_6.1.0_164/lpcxpresso/bin/crt_directory.xml
Emu(0): Conn&Reset. DpID: 2BA01477. Info: HID64HS12
SWD Frequency: 3000 KHz. RTCK: False. Vector catch: False.
Packet delay: 0  Poll delay: 0.
Loaded LPC175x_6x_512.cfx: LPC175x_6x (512K) Apr 22 2013 12:14:31  On-chip Flash Memory
NXP: LPC1769  Part ID: 0x00000000
Connected: was_reset=true. was_stopped=false
v LPCXpresso Free License - Download limit is 256K
Writing 2744 bytes to 0000 in Flash (assumed clock: 4.0MHz)
Erased/Wrote page  0-0 with 2744 bytes in 533msec
Flash write Done
Writing 95788 bytes to 2000 in Flash (assumed clock: 4.0MHz)
Erased/Wrote page  2-9 with 32768 bytes in 4092msec
Erased/Wrote page  10-16 with 24576 bytes in 3072msec
Erased/Wrote page  16-16 with 32768 bytes in 2857msec
Erased/Wrote page  17-17 with 5676 bytes in 704msec
Flash write Done
43: Invalid Reset vector - out of range
Writing 1632 bytes to 19630 in Flash (assumed clock: 4.0MHz)
Erased/Wrote page  17-17 with 1632 bytes in 1002msec
Flash write Done
nSRST assert (if available)
Executing in bootloader.

Stopped: Breakpoint #1

I think that there is something here that should be fixed!

Miguel

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mjulier on Wed Nov 06 07:42:49 MST 2013
My motivations were:

1) leaving an unused block for storing some configuration. The first blocks are smaller, so I needed a gap at 0x1000-0x1FFF, and to put parts of the code below 0x1000 and the rest after 0x2000. The hole is the section named ".bloc1flash", and it is not loaded because I want it not to be erased when I reprogram the CPU.

2) knowing which is the last byte used in the flash, because I store some data after the end. Not the end of the code, but the end of everything stored in the flash. This the symbol "_endflash".

3) for some reason, in a previous version, there was a problem that I could track to be caused by the data section not to be aligned on 8 bytes. I don't remember the exact reason, but I have to reason to worry about possibly losing 4 bytes.

Anyway, I can solve my problem, but the fact is that the linker produces some code and the debugger does not put all of it into the CPU in LPCXpresso-6, while it puts on the debug log that it has done just what is needed, and there is no problem in LPCXpresso-5 with exactly the same code.

Thanks

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Wed Nov 06 07:17:22 MST 2013
What exactly are you trying to achieve with this rather strange linker script???

And why do you seem to think that you need to align the load address of the data section on an 8 byte boundary. There should be no need to do this.

Regards,
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mjulier on Wed Nov 06 06:29:35 MST 2013
I found a work-around, by modifying the .ld file for removing the hole: there is a hole because I use a section just for aligning, and the section is removed if it contains only alignment, even with "FILL".

Here are the files in the configuration that cause the problem, in a Zip archive:
1) the AXF file with causes this problem
2) the Map file
3) the .ld files. Note that Pegasus.ld is the main file, and that a solution is obtained by uncommenting at line #115 so that the section does not contain only alignment.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Wed Nov 06 04:19:40 MST 2013
Please post:

[list=1]
[*]The AXF that you are loading
[*]The map file generated by the linker when building that AXF file
[*]The linker script files (.ld) used to build the AXF file
[/list]

These will typically all be found in the Debug/Release directory of your project

Regards,
LPCXpresso Support