FreeRTOS, SWI, LPC2148 Problem..

[Thomas Kusch (Gast)]

Hallo!

Ich bin am Anpassen des FreeRTOS an einen LPC2148 (Olimex) unter
CrossWorks (1.6B2). Habe jetzt aber ein Problem mit dem SWI..
So wie ich es verstanden habe verhaelt es sich so (bin noch
ARM-Frischling):
der SWI zeigt in der Startup auf sich selber

swi_handler:
  b swi_handler

Dieser wird dann in der portISR.c-Datei ueberschrieben mit

void vPortYieldProcessor( void ) __attribute__((interrupt("SWI"),
naked));

void vPortYieldProcessor( void )
{
  asm volatile ( "ADD    LR, LR, #4" );
  portSAVE_CONTEXT();
  vTaskSwitchContext();
  portRESTORE_CONTEXT();
}

Jedes taskYIELD() (ist ein Makro auf portYIELD() was wiederum ein Makro
auf   asm volatile ( "SWI" )  ist) loest diesen Interrupt aus.
Mein Problem ist, dass obwohl die portISR kompiliert wird, springt der
ARM bei einem taskYeld in den im Startup definierten leeren Handler und
bleibt dort stecken...

Ich habe irgendwie das Gefuehl, dass die INTs grundsaetzlich falsch
gelinkt werden. Die .map zeigt folgendes:

.init          0x00000200       0x1c ARM Flash
Debug/Philips_LPC210X_Startup.o
                0x00000204                undef_handler
                0x0000020c                pabort_handler
                0x00000210                dabort_handler
                0x00000208                swi_handler
                0x00000218                fiq_handler
                0x00000214                irq_handler
                0x0000021c                _init_end_ =
(_init_start_ + SIZEOF (.init))

Nach Hochladen des Programms stehen aber unter diesen Adressen ziemlich
unsinnige Werte:
0x00000200 eaffff8e eafffffe eafffffe eafffffe eafffffe eafffffe
Da haette ich die Einsprungadressen in die INT-Haendler erwartet...


Bin langsam mit meinem Latein am Ende :( Hat jemand eine Idee?
Ich waere sehr dankbar fuer jeden Hinweis!

Danke und Gruss,
Th.

[Martin Thomas (Gast)]

>Mein Problem ist, dass obwohl die portISR kompiliert wird, springt
>der ARM bei einem taskYeld in den im Startup definierten leeren
>Handler und bleibt dort stecken...

Ja, weil das mit dem "ueberschreiben" so nicht stimmt (zumindest bei
"Standard-gcc", keine Ahnung ob Rowley da etwas angepasst hat,
augenscheinlich nicht). Das Attribut stellt nicht den Exceptions-Vector
ein. Man muss bei gcc selbst dafuer sorgen, dass der SWI-Vector auf die
SWI-ISR zeigt. Wie das geht, wird aus dem mitgelieferten Beispielen
auch recht deutlich (boot.S aus einem LPC2106-gcc Beispiel):

...
  ldr   pc, _undf
  ldr   pc, _swi
  ldr   pc, _pabt
...
_swi:   .word vPortYieldProcessor
...

Das Prinzip einfach so uebernehmen (evtl. noch ein extern vPort...
ergaenzen).

HTH
Martin Thomas

[Thomas Kusch (Gast)]

Hallo Martin.

Danke sehr fuer die Antwort! Werde es am Abend ausprobieren.

Gruss,
Th.