Discussion:
[Openocd-development] r1770, load_image ist not working here
Michael Fischer
2009-05-13 19:12:47 UTC
Permalink
Hello list,

please can some one try if the load_image is working?

I want to download data into an external RAM of the LPC2294
CPU. Interface is a FT2232 device, command looks like:

load_image test.bin 0x81000000

The telnet prompt come back, but I could not
found any data at 0x81000000.

The external memory is mapped, because I can use:

mww 0x81000000 0x11223344

And read it back with:

mdw 0x81000000 1

Tested under Windows.

Best regards,

Michael
Øyvind Harboe
2009-05-13 19:31:47 UTC
Permalink
Referring to our offlist discussion: 1606 has the same problem
per your testing.

What I find curious about the lpc2294.cfg and your posting above
is that working memory is at 0x40000000.

Does the lpc2294 have two ram regions?


Could it be that the config script is busted and that working memory address
is wrong?
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
Michael Fischer
2009-05-13 19:35:45 UTC
Permalink
Hello List,

it is possible that I have make to much testing here
and mixed something. I will start with a clean build.
Post by Øyvind Harboe
What I find curious about the lpc2294.cfg and your posting above
is that working memory is at 0x40000000.
It is a olimex LPC-2294 board with external RAM.

I will test it again with the 1606 and 1770.

Regards,

Michael

-----Ursprüngliche Nachricht-----
Von: ***@gmail.com [mailto:***@gmail.com]Im Auftrag
von Øyvind Harboe
Gesendet: Mittwoch, 13. Mai 2009 21:32
An: Michael Fischer
Cc: Openocd-Dev
Betreff: Re: [Openocd-development] r1770, load_image ist not working
here


Referring to our offlist discussion: 1606 has the same problem
per your testing.

What I find curious about the lpc2294.cfg and your posting above
is that working memory is at 0x40000000.

Does the lpc2294 have two ram regions?


Could it be that the config script is busted and that working memory address
is wrong?


--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
Michael Fischer
2009-05-13 20:33:26 UTC
Permalink
Hello list,

here is a new test which I had make with r1606 / r1770,
done with a FT2232 device. The result look like:

Windows-ft2232-1606
====================

Open On-Chip Debugger
version
Open On-Chip Debugger 0.2.0-in-development (2009-05-13-21:55) svn:1606
load_image testimg.bin 0x81000000
2466976 byte written at address 0x81000000
downloaded 2466976 byte in 111.546875s
dump_image win-1606.bin 0x81000000 2466976
Windows-ft2232-1770
====================

Open On-Chip Debugger
version
Open On-Chip Debugger 0.2.0-in-development (2009-05-13-22:03) svn:1770
load_image testimg.bin 0x81000000
2466976 byte written at address 0x81000000
downloaded 2466976 byte in 111.562500s
dump_image win-1770.bin 0x81000000 2466976
timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: 2
The file on the harddisk had a size of 2030560 and not the full size of
2466976.

Attached is the cfg file too.

OpenOCD was build with:

./bootstrap
./configure --enable-maintainer-mode --disable-werror --enable-ft2232_ftd2xx
--with-ftd2xx-win32-zipdir=/home/mfischer/openocd/ftd2xx
CC="gcc -mno-cygwin"

Best regards,

Michael
Øyvind Harboe
2009-05-14 08:50:45 UTC
Permalink
Could this be an intermittant problem?

I was able to reproduce this problem *once* using 1770 and
the script below on a parport interface with an LPC2148 target
and the command below:

reset init
for {set i 0} {$i < 100} {set i [expr $i+1]} {puts $i ; dump_image
c:\\temp\\test.bin 0x40000000 0x8000}
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
Øyvind Harboe
2009-05-14 10:33:11 UTC
Permalink
I've worked a bit more on testing lpc2148 and except for that *one*
time I haven't seen the error you saw.

Perhaps this is easier to reproduce on an ft2232 adapter?

Below are some commands I used to run a 1000 iterations of this test...

# tried messing about with options...
arm7_9 fast_memory_access enable
arm7_9 dcc_downloads enable

# dump, verify and load memory...
for {set i 0} {$i<1000} {set i [expr $i+1]} {puts $i; dump_image
c:\\temp\\test.bin 0x40004000 0x4000; verify_image c:\\temp\\test.bin
0x40004000 bin; load_image c:\\temp\\test.bin 0x40004000 bin}
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
Continue reading on narkive:
Loading...