Indeed it works without the wokring area!
Here is the log file:
----------------
Open On-Chip Debugger 0.5.0-dev-00622-g9a04974 (2010-11-30-17:39)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
5 kHz
adapter_nsrst_delay: 300
jtag_ntrst_delay: 300
trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
RCLK - adaptive
Info : device: 4 "2232C"
Info : deviceID: 67353336
Info : SerialNumber: FTR5CYBEA
Info : Description: OOCDLink A
Info : RCLK (adaptive clock speed) not supported - fallback to 500 kHz
Info : JTAG tap: lpc2478.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part:
0xf1f0, ver: 0x4)
Info : Embedded ICE version 7
Error: EmbeddedICE v7 handling might be broken
Info : lpc2478.cpu: hardware has 2 breakpoint/watchpoint units
Info : accepting 'gdb' connection from 3333
Info : Flash Manufacturer/Device: 0x0001 0x227e
Warn : acknowledgment received, but no packet pending
Info : JTAG tap: lpc2478.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part:
0xf1f0, ver: 0x4)
Warn : srst pulls trst - can not reset into halted mode. Issuing halt after
reset.
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x800000d3 pc: 0x00005230
core state: ARM
Warn : NOTE! DCC downloads have not been enabled, defaulting to slow memory
writes. Type 'help dcc'.
Warn : NOTE! Severe performance degradation without working memory enabled.
Warn : NOTE! Severe performance degradation without fast memory access
enabled. Type 'help fast'.
requesting target halt and executing a soft reset
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x800000d3 pc: 0x00000000
Info : Flash Manufacturer/Device: 0x0001 0x227e
flash 'cfi' found at 0x80000000
auto erase enabled
Error: No working memory available. Specify -work-area-phys to target.
Warn : not enough working area available(requested 96)
Info : Programming at 80000000, count 00080000 bytes remaining
Info : Programming at 80000100, count 0007ff00 bytes remaining
Info : Programming at 80000200, count 0007fe00 bytes remaining
Info : Programming at 80000300, count 0007fd00 bytes remaining
...
...
Info : Programming at 8007fc00, count 00000400 bytes remaining
Info : Programming at 8007fd00, count 00000300 bytes remaining
Info : Programming at 8007fe00, count 00000200 bytes remaining
Info : Programming at 8007ff00, count 00000100 bytes remaining
wrote 524288 bytes from file ./bin/Debug/WePi-Res.hex in 1276.454102s (0.401
KiB/s)
----------------
It takes some time but it works!
This was the work area I had defined previously:
$_TARGETNAME configure -work-area-phys 0x40000000 -work-area-size 0x10000
-work-area-backup 0
-----Ursprüngliche Nachricht-----
Von: [email protected]
[mailto:[email protected]] Im Auftrag von Michael
Schwingen
Gesendet: Dienstag, 30. November 2010 20:01
An: [email protected]
Betreff: Re: [Openocd-development] Programming external flash with OpenOCD
fails
On 11/30/2010 07:06 PM, Starkeeper wrote:
> Hi there,
> I have an external flash (Spansion S29GL128N90) connected to a NXP
> LPC2478 microcontroller. Everytime when I try to flash this external
> flash I get the following error from OpenOCD (Version 0.4.0 and self
compiled 0.5.0):
>
> Flash Manufacturer/Device: 0x0001 0x227e error writing to flash at
> address 0x80000000 at offset 0x00000000 (-902) Command handler
> execution failed in procedure 'flash' called at file "command.c", line
> 650 called at file "command.c", line 361
>
> Command used:
> monitor flash write_image erase ./bin/Debug/We-Res.hex 0x00 ihex
>
>
> The flash is connected to the EMI and seems to works fine. OpenOCD is
> able to erase the flash and I am able to read the data, that I have
> written previously with the following commands:
> monitor flash erase_sector 1 0 10
> monitor flash fillw 0x80000000 0x12345678 0x1000
Could you try what happens if you disable the work-area in the CPU config?
If it works, it will be dead slow, but we might get more diagnostics if the
offending code runs on the PC instead of the target. If it fails, too,
please provide a log of the failing operation that shows the bus cycles.
BTW: you *did* set up the work area to point to an area where you have
working memory?
cu
Michael
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
