LPC1114: "Target error from Write Memory"

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Jaecko on Mon Dec 20 01:01:39 MST 2010
We are using an LPC1114/301 for one of our products. To make a firmware update possible, we divided the flash into 3 sections; 1 sector for a bootstrap (fixed), 2 sectors for the bootloader (updateable) and 5 sectors for the firmware (also updateable). In the XPresso-Workspace, there are 4 projects: Bootstrap, Bootloader, Firmware and CMSIS.

After changing the linker script in a way, that all program sections reside in the correct place, it's not possible to use the debugger (LPC-Link) anymore (LPC Xpresso 3.5.0 and 3.5.6). When starting the debugger, an error message with "15: Target error from Write Memory" appears.
We don't use any not-existing memory areas; all addresses are in valid memories according to the .map-file.
Do you know, what causes this problem or how to solve it?

Regards

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Jaecko on Tue Dec 21 03:05:31 MST 2010
Thank you very much!
The missing NOLOAD-attribute caused all this trouble. Now, with NOLOAD, everything works again; The debugger message disappeared, also the error when downloading the .axf vanished. Perfect.

Sincere thanks.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Tue Dec 21 02:48:37 MST 2010
I would also suggest moving _etext to before your noinit section! This symbol is probably being used by your startup code to identify where to copy the initial values of your data - which is at the end of your code.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Tue Dec 21 02:40:48 MST 2010
Looking at the section headers in your axf file using:

[FONT=Courier New][SIZE=1]arm-none-eabi-objdump -h FW.axf[/SIZE][/FONT]

The linker is marking this as loadable data (rather than bss/noloadable which is what you want)....

15 .noinit       00001248  10000000  10000000  00010000  2**4
                  CONTENTS, ALLOC, LOAD, DATA

To prevent this, you need to specify the (NOLOAD) attribute on your noinit section:

    .noinit (NOLOAD):
    {
        *(.bootstrap_noinit)  
        *(.bootloader_noinit) 
        *(.noinit)
    } > RamLoc8

Without NOLOAD, the debugger is actually trying to program up the whole of memory from 0x0 up into RAM as if it were Flash - which is why you get an error.

Docs on NOLOAD at:
http://sourceware.org/binutils/docs-2.20/ld/Output-Section-Type.html#Output-Section-Type

The other alternative would be to change your section names in the noninit section to begin ".bss" (as they then would not be marked as LOADable).

Regards,
CodeRedSupport

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Jaecko on Tue Dec 21 00:58:41 MST 2010
Here are the files.
- A working linker script
- The 2 automatically generated .ld (lib + mem)
- fw.axf

the first two lines in the linker script with bs_externals/bl_externals don't influence the problem.
The main change was this noinit-part.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Mon Dec 20 09:52:19 MST 2010
Please can you provide the *exact* changes between a working and non-working linker script?

Edit: We would also like to review the "../../FW/Debug/FW_Debug_mem.ld" and "../../FW/Debug/FW_Debug_lib.ld" script files, and it would be helpful to have the FW.axf file itself.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Jaecko on Mon Dec 20 08:39:56 MST 2010
Simply said: yes.

I went through the revision history and found the two revisions, where this debugger error appeared. And the only changes here were changes in the linker script accompanied by section attributes for functions/variables.

I've attached the linker script and the created .map-file.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Mon Dec 20 07:15:48 MST 2010
So, you changed the linker script, and the debugger now gives this error? Pleasre post you linker script and map file, and we will tell you what you have done wrong.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Jaecko on Mon Dec 20 06:45:26 MST 2010
The connection from LPC-Link to our board contains SWDIO, SWCLK, Reset and GND. We adopted the electrical connection from the XPresso schematics.

If i take an example program (e.g. blinky), this works perfect. The .axf can be downloaded without any errors, the debugger can be used without any problems. Also if i use an old program revision with just only one project (the firmware without bootstrap/bootloader), it works.
Since we combined those 3 (4 with CMSIS) projects into one workspace, the one "error" after flashing the .axf appeared, but the debugger was still working fine.
After the section placement changes, the debugger shows up the target error message.

The clock setup was not changed; the settings are the same as in 'blinky'.

Edit: The semihosting project is also working; "hello world" is shown.

Regards

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Mon Dec 20 05:04:29 MST 2010
Please confirm:

