This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

gdb -> OcdLibRemote -> Raven | Wiggler -> LittleEndian Arm


Hi,

Firstly, apologies if this is off-topic for the list.

GDB 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 am using a "raven" type JTAG device with the Sharp LH79520 (a
"little-endian" ARM variant).
 
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.

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

Help!

Thanks,

-- 

John Devereux


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]