LPC2138 und UART mit Interrupts

[funker211 (Gast)]

Hallo Community,

versuche grad die UART0 eines LPC2138 mit Interrupts in Betrieb zu 
nehmen, und obwohl mir das schon mal mit einem LPC2129 unter UART0 
erfolgreich gelungen ist, krieg ich's nicht hin...

Umgebung: Yagarto (Eclipse, arm-elf-gcc, arm-elf-gdb, OpenOCD und 
Amontec JTAGkey).

Kann mir jemand kurz sagen, was die typischen Fehler sind?

---
Ich nutze IRQ.
Im Startup Code daher:

_vectors:
  ldr pc, ResetAddr    // Reset
  ldr pc, UndefAddr    // Undefined instruction
  ldr pc, SWIAddr      // Software interrupt
  ldr pc, PAbortAddr    // Prefetch abort
  ldr pc, DAbortAddr    // Data abort
  ldr pc, ReservedAddr  // Reserved
  ldr pc, [pc, #-0xFF0]   // IRQ interrupt: jump to whatever VICVectAddr points to
  ldr pc, FIQAddr      // FIQ interrupt

VICVectAddr sollte von VicVectAddr0 geladen werden.

Code aus UART-Konfig:

// Clear any pending interrupts / Disable interrupts
VICINTENCLR = MASK_VIC_UART0;
    
// Make UART 0 Interrupt an IRQ Interrupt
VICINTSELECT &= (~MASK_VIC_UART0);
 
// Register UART ISR as vectored interrupt:
// Write IRQ Handler address to VICVECTRADDRx,
// write IRQ Channel to VICVECTCNTLx
VICVECTADDR0 = (DWORD)IoUart0Isr;
VICVECTCNTL0 = (DWORD)(VIC_CHANNEL_UART0 | VICVECTCTRL_IRQENA); 
    
// Enable UART 0 Interrupt Source
VICINTENABLE |= MASK_VIC_UART0;
    
// Enable specific interrupts:
// Receive Data Available (RDA) und
// Transmit Hold Register Empty (THRE) Interrupt
U0IER |= (MASK_UXIER_RDA | MASK_UXIER_THRE);

Und ISR:

void  __attribute__ ((interrupt ("IRQ"))) IoUart0Isr (void) {

  ... // Code weggelassen
    
  // Clear UART Interrupt by reading U0IIR
  counter = U0IIR;
    
  // Acknowledge IRQ
  VICVECTADDR = 0;
}

Das ganze läuft im RAM. Dazu habe ich das Memory Remapping per Debugger 
eingestellt (Skript für GDB):

monitor mww 0xE01FC040 0x02

Allerdings liefert mit obiges immer eine Fehlermeldung, scheint aber 
trotzdem zu funktionieren, denn wenn ich es weglasse, geht gar kein 
Debuggen, mit o.g. Befehl geht debuggen, aber im Falle eines Interrupts 
sprint das Ding sonst wohin...

[funker211 (Gast)]

Ach, ist es nicht schön, wenn man beim Schreiben endlich beginnt, 
nachzudenken?

Das Memory Mapping scheint wohl tatsächlich nicht zu funktionieren, also

 monitor mww 0xE01FC040 0x02

ist tatsächlich nicht erfolgreich, wie ja die Meldung eigentlich auch 
sagt.

Also daher jetzt eine konkretere Frage:

Was kann die Ursache dafür sein, dass dieser Zugriff nicht funktioniert?

Hier meine gesamte GDB-Initialisierung:

target remote localhost:3333
monitor reset
monitor sleep 500
monitor poll
monitor soft_reset_halt
monitor sleep 500
monitor arm7_9 sw_bkpts enable
monitor debug_level 3
monitor sleep 500
monitor mww 0xE01FC040 0x02
monitor sleep 500
break main
load
continue

Lasse ich den Debugger starten, und mache dann später manuell den 
monitor mww trallalla-Befehl über eine telnet-Verbindung zu OpenOCD, 
dann klappt's.

Ist ggf. der ARM nicht im richtigen Zustand nach einem Reset, um in 
MEMMAP schreiben zu dürfen? Aber der müsste doch im ARM-Mode und 
Supervisor-Mode starten, oder, also mir alle Rechte einräumen, zumal 
über JTAG...

Irgendwelche Ideen?

[funker211 (Gast)]

Lösung:

monitor soft_reset_halt

 auskommentiert.

Dafür weiter oben

monitor reset run_and_halt

Nun geht's, jetzt ist der Befehl

monitor mww 0xE01FC040 0x02

endlich erfolgreich.

Und kaum ist die Vektortabelle aus dem SRAM richtig in den Adressbereich 
0x00000000 gemappt, funktionieren auch die Interrupts.