SparkFun Forums

[hp.mu]

Hello

I'm using openocd r88-rc1 (http://www.yagarto.de/) and the amontec sdk.

In some cases it seams, the downloaded data of the arm-elf-gdb via openocd is corrupted. With my current elf file I can see this situation a few times. I checked it and it looks like it is the same problem always (mem is ok).

binary data (produced with arm-elf-objdump)
107c: e58d3000 str r3, [sp]
1080: e59f007c ldr r0, [pc, #124] ; 1104 <.text+0x1104>
1084: e59f107c ldr r1, [pc, #124] ; 1108 <.text+0x1108>
1088: e3a02020 mov r2, #32 ; 0x20
108c: e3a03008 mov r3, #8 ; 0x8


11fc: e59b3008 ldr r3, [fp, #8]
1200: e58d3004 str r3, [sp, #4]
1204: e59b300c ldr r3, [fp, #12]
1208: e58d3008 str r3, [sp, #8]
120c: e59b3010 ldr r3, [fp, #16]

openocd log output (bitbang.c and jtag.c lines removed)

Debug: gdb_server.c:814 gdb_write_memory_binary_packet(): addr: 0x00001086, len: 0x00000180
Debug: target.c:623 target_write_buffer(): writing buffer of 384 byte at 0x00001086
Debug: arm7_9_common.c:1771 arm7_9_write_memory(): address: 0x00001086, size: 0x00000001, count: 0x00000002
Debug: embeddedice.c:155 embeddedice_read_reg_w_check(): 1
Debug: embeddedice.c:155 embeddedice_read_reg_w_check(): 1
Debug: arm7_9_common.c:1771 arm7_9_write_memory(): address: 0x00001088, size: 0x00000004, count: 0x0000005f
Debug: embeddedice.c:155 embeddedice_read_reg_w_check(): 1
Debug: embeddedice.c:155 embeddedice_read_reg_w_check(): 1
Debug: embeddedice.c:155 embeddedice_read_reg_w_check(): 1
Debug: embeddedice.c:155 embeddedice_read_reg_w_check(): 1
Debug: embeddedice.c:155 embeddedice_read_reg_w_check(): 1
Debug: embeddedice.c:155 embeddedice_read_reg_w_check(): 1
Debug: embeddedice.c:155 embeddedice_read_reg_w_check(): 1
Debug: arm7_9_common.c:1771 arm7_9_write_memory(): address: 0x00001204, size: 0x00000001, count: 0x00000002
Debug: embeddedice.c:155 embeddedice_read_reg_w_check(): 1
Debug: embeddedice.c:155 embeddedice_read_reg_w_check(): 1
Debug: gdb_server.c:177 gdb_put_packet(): sending packet '$OK#9a'

after loading I dump the two areas:

> mdw 0x1080 3
0x00001080: e59f007c 7c109fe5 e3a02020

> mdw 0x1200 3
0x00001200: e58d3004 0c309be5 e58d3008

Is there a little / big endian problem?

thx for help and ideas

hp.mu

[hp.mu]

I'm using openocd r88-rc1 (http://www.yagarto.de/) and the amontec sdk.

I detected the problem while working with openocd r82. But it's reproducable 1:1 with r88-rc1.

hp.mu

[mifi]

Hello hp.mu,

it would be nice if you could provide some more information, like
for wich CPU you use the software. LPC2XXX, STR71X, YYYY.

If you using the parport interface or an USB key?

Regards,

Michael

[hp.mu]

Hello Michael

Here a few more informations:

- I'm using an amontec chameleon pod on parallel port with wiggler configuration.
- I'm working on a Netarm40 (ARM7 core)

regards

hp.mu

[Dominic]

Hi,

could you please send
- the config file you used
- the complete debug output
- if possible (i.e. nothing confidential etc.), the binary source and dump

to Dominic.Rath <at> gmx.de.

Is the Netarm40 big-endian or little-endian?

Regards,

Dominic