1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

gdb --> Raven loading with wrong "endianness"

Discussion in 'Embedded' started by John Devereux, Sep 14, 2003.

  1. 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

    John Devereux, Sep 14, 2003
    1. Advertisements

  2. John Devereux

    Tauno Voipio Guest

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

    Tauno Voipio
    tauno voipio @ iki fi
    Tauno Voipio, Sep 15, 2003
    1. Advertisements

  3. 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

    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, Sep 15, 2003
  4. John Devereux

    John Guest

    On 15 Sep 2003 09:57:20 +0100, John Devereux <>

    I think the OCD Driver only works with GDB 5.0
    John, Sep 15, 2003
  5. 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

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

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

    John Devereux, Sep 16, 2003
  6. John Devereux

    Simon Berry Guest

    Could somebody please confirm that they have had this configuration
    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 ?
    Simon Berry, Sep 17, 2003
  7. 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, Sep 17, 2003
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.