LPC21xx: ARM state: FIQ

[magnus (Gast)]

Hallo *,

weiß jemand von euch vllt, wie man "von außen" den ARM-state 
beeinflussen kann?

Ich hab folgendes Problem:
Ich hab ein kleines Testprogramm da, was einfach ein paar LEDs zum 
blinken bringt, ist nicht weiter wichtig.

Wichtig ist jedoch, dass ich eben im startup code eine Zeile verändert 
habe und nun lässt sich der Controllern icht mehr flashen o_O...


Vorher:

/* The vector table */
Vectors:        LDR     PC, Reset_Addr         
                LDR     PC, Undef_Addr
                LDR     PC, SWI_Addr
                LDR     PC, PAbt_Addr
                LDR     PC, DAbt_Addr
                NOP               /* Reserved vector */ 
;                LDR     PC, IRQ_Addr
        LDR    PC, [PC, #-0x0FF0]                
                LDR     PC, FIQ_Addr

Da mein Editor nur C Syntax anzeigt, habe ich den Code SO ändern wollen:

/* The vector table */
Vectors:        LDR     PC, Reset_Addr         
                LDR     PC, Undef_Addr
                LDR     PC, SWI_Addr
                LDR     PC, PAbt_Addr
                LDR     PC, DAbt_Addr
                NOP               /* Reserved vector */ 
/*                LDR     PC, IRQ_Addr*/
        LDR    PC, [PC, #-0x0FF0]                
                LDR     PC, FIQ_Addr

...da ich dachte, das die Art des Kommentars egal sein wird.

Danach ließ sich der Controller noch genau einmal brennen und seit dem 
nicht mehr.


Beim download erhalte ich folgende Meldungen:

target state: halted
target halted in ARM state due to debug request, current mode: FIQ
cpsr: 0x600000d1 pc: 0x00009f88
usage: flash probe <num>
/cygdrive/c/DOCUME~1/magnus/LOCALS~1/Temp/arm-gdb-commands91435866734502 
84387.tmp:5:  Error in sourced command file:
Reply contains invalid hex digit 116


Bei einem anderen Board, das noch hinsichtlich des Flashens funktioniert 
erscheint:

target state: halted
target halted in ARM state due to debug request, current mode: User
.
.
.


Wie kann ich nun bewirken, dass das andere Board sich nicht mehr im FIQ 
state befindet?


Ich verwende die GNU ARM Toolchain, allerdings in Verbindung mir der 
RapidiTTy 1.5 IDE, die von Olimex auch verlinkt wird.
Hardware: Olimex Baord LPC-P212x-B, Olimex ARM-USB-OCD

[(prx) A. K. (prx)]

Der Bootloader greift bevor das Programm im Flash loslegt. JTAG (OCD) 
erst danach. Wenn der Bootloader das Flash erst einmal gelöscht hat, 
wird auch der Weg über JTAG wieder funktionieren.

Empfehlung: Den Startup-Code ganz vorne um eine Schleife bereichern, die 
ein paarhundert Millisekunden leer rumeiert. JTAG kann auf den LPC2000 
nicht verhindern, dass der Controller nach Reset direkt loslegt, sondern 
versucht, ihn danach unter Kontrolle zu bekommen. Ohne die Wartezeit ist 
das manchmal schon zu spät.

[magnus (Gast)]

Das heißt, ich müsste versuchen den Chip im FIQ Mode zunächst über die 
serielle Schnittstelle zu flashen?

[(prx) A. K. (prx)]

Ja, wobei es ausreichen wird, das Flash zu löschen. Dann wird er wieder 
normal ansprechbar sein.

[magnus (Gast)]

Vielen Dank A. K. !!!

Ich hab irgendwie das lpc21isp Tool zum laufen gebracht (wobei ich 
zunächst vergaß auch eine Baudrate zu nehmen, die mit dem 10 MHz Quarz 
erzeugt werden kann, einzustellen).
Damit konnte ich dann den Chip brennen und nun tut auch wieder JTAG 
;)...

Aber wie lang in etwa soll die Schleife im Startup-Script sein?
Welche hast du eingebaut?

Auf jeden Fall vielen Dank für die Hilfe!!!!

[(prx) A. K. (prx)]

__start:
    mov   r0, #1<<20
1:  subs  r0, r0, #1
    bne   1b

[magnus (Gast)]

noch eine letzte Frage:

Kommt die Schleife dann vor oder nach der Vectortabelle?
Soweit ich mich erinnern kann, müssen die Vectorsprungadressen doch 
immer zuerst definiert werden, oder?

[(prx) A. K. (prx)]

Steht bei mir am Anfang des eigentlichen Startup-Codes, also dorthin wo 
der Reset schlussendlich hinhüpft. Damit ich ggf. den Startup-Code noch 
mit dem Debugger erwischen kann.