gdb --> Raven loading with wrong "endianness"

Hi,

I am using a "raven" type JTAG device with the Sharp LH79520 (a "little-endian" ARM variant).

GDB always loads the application into the chip with the wrong endianness! So the instruction opcodes are all scrambled up and the program is garbage. I have tried all four combinations of "set endian" and the "monitor" equivalent, they seem to make no difference. (You can make the program APPEAR correct like this, but it is still wrongly loaded into the chip and does not run).

I can load and run programs fine using the Macraigor OCD Commander application. Once loaded like this, I can even use GDB to step through the application. It is just the loading phase which is going wrong.

Can anyone shed some light on this? Is anyone doing this with a "little-endian" ARM?

I have currently using V5.3 of arm-elf-gdb, tried on both linux and windows.

Thanks,

--

John Devereux
Reply to
John Devereux
Loading thread data ...

Have you tried 'set endian little' before talking to the target?

Tauno Voipio tauno voipio @ iki fi

Reply to
Tauno Voipio

Hi Tauno,

Yes, the command is is the startup file before the connection (to the driver) is made.

Some more information: I am using the OcdLibRemote driver to interface gdb to the target. Here is my .gdbinit file:

---------------------------------------------- set complaints 1 set output-radix 16 set input-radix 16 set endian little dir . set prompt (arm-gdb)

target remote 217.169.15.187:8888

monitor endian big load ./lpa2.elf symbol-file ./lpa2.elf

----------------------------------------------

(I tried all the combinations for "set endian" and "monitor endian".

I am using a "stock" gdb 5.3 built for arm-elf. I wonder, can this in fact talk properly to the OCD driver, or do I need something else?

--

John Devereux
Reply to
John Devereux

I think the OCD Driver only works with GDB 5.0

Reply to
John

I am still having this problem!

Some more information:

GDB uses OCDlibremote to talk to the hardware. The loading process is incorrectly inverting the "endianness", for instructions, *but not for data* !!!

How is this even possible? I suppose either gdb or OCDlibremote must be doing some "interpretation", somehow. This happens even when the input file is in a raw s-record format.

Could somebody please confirm that they have had this configuration working:

gdb -> OcdLibremote -> Raven | Wiggler -> LittleEndian ARM

If not via the newsgroup, is there anyone who would be willing to help via email? Pretty Please?

Thanks,

--

John Devereux
Reply to
John Devereux

I have had OCDLibremote (running under Cygwin / Win2000) -> RAVEN ->

LittleEndian ARM 9 and ARM7 processors.

GDB 5.2 was running on a (different ) Linux PC.

It all worked fine.

I assume you have a cross-compiled version of GDB ?

Reply to
Simon Berry

Yes, I am using the same setup as you. OcdLibRemote on a Cygwin/W2K machine, GDB on linux. I have tried several versions of arm-elf-gdb by now, 5.0, 5.21, 5.3, mostly on linux.

Simon, thanks for the response, at least I know it should be possible!

Here is what is happening:

I have a machine code file app.sr. It is little-endian for both code and data (by inspection).

I can load app.sr using the OCD Commander debugger OK. The program stays little-endian & runs OK. I can even then connect with gdb and single step etc.

So app.sr -> OCD Commander -> Raven -> LH79520 = OK.

If I use gdb to load it, via OcdLibRemote, it inverts the endianness of the code, but not the data!

app.sr -> arm-elf-gdb -> OcdLibRemote -> Raven -> LH79520 = BAD

I don't see how this is possible, the tools should not be able to decode a hex file well enough to be able to tell the difference between opcodes and data. But this is what happens.

--

John Devereux
Reply to
John Devereux

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.