LPC1754 programming bug?

[lpcware]

Content originally posted in LPCWare by eltom2 on Mon Aug 02 03:25:57 MST 2010
hi,

I am writing applications on LPC1754 processor, everything was ok until my application does not exceed 64 Kbytes. When the LPC-Link programmed processor, something strange happens. How  will attempt to reach the address 0x14000 it automatically goes back to  the sector to address 0x10000, and there entered the data that should  be at 0x14000. Has anyone met with this problem, which may be the cause?

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Sat Feb 05 08:56:21 MST 2011

---

Quote: fiosca
It sounds like I have a very similar problem. I'm using LPCXpresso for Windows ver 3.6.0 (Build 253).

After few days where everything was working correctly, I made a small change, built everything again and flashed AXF file. After reset, CPU enters a Hard Fault condition due to the fact that part of the flash memory (problem was located on the latest sector) contains wrong data.

---

First thing to do is try doing a clean build using the current release of LPCXpresso (3.6.2).

If that doesn't help, then a few more details of your system, your application, and the changes you recently made which triggered the problem might gives us a few clues as to what is happening.

Regards,
CodeRedSupport

[lpcware]

Content originally posted in LPCWare by fiosca on Sat Feb 05 08:26:56 MST 2011
It sounds like I have a very similar problem. I'm using LPCXpresso for Windows ver 3.6.0 (Build 253).

After few days where everything was working correctly, I made a small change, built everything again and flashed AXF file. After reset, CPU enters a Hard Fault condition due to the fact that part of the flash memory (problem was located on the latest sector) contains wrong data.

From that moment on, I could not have the system working again. So I tried to generate a BIN file starting from the same AXF file. Flashing the BIN file everything works correctly, flashing the correspondent AXF file system hangs in Hard Fault.

I tried to open BIN file with an hexadecimal editor. When flashing a BIN file, device flash memory matches with the content of the file. If I flash the AXF file, the latest sector of the flash memory used by code contains bogus data.

Actually, it sounds like a problem of LPCXpresso flasher.
Have you ever seen any similar issue?

[lpcware]

Content originally posted in LPCWare by moltke on Mon Oct 18 07:57:56 MST 2010
Sorry, I should have added that:

I'm using LPCXPresso 3.7.2_Beta [Build 80] [24/09/2010] on an Ubuntu 10.04 LTS host, running as a virtual machine under Oracle's VirtualBox on a Debian Linux host :)

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Mon Oct 18 07:50:32 MST 2010
Moltke - in order for us to investigate, please confirm the version of LPCXpresso that you are using.

http://support.code-red-tech.com/CodeRedWiki/FindVersionNumber

[ Current version of LPCXpresso = 3.5.0 ]

Regards,
CodeRedSupport

[lpcware]

Content originally posted in LPCWare by moltke on Mon Oct 18 07:38:33 MST 2010
I'm experiencing a similar problem as described by eltom2.

My project starts at address 0x2000, as there is an 8K USB bootloader code at address 0.

These are the relevant sections in my .axf file, as seen by arm-none-eabi-objdump -h:

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 prog          0000bab2  00002000  00002000  00002000  2**3
                  CONTENTS, ALLOC, LOAD, CODE
  1 .ARM.exidx    00000008  0000dab4  0000dab4  0000dab4  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         0000026c  10000000  0000dabc  00010000  2**2
                  CONTENTS, ALLOC, LOAD, DATA

When I program the flash from the IDE (start a debug session), the 'prog' section is programmed correctly. But the sections '.ARM.exidx' and '.data' are put into flash starting at [COLOR=Red][B]0xD000[/B][/COLOR], while the correct location is 0xDAB4! This destroys the end of the 'prog' section that is already in flash.

Section Idx 1 goes to 0xD000 (instead of 0xDAB4)
Section Idx 2 goes to 0xD008 (instead of 0xDABC)
So the downloader honors the correct order of sections 1 and 2.

Now the same software is compiled with a compiler switch that adds a trace option to the project, and therefore lets code and data sections grow a bit:

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 prog          0000fee0  00002000  00002000  00002000  2**3
                  CONTENTS, ALLOC, LOAD, CODE
  1 .ARM.exidx    00000008  00011ee0  00011ee0  00011ee0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         00000774  10000000  00011ee8  00018000  2**2
                  CONTENTS, ALLOC, LOAD, DATA

Although not fundamentally different from the previous example, this time all sections end up at their correct location in flash.

Obviously I'm using a custom linker script, which I'm attaching for completeness.

/* Describe the available memory blocks */
MEMORY
{
  flash    : ORIGIN = 0x00002000, LENGTH = 504K
  ram      : ORIGIN = 0x10000000, LENGTH = 32K
  ram2     : ORIGIN = 0x2007C000, LENGTH = 16K
  ram3     : ORIGIN = 0x20080000, LENGTH = 16K
}

/* Stack grows downwards from the end of the first (main) RAM block.
 * Keep 32 bytes free for calls to the IAP flash programming functions.
 * Keep another 16 bytes free to work around a GDB issue where it reads
 * beyond the end of the stack.
 */
__stack_end__ = ORIGIN( ram ) + LENGTH( ram ) - 32 - 16;


/* --------------------------------------------------------
 * Libraries
 * --------------------------------------------------------
 */
GROUP(-lgcc -lc)


/* --------------------------------------------------------
 * FreeRTOS -- Definitions for Memory Protection Unit (MPU)
 * --------------------------------------------------------
 */

/* The 'FLASH_segment' will be set to unprivileged read-only access.
 * Include the whole flash address range.
 */
__FLASH_segment_start__ = ORIGIN( flash );
__FLASH_segment_end__   = __FLASH_segment_start__ + LENGTH( flash );

/* The 'SRAM_segment' will be set to unprivileged read/write access.
 * Include the full range of the first RAM block. Access to the other
 * RAM blocks must be allowed on a per task basis!
 */
__SRAM_segment_start__ = ORIGIN( ram );
__SRAM_segment_end__   = __SRAM_segment_start__ + LENGTH( ram );

/* Define the size of the Flash (functions) and RAM (data) regions which are
 * protected for kernel use. The size must be sufficient for the kernel,
 * and it must be a valid MPU region size.
 * VERY IMPORTANT: Make sure that __FLASH_segment_start__ is aligned to
 *                 at least _sizeof_privileged_functions_!
 */
_sizeof_privileged_functions_ = 8K;
_sizeof_privileged_data_      = 512;

/* FreeRTOS assumes that the privileged functions always start at the
 * beginning of the FLASH_segment. We only have to define the end address.
 */
__privileged_functions_end__  = __FLASH_segment_start__ + _sizeof_privileged_functions_;

/* Protected RAM data for kernel use. Make sure to place it at the beginning
 * of the .data section below (We have to assume that this can be initialized
 * RAM, so it cannot be put in the .bss section).
 */
__privileged_data_start__ = ORIGIN( ram );
__privileged_data_end__   = __privileged_data_start__ + _sizeof_privileged_data_;





SECTIONS
{
  prog :
  {
    KEEP(*(.vectors))
    *(privileged_functions)

    . = ALIGN(_sizeof_privileged_functions_);

    *(.text.*)
    *(.text)
    *(.rodata)
    *(.rodata*)
    *(.ARM.extab* .gnu.linkonce.armextab.*)
  } >flash

  /* Ordered library section goes separately. */
  .ARM.exidx :
  {
    *(.ARM.exidx* .gnu.linkonce.armexidx.*)
  } >flash

  __end_of_text__ = .;


  .data :
  {
    __data_start__ = .;
    *(privileged_data)

    . = ALIGN(_sizeof_privileged_data_);

    *(.data)
    *(.data.*)
    __data_end__ = ALIGN(4);
    *(.pRam)        /* TODO: LPCXpresso workaround. see startup.c */
  } >ram AT>flash

  .bss :
  {
    __bss_start__ = .;
    *(.bss.*)
    *(.bss)
    *(COMMON)
    __bss_end__ = ALIGN(4);
  } >ram

  .ram2data :
  {
    __data2_start__ = .;
    __data2_end__ = ALIGN(4);
  } >ram2 AT>flash

  .ram2bss (NOLOAD) :
  {
    __bss2_start__ = .;
    *(.ram2bss)
    __bss2_end__ = ALIGN(4);
  } >ram2

  .ram3data :
  {
    __data3_start__ = .;
    __data3_end__ = ALIGN(4);
  } >ram3 AT>flash

  .ram3bss (NOLOAD) :
  {
    __bss3_start__ = .;
    *(.trace*)
    __bss3_end__ = ALIGN(4);
  } >ram3
}

In both cases the binaries produced by arm-none-eabi-objcopy from the .axf files are perfectly correct.

Any idea?

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Wed Aug 04 20:04:55 MST 2010

---

Quote: eltom2
yes I know, because in order to generate the logs, i deleted my bootloader, so this error appears. I know and understand. My  problem (as I wrote earlier) is associated with the erroneous  programming of the processor when address is above  0x10000

---

This sounds similar to a problem report we received some weeks ago related to sector boundaries when you offset your code in flash. In your case, the sector boundary for the first 32K sector is at 0x10000. Can you provide your binary file for testing? If so, please contact Code Red directly at http://www.code-red-tech.com/contact.php  so we can help resolve the problem.

[lpcware]

Content originally posted in LPCWare by eltom2 on Wed Aug 04 11:23:37 MST 2010

---

Quote: CodeRedSupport
The "Invalid Reset vector - out of range" message is informational, and can be issued for flash operations not at address zero. It's simply telling you that the reset (and other) vector(s) may not be correctly setup.

---

yes I know, because in order to generate the logs, i deleted my bootloader, so this error appears. I know and understand. My  problem (as I wrote earlier) is associated with the erroneous  programming of the processor when address is above  0x10000

[lpcware]

Content originally posted in LPCWare by eltom2 on Wed Aug 04 11:13:26 MST 2010
Please look at the logs carefully. When it comes to sector address 0x14000 suddenly goes back to the sector address 0x10000, and that is the problem.

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Wed Aug 04 10:31:33 MST 2010
Sorry, I'm not sure you asked a question? The stub output from your command-line flash program shows you're programming flash in the first case at address 0, and at address 0x4000 in the second case. Both were successful.

Note the "Executing in bootloader" status message refers to the NXP ISP, not to your bootloader which we know nothing about. The "Invalid Reset vector - out of range" message is informational, and can be issued for flash operations not at address zero. It's simply telling you that the reset (and other) vector(s) may not be correctly setup.

Regards,

CodeRedSupport

[lpcware]

Content originally posted in LPCWare by eltom2 on Wed Aug 04 05:03:53 MST 2010

---

Quote: CodeRedSupport
For unknown reasons, the GNU linker pads zeroes in a loadable section in front of the start of your application code after you offset the load address. Your code still locates correctly,  but the flash programmer sees the zero pad as loadable code/data (per the ELF file program header) and overwrites the flash contents in the first flash sector.

---

Hmm, strange, because for me it does not overwrite the first sectors. Ihex generated file, starting at address 0x4000, so the file is generated correctly.

---

Quote: CodeRedSupport
I've been unsuccessful in finding a way to work around this behavior in  a linker script. As an interim workaround, it should be possible to  post process the .axf file using the 'arm-none-eabi-objcopy.exe' GNU  binary  utility.

Add the following to your project Properties -> C/C++ Build ->  Settings -> Build Steps (tab) -> Post-build steps:

arm-none-eabi-objcopy --input-target=elf32-littlearm   --output-target=binary --change-section-address .text-0x4000 ${BuildArtifactFileName} ${BuildArtifactFileBaseName}.bin;

---

When I make it just as you wrote, arm-none-EABI-objcopy [COLOR=#000000]hang[/COLOR].

---

Quote: CodeRedSupport

This binary file can be programmed to flash in a separate step (i.e. use the debug stub from the command-line):
C:\>crt_emu_cm3_nxp.exe -g -2 -pLPC1754  -load-base=0x4000 -flash-load=<yourfile>.bin

---

[COLOR=#000000]These are the logs from the programming of the address 0x00[/COLOR]

E:\NXP\lpcxpresso_3.4\bin>cd E:\NXP\lpcxpresso_3.4\bin\

E:\NXP\lpcxpresso_3.4\bin>crt_emu_cm3_nxp.exe -wire=hid -g -2 -pLPC1754 -load-ba
se=0x0000 -flash-load=E:\NXP\workspace\Beacon\Debug\Beacon.bin
Pc: (  0) Reading remote configuration
Ni: LPCXpresso Debug Driver v2.0 (Jun 10 2010 11:46:27)
Nc: Looked for chip XML file in E:/NXP/lpcxpresso_3.4/bin/LPC1754.xml

Nc: Looked for vendor directory XML file in E:/NXP/lpcxpresso_3.4/bin/nxp_direct
ory.xml

Nc: Found generic directory XML file in E:/NXP/lpcxpresso_3.4/bin/crt_directory.
xml

Pc: (  5) Remote configuration complete
Pc: ( 30) Emulator Connected
Pc: ( 40) Debug Halt
Pc: ( 50) CPU ID
Nc: NXP: LPC1754  Part ID: 0x25011722
Pc: ( 65) Chip Setup Complete
Nt: Connected: was_reset=false. was_stopped=true
Cr:v Registered license, download limit of 128K
Pc: ( 70) License Check Complete
Nt: Loading binary file 'Beacon.bin' at location 00000000
Nt: Writing 101388 bytes to 0000 in Flash (assumed clock: 4.0MHz)
Pb: 1 of 4 (  0) Writing pages 0-7 at 0x00000000 with 32768 bytes
Ps: (  0) Page  0 at 00000000
Ps: ( 12) Page  0 at 00000000: 4096 bytes
Ps: ( 25) Page  1 at 00001000: 4096 bytes
Ps: ( 37) Page  2 at 00002000: 4096 bytes
Ps: ( 50) Page  3 at 00003000: 4096 bytes
Ps: ( 62) Page  4 at 00004000: 4096 bytes
Ps: ( 75) Page  5 at 00005000: 4096 bytes
Ps: ( 87) Page  6 at 00006000: 4096 bytes
Ps: (100) Page  7 at 00007000: 4096 bytes
Nt: Erased/Wrote page  0-7 with 32768 bytes in 4939msec
Pb: 2 of 4 ( 32) Writing pages 8-15 at 0x00008000 with 32768 bytes
Ps: (  0) Page  8 at 00008000
Ps: ( 12) Page  8 at 00008000: 4096 bytes
Ps: ( 25) Page  9 at 00009000: 4096 bytes
Ps: ( 37) Page 10 at 0000A000: 4096 bytes
Ps: ( 50) Page 11 at 0000B000: 4096 bytes
Ps: ( 62) Page 12 at 0000C000: 4096 bytes
Ps: ( 75) Page 13 at 0000D000: 4096 bytes
Ps: ( 87) Page 14 at 0000E000: 4096 bytes
Ps: (100) Page 15 at 0000F000: 4096 bytes
Nt: Erased/Wrote page  8-15 with 32768 bytes in 5418msec
Pb: ( 64) Writing page 16 at 0x00010000 with 32768 bytes
Ps: (  0) Page 16 at 00010000
Ps: ( 12) Page 16 at 00010000: 4096 bytes
Ps: ( 25) Page 16 at 00011000: 4096 bytes
Ps: ( 37) Page 16 at 00012000: 4096 bytes
Ps: ( 50) Page 16 at 00013000: 4096 bytes
Ps: ( 12) Page 16 at 00010000: 4096 bytes
Ps: ( 25) Page 16 at 00011000: 4096 bytes
Ps: ( 37) Page 16 at 00012000: 4096 bytes
Ps: ( 50) Page 16 at 00013000: 4096 bytes
Ps: ( 62) Page 16 at 00014000: 4096 bytes
Ps: ( 75) Page 16 at 00015000: 4096 bytes
Ps: ( 87) Page 16 at 00016000: 4096 bytes
Ps: (100) Page 16 at 00017000: 4096 bytes
Nt: Erased/Wrote page    16 with 32768 bytes in 4072msec
Pb: ( 96) Writing page 17 at 0x00018000 with 3084 bytes
Ps: (  0) Page 17 at 00018000
Ps: (100) Page 17 at 00018000: 3084 bytes
Nt: Erased/Wrote page    17 with 3084 bytes in 783msec
Pb: (100) Finished writing Flash successfully.
Nt: Flash write Done
Nc: nSRST assert (if available)
Nc: Executing in bootloader.
Nt: Stopped (Was Reset)  [Reset from External]

E:\NXP\lpcxpresso_3.4\bin>PAUSE
Aby kontynuować, naciśnij dowolny klawisz . . .

[COLOR=#000000]These are the logs from the programming of the address 0x4000[/COLOR]

E:\NXP\lpcxpresso_3.4\bin>cd E:\NXP\lpcxpresso_3.4\bin\

E:\NXP\lpcxpresso_3.4\bin>crt_emu_cm3_nxp.exe -wire=hid -g -2 -pLPC1754 -load-ba
se=0x4000 -flash-load=E:\NXP\workspace\Beacon\Debug\Beacon.bin
Pc: (  0) Reading remote configuration
Ni: LPCXpresso Debug Driver v2.0 (Jun 10 2010 11:46:27)
Nc: Looked for chip XML file in E:/NXP/lpcxpresso_3.4/bin/LPC1754.xml

Nc: Looked for vendor directory XML file in E:/NXP/lpcxpresso_3.4/bin/nxp_direct
ory.xml

Nc: Found generic directory XML file in E:/NXP/lpcxpresso_3.4/bin/crt_directory.
xml

Pc: (  5) Remote configuration complete
Pc: ( 30) Emulator Connected
Pc: ( 40) Debug Halt
Pc: ( 50) CPU ID
Nc: NXP: LPC1754  Part ID: 0x25011722
Pc: ( 65) Chip Setup Complete
Nt: Connected: was_reset=false. was_stopped=true
Cr:v Registered license, download limit of 128K
Pc: ( 70) License Check Complete
Nt: Loading binary file 'Beacon.bin' at location 00004000
Nt: Writing 101388 bytes to 4000 in Flash (assumed clock: 4.0MHz)
Pb: 1 of 4 (  0) Writing pages 4-11 at 0x00004000 with 32768 bytes
Ps: (  0) Page  4 at 00004000
Ps: ( 12) Page  4 at 00004000: 4096 bytes
Ps: ( 25) Page  5 at 00005000: 4096 bytes
Ps: ( 37) Page  6 at 00006000: 4096 bytes
Ps: ( 50) Page  7 at 00007000: 4096 bytes
Ps: ( 62) Page  8 at 00008000: 4096 bytes
Ps: ( 75) Page  9 at 00009000: 4096 bytes
Ps: ( 87) Page 10 at 0000A000: 4096 bytes
Ps: (100) Page 11 at 0000B000: 4096 bytes
Nt: Erased/Wrote page  4-11 with 32768 bytes in 5419msec
Pb: 2 of 4 ( 32) Writing pages 12-16 at 0x0000C000 with 32768 bytes
Ps: (  0) Page 12 at 0000C000
Ps: ( 12) Page 12 at 0000C000: 4096 bytes
Ps: ( 25) Page 13 at 0000D000: 4096 bytes
Ps: ( 37) Page 14 at 0000E000: 4096 bytes
Ps: ( 50) Page 15 at 0000F000: 4096 bytes
Ps: ( 62) Page 16 at 00010000: 4096 bytes
Ps: ( 75) Page 16 at 00011000: 4096 bytes
Ps: ( 87) Page 16 at 00012000: 4096 bytes
Ps: (100) Page 16 at 00013000: 4096 bytes
Nt: Erased/Wrote page  12-16 with 32768 bytes in 4471msec
Pb: ( 64) Writing page 16 at 0x00014000 with 16384 bytes
Ps: (  0) Page 16 at 00014000
Ps: ( 25) Page 16 at 00010000: 4096 bytes
Ps: ( 50) Page 16 at 00011000: 4096 bytes
Ps: ( 75) Page 16 at 00012000: 4096 bytes
Ps: (100) Page 16 at 00013000: 4096 bytes
Nt: Erased/Wrote page    16 with 16384 bytes in 1889msec
Pb: ( 80) Writing page 17 at 0x00018000 with 19468 bytes
Ps: (  0) Page 17 at 00018000
Ps: ( 21) Page 17 at 00018000: 4096 bytes
Ps: ( 42) Page 17 at 00019000: 4096 bytes
Ps: ( 63) Page 17 at 0001A000: 4096 bytes
Ps: ( 84) Page 17 at 0001B000: 4096 bytes
Ps: (100) Page 17 at 0001C000: 3084 bytes
Nt: Erased/Wrote page    17 with 19468 bytes in 2134msec
Pb: (100) Finished writing Flash successfully.
Nt: Flash write Done
Wt:43: Invalid Reset vector - out of range
Nc: nSRST assert (if available)
Nc: Executing in bootloader.
Nt: Stopped (Was Reset)  [Reset from External]

E:\NXP\lpcxpresso_3.4\bin>PAUSE
Aby kontynuować, naciśnij dowolny klawisz . . .

Let me explain what happens during the programming sector number 16, when the offset is 0x4000?

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Tue Aug 03 14:25:30 MST 2010
For unknown reasons, the GNU linker pads zeroes in a loadable section in front of the start of your application code after you offset the load address. Your code still locates correctly,  but the flash programmer sees the zero pad as loadable code/data (per the ELF file program header) and overwrites the flash contents in the first flash sector.

I've been unsuccessful in finding a way to work around this behavior in  a linker script. As an interim workaround, it should be possible to  post process the .axf file using the 'arm-none-eabi-objcopy.exe' GNU  binary  utility.

Add the following to your project Properties -> C/C++ Build ->  Settings -> Build Steps (tab) -> Post-build steps:

arm-none-eabi-objcopy --input-target=elf32-littlearm   --output-target=binary --change-section-address .text-0x4000 ${BuildArtifactFileName} ${BuildArtifactFileBaseName}.bin;

This binary file can be programmed to flash in a separate step (i.e. use the debug stub from the command-line):
C:\>crt_emu_cm3_nxp.exe -g -2 -pLPC1754  -load-base=0x4000 -flash-load=<yourfile>.bin

The Code Red ELF reader will accommodate this linker behavior in the next LPCXpresso release. In the meantime, note that it is possible to debug a binary that  you have programmed into the flash. For details, please read.

http://support.code-red-tech.com/CodeRedWiki/DebugRunningSystem

Regards,

CodeRedSupport

---

Quote: eltom2
ok I know what is causing this situation. My definition of memory in the linker script is as follows:

MEMORY
{
  /* Define each memory region */
  MFlash128 (rx) : ORIGIN = 0x4000, LENGTH = 0x1C000 /* 128k */
  RamLoc16 (rwx) : ORIGIN = 0x10000000, LENGTH = 0x4000 /* 16k */
  RamAHB16 (rwx) : ORIGIN = 0x2007c000, LENGTH = 0x4000 /* 16k */
  CANAccFilterRAM (rwx) : ORIGIN = 0x40038000, LENGTH = 0x800 /* 2k */

}

When I set a start of memory, as in the original linker script, the program is loaded correctly. However,  as the move the beginning of the memory address 0x4000 then there are  these strange effects of the programming that I described earlier.

I care so I can program from address 0x4000, because from address 0x0000 to address 0x4000 is my bootloader.

---

[lpcware]

Content originally posted in LPCWare by eltom2 on Tue Aug 03 03:24:45 MST 2010
ok I know what is causing this situation. My definition of memory in the linker script is as follows:

MEMORY
{
  /* Define each memory region */
  MFlash128 (rx) : ORIGIN = 0x4000, LENGTH = 0x1C000 /* 128k */
  RamLoc16 (rwx) : ORIGIN = 0x10000000, LENGTH = 0x4000 /* 16k */
  RamAHB16 (rwx) : ORIGIN = 0x2007c000, LENGTH = 0x4000 /* 16k */
  CANAccFilterRAM (rwx) : ORIGIN = 0x40038000, LENGTH = 0x800 /* 2k */

}

When I set a start of memory, as in the original linker script, the program is loaded correctly. However,  as the move the beginning of the memory address 0x4000 then there are  these strange effects of the programming that I described earlier.

I care so I can program from address 0x4000, because from address 0x0000 to address 0x4000 is my bootloader.

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Mon Aug 02 06:02:29 MST 2010
You haven't explained the changes you made. If we do not have the information, we cannot help.

[lpcware]

Content originally posted in LPCWare by eltom2 on Mon Aug 02 05:05:31 MST 2010
It's not the fault of the linker script or application. Hex file is generated correctly. When I program the processor with built-in bootloader, everything is ok,

The problem is, when the LPC-Link programmed processor. On the bottom bar of the IDE, you can see how they are programmed flash memory sectors. When the LPC-Link programming sector address 0x14000, suddenly returns and begins to program the sector address 0x10000. When I do a preview of memory I can see that at 0x10000 is what should be at 0x14000.

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Mon Aug 02 03:36:54 MST 2010
What have you changed in your application? Have you provided your own linker script?