JLink & Code::Blocks in Linux (arm-none-eabi gcc) mit LM3S6965 Debugger Fehler?

[No Y. (noy)]

Hallo Forum ich habe hier ein kleines Problem mit der oben genannten 
Kombination.

Meine Debug Einstellungen für den JLink sehen folgendermaßen aus:

 # Enable flash download and flash breakpoints.
 # Flash download and flash breakpoints are features of
 # the J-Link software which require separate licenses
 # from SEGGER.

 # Select flash device
 monitor flash device = LM3S6965

 # Enable FlashDL and FlashBPs
 monitor flash download = 1
 monitor flash breakpoints = 1

 # Clear all pendig breakpoints
 monitor clrbp

 # Set gdb server to little endian
 monitor endian little

 monitor interface JTAG

 # Set JTAG speed to 1000 kHz
 monitor speed auto

 # Reset the target
monitor reset halt
load
monitor reset init

# Set a breakpoint at main().
break main

# Run to the breakpoint.
continue

Mein Code der debuggt werden soll ist im Anhang (besteht zu 99% aus dem 
Example von TI).
Wenn ich das Compiliere und direkt flashe geht alles wunderbar. Nur wenn 
ich den Debugger starte und dann Debuggen möchte geht es nicht.

Erst hatte ich das Problem das immer eine faultISR geschmissen wurde, 
danach habe ich:

 # Reset the target
monitor reset
load
thbreak main

in

# Set a breakpoint at main().
break main

# Run to the breakpoint.
continue

 # Reset the target
monitor reset halt
load
monitor reset init

# Set a breakpoint at main().
break main

# Run to the breakpoint.
continue

verändert und nun hab ich irgend ein anderes.

Das Blinky Projekt aus den Examples hatte ich zuerst versucht und dort 
ging das Debuggen ohne Probleme aber ich hab dann ja irgendwo dran 
rumgespielt... :-(

Meldungen vom JLink GDB sind im Anhang.

Hoffe mir kann jemand helfen.

[Jim M. (turboj)]

Da ist was oberfaul:

JTAG ID: 0x3BA00477 (Cortex-M3)
...
Starting target CPU...
WARNING: T-bit of XPSR is 0 but should be 1. Changed to 1.
...Target halted (PC = 0x00000000)
Reading all registers
Read 4 bytes @ address 0x00000000 (Data = 0x20000540)
Removing breakpoint @ address 0x00000A94, Size = 2
Removing breakpoint @ address 0x00000A96, Size = 2
Setting breakpoint @ address 0x00000A94, Size = 2, BPHandle = 0x000A
Setting breakpoint @ address 0x00000A96, Size = 2, BPHandle = 0x000B
Performing single step...
...Target halted (PC = 0x00000002)
Reading all registers
Read 4 bytes @ address 0x00000002 (Data = 0x10672000)
Read 2 bytes @ address 0x00000000 (Data = 0x0540)
Performing single step...
...Target halted (PC = 0x00000004)
Reading all registers
Read 4 bytes @ address 0x00000004 (Data = 0x00001067)
Read 2 bytes @ address 0x00000000 (Data = 0x0540)
Read 2 bytes @ address 0x00000002 (Data = 0x2000)
Performing single step...
...Target halted (PC = 0x00000006)

Der PC zählt von 0x00. Das ist beim Cortex M3 aber völlig falsch!
Im Flash scheint es sogar korrekt zu stehen:
> Read 4 bytes @ address 0x00000004 (Data = 0x00001067)

Er müsste demzufolge mit PC=0x00001066 anfangen, das ist die Adresse der 
ersten Instruktion. Die Sache mt dem T-Bit deutet auch auf 
Kommunikationsprobleme hin - wenn das nicht gesetzt ist, befindet sich 
der Core im Lockup. Das müsste der Debugger aber eigentlich irgendwo 
loggen.

Ich würe es auch mal deutlich langsamer als mit 4 MHz JTAG Takt 
versuchen, das könnte zu schnell sein.

No y. schrieb:
> monitor flash breakpoints = 1

Das würde mal testweise auf 0 setzen, Cortex M3 kennt Hardware 
Breakpoints, da muss man nicht im Flash rummüllen.

[No Y. (noy)]

Hab die Einstellungen mal geändert. Aber hat nichts gebracht... Neuer 
Log im Anhang.
Was mir aufgefallen ist, er hängt anscheinend immer an dieser Funktion:

/*********************************************************************** 
******
//
// Wrapper function for the CPSID instruction.  Returns the state of 
PRIMASK
// on entry.
//
//********************************************************************** 
*******
#if defined(codered) || defined(gcc) || defined(sourcerygxx)
unsigned long __attribute__((naked))
CPUcpsid(void)
{
    unsigned long ulRet;

    //
    // Read PRIMASK and disable interrupts.
    //
    __asm("    mrs     r0, PRIMASK\n"
          "    cpsid   i\n"
          "    bx      lr\n"
          : "=r" (ulRet));

    //
    // The return is handled in the inline assembly, but the compiler 
will
    // still complain if there is not an explicit return here (despite 
the fact
    // that this does not result in any code being produced because of 
the
    // naked attribute).
    //
    return(ulRet);
}
#endif


Mit diesen Einstellungen:
 # Reset the target
monitor reset
load
thbreak main

Hing er immer in einer faultISR().