The details of the reset/swd circuitry on your target board - in particular, not that LPC-Link requires RESET in addition to SWDIO, CLK and GND when connecting to an LPC11 target.

Can you successfully download and debug a "standard" LPCXpresso1114 example? [In other words an application that consists only of one part]. I would suggest you simply switch to a new workspace, import the LPC11 CMSIS project, then create a default "NXP LPC1100 semihosting C project". Does this successfully download and run (ie print "hello world" to the console).

Can you also confirm whether you have changed the clock setup code in the CMSIS project you are using in your project?

Regards,
CodeRedSupport.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Jaecko on Mon Dec 20 03:52:55 MST 2010
The built-in MCU is not used. We disconnected the PCB tracks and connect the LPC-Link to our board with the 2x5 pin header (SW-Debug).

If i download the created .axf via "Program Flash", the process seems to work; after the flash was programmed, we get the error message "05: File 'project.axf' load failure: Eg(10). Attempt to load into missing flash area.". This message occured the first time days before the restructuring of the linker script and the "target error". After disconnecting and repowering the board, the new software runs perfectly.
(Here i think the LPC-Link tries to write some RAM data)

Here is the MCU debug log:

    [COLOR=black][FONT=&quot]LPCXpresso Debug Driver v2.0 ([/FONT][/COLOR][COLOR=black][FONT=&quot]Oct 27 2010[/FONT][/COLOR][COLOR=black][FONT=&quot]12:23:[/FONT][/COLOR][COLOR=black][FONT=&quot]56)[/FONT][/COLOR]
[COLOR=black][FONT=&quot]Looked for chip XML file in D:/progs/nxp/lpcxpresso_3.5/bin/LPC1114/301.xml[/FONT][/COLOR]
[COLOR=black][FONT=&quot]Looked for vendor directory XML file in D:/progs/nxp/lpcxpresso_3.5/bin/nxp_directory.xml[/FONT][/COLOR]
[COLOR=black][FONT=&quot]Found generic directory XML file in D:/progs/nxp/lpcxpresso_3.5/bin/crt_directory.xml[/FONT][/COLOR]
[COLOR=black][FONT=&quot]Emu(0): Conn&Reset. DpID: BB11477. [/FONT][/COLOR][COLOR=black][FONT=&quot]Info: T1S6RGRIA[/FONT][/COLOR]
[COLOR=black][FONT=&quot]SWD Frequency: 3000 KHz. RTCK: False. Vector catch: False.[/FONT][/COLOR]
[COLOR=black][FONT=&quot]Packet delay: 0 Poll delay: 0.[/FONT][/COLOR]
[COLOR=green][FONT=&quot]Cannot find definition 'LPC11_PMU' for peripheralInstance 'PMU'[/FONT][/COLOR]
[COLOR=black][FONT=&quot]NXP: LPC1114/301 Part ID: 0x0444102B[/FONT][/COLOR]
[COLOR=black][FONT=&quot]Connected: was_reset=false. was_stopped=true[/FONT][/COLOR]
[COLOR=black][FONT=&quot]v Registered license, download limit of 128K[/FONT][/COLOR]
[COLOR=red][FONT=&quot]15: Target error from Write Memory: Em(06). Overrun memory transaction buffer.[/FONT][/COLOR]
[COLOR=black][FONT=&quot]Stopped: VectorCatch:HardF (PC was 0x00003004)[/FONT][/COLOR]

The Address 0x3004 where the Program Counter was, is the Reset Vector of our "new" Vector table. Since the vector table is not relocateable in flash, we use tail chaining to reroute the interrupts to our own table (hint from http://embeddedfreak.wordpress.com/2010/10/19/tail-chaining-arm-cortex-m0-interrupts/ ). This worked perfectly. Only the Firmware uses interrupts; bootstrap and bootloader don't need them.

Regards

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Mon Dec 20 03:14:50 MST 2010
Are you connecting via the LPC-Link to the built-in MCU on the LPCXpresso board, or have you split the LPC-Link off and are connecting to your own board?

Can you successfully download and run a "standard" LPCXPresso example application?

Please can you copy and paste the MCU debug log from the console view of the LPCXpresso into this thread. You may need to use the "Monitor" icon of the console view in order to select the MCU debug log as the log file to display.

Regards,
CodeRedSupport