Probleme mit NXP LPC845 und die USART Ports

[Waffel (Gast)]

Moin,

ich habe ein kleines Problem mit NXP Controllern. Mein LPC845 will zum 
Verrecken nicht auf den USART Ports 3 und 4 kommunizieren. Sobald ich 
dort einmal sende, hängt sich der ganze MC auf. Ich habe dazu mal das 
Beispiel verändert:

    BOARD_InitBootPins();
    BOARD_InitBootClocks();
    BOARD_InitBootPeripherals();

    /* Init FSL debug console. */
    BOARD_InitDebugConsole();

    PRINTF("Init...\n\r");

    callbackUserData[0] = 0;
    callbackUserData[1]  = 1;
    callbackUserData[2] = 2;
    callbackUserData[3]  = 3;

    PRINTF("Create Handles\n\r");
  USART_TransferCreateHandle(baseAddress[1],  &usart[1],  USARTUserCallback1, NULL);
  USART_TransferCreateHandle(baseAddress[2], &usart[2], USARTUserCallback2, NULL);
  USART_TransferCreateHandle(baseAddress[3],  &usart[3],  USARTUserCallback3, NULL);

    PRINTF("Init finished\n\r");

    uint8_t string[] = "Hello World";
    usart_transfer_t test_data;
    test_data.data = string;
    test_data.dataSize = sizeof(string);
    PRINTF("sending test.\n\r");

    USART_TransferSendNonBlocking (baseAddress[1], &usart[1], &test_data);
    USART_TransferSendNonBlocking (baseAddress[2], &usart[2], &test_data);
    USART_TransferSendNonBlocking (baseAddress[3], &usart[3], &test_data);

    PRINTF("test Send.\n\r");

Das Letzte was ausgegeben wird ist "sending test" und der Interupt 
USARTUserCallback1 feuert. Die USARTs sind über das Treiber-Tool 
configuriert.

[Harald A. (embedded)]

Bist Du da mal im Single Step durchgegangen? Irgendwann müsste er ja 
dann im Nirwana landen, daraus kann man meistens Rückschlüsse ziehen.

Wie sieht die Funktion USARTUserCallback aus?

[Johannes S. (Gast)]

Fehlt da nicht ein USART_Init?

[Waffel (Gast)]

USART3_init ist autogeneriert in der peripherals.c :

const usart_config_t USART3_config = {
  .baudRate_Bps = 9600,
  .syncMode = kUSART_SyncModeDisabled,
  .parityMode = kUSART_ParityDisabled,
  .stopBitCount = kUSART_OneStopBit,
  .bitCountPerChar = kUSART_8BitsPerChar,
  .loopback = false,
  .enableRx = true,
  .enableTx = true,
  .clockPolarity = kUSART_RxSampleOnFallingEdge,
  .enableContinuousSCLK = false
};

void USART3_init(void) {
  /* USART3 peripheral initialization */
  USART_Init(USART3_PERIPHERAL, &USART3_config, USART3_CLOCK_SOURCE);
}

Harald A. schrieb:
> Wie sieht die Funktion USARTUserCallback aus?

Die sehe alle gleich aus im Test, 0 und 1 feuern. 2 und 3 nicht.
[c]
void USARTUserCallback2(USART_Type *base, usart_handle_t *handle, 
status_t status, void *userData)
{
  uint8_t usartId = *(uint8_t*)userData;
  PRINTF("Int2 %d on %d\n\r", status, usartId);
}
[c]

[Johannes S. (Gast)]

Das PRINTF im callback sieht gefährlich aus. Wenn das im ISR context 
selber Interrupts benutzt kann das ein Problem sein.

[Harald A. (embedded)]

>
> Die sehe alle gleich aus im Test, 0 und 1 feuern. 2 und 3 nicht.
> [c]
> void USARTUserCallback2(USART_Type *base, usart_handle_t *handle,
> status_t status, void *userData)
> {
>   uint8_t usartId = *(uint8_t*)userData;
>   PRINTF("Int2 %d on %d\n\r", status, usartId);
> }

Wenn im User Callback PRINTF aufgerufen wird, wo landet denn die PRINTF 
Ausgabe? Auf dem UART?

[Waffel (Gast)]

Die Ausgabe geht auf USART0 - Das ist aber nicht das Problem, bei USART0 
und 1 funktioniert das ja. Ich hab das auch ohne die Ausgabe schon 
versucht, mit einem Breakpoint im Callback. Das macht keinen 
Unterschied.

[Harald A. (embedded)]

Wie ist das denn jetzt? Kannst Du Single Step machen oder hast Du keinen 
Debugger dran? In den ersten USART_TransferSendNonBlocking rein und 
schauen, wo er in die Wüste springt

[Johannes S. (Gast)]

hier ist der Zeiger auf userdata NULL:

USART_TransferCreateHandle(baseAddress[1],  &usart[1],  USARTUserCallback1, NULL);

Im callback wird der Zeiger dereferenziert, gibts da evtl. einen 
hardfault? Statt NULL sollte da doch sicher &userdata[n] rein.

[Waffel (Gast)]

Dsa Problem ist, dass sich das nicht wirklich debuggen lässt. Gehe ich 
Schritt für Schritt vor, läuft er zumindest bis zum "test send" durch. 
sobald ich dann aber auf "continue" drücke hängts. Das scheint mit dem 
Auslösen des Interupts zu tun zu haben.

[Peter D. (peda)]

Waffel schrieb:
> Die sehe alle gleich aus im Test

Laß die Prosa sein, die taugt nicht als Quelltext.
Wie wärs, wenn Du mal den echten und vollständigen Testcode als Anhang 
postest.
Und auch nen Link auf die Lib und die Toolchain.

[Waffel (Gast)]

Peter D. schrieb:
> Und auch nen Link auf die Lib und die Toolchain.

Versuch doch im Gegenzug mal ein wenig netter zu sein. Dein Text kommt 
bei mir schon etwas agressiv an. Der Satz heißt lediglich, dass alle 
vier Interupthandler den gleichen Inhalt haben und sich nur durch eine 
Zahl im Namen unterscheiden. Ich sehe es nicht als zielführend weil 
unübersichtlich, vier mal das gleiche zu posten.

Der restliche Quelltext ist oben zu finden. Die Toolchain ist das 
MCUXpresso IDE von NXP, dass bringt die Libs mit. In diesem Fall ist es 
die fsl_usart (wie im Include des geposteten Quellcode zu sehen) Das 
sind alles die offiziellen standard Tools, die von NXP kommen. Falls dir 
also noch etwas konkretes fehlt, kann ich das gerne posten.

Hier noch das Ergebnis des Konfigurationstools, die entsprechenden 
Einträge der pin_mux.h. Die fehlte noch.

    /* USART3_TXD connect to P0_7 */
    SWM_SetMovablePinSelect(SWM0, kSWM_USART3_TXD, kSWM_PortPin_P0_7);

    /* USART3_RXD connect to P0_6 */
    SWM_SetMovablePinSelect(SWM0, kSWM_USART3_RXD, kSWM_PortPin_P0_6);

    /* USART4_TXD connect to P0_22 */
    SWM_SetMovablePinSelect(SWM0, kSWM_USART4_TXD, kSWM_PortPin_P0_22);

    /* USART4_RXD connect to P0_21 */
    SWM_SetMovablePinSelect(SWM0, kSWM_USART4_RXD, kSWM_PortPin_P0_21);

[Harald A. (embedded)]

Waffel schrieb:
> läuft er zumindest bis zum "test send" durch.
> sobald ich dann aber auf "continue" drücke hängts.

Hast Du mal versucht, dass Du einfach weiter beharrlich weiterstepst, 
auch wenn er augenscheinlich durch ist? Das Problem ist ja, dass der 
tatsächliche Int wesentlich später feuert. Falls da am Ende eine 
Sleep-Instruction ist (Programm-Ende) füge einfach ein While(1) oder 
ähnliches ein, wo Du dann auch weitersteppen kannst.
Was sagt denn der Alice Yang aus dem anderen Forum dazu? Der scheint ja 
recht hilfsbereit zu sein...

[Waffel (Gast)]

So lange du im Step Modus bist, werden die Interupts nicht ausgelöst. Da 
kann man dann ewig durch die main loop laufen. - Das steht als Hinweis 
extra im Datenblatt.

Wenn ich ihn aber laufen lasse, bis er hängt, und dann den Debugger 
einschalte, lande ich immer in PIN_INT6_USART3_IRQHandler - Und sehe da 
auch beim schrittweise durchgehen, das er dort im Kreis läuft. Also 
fürchte ich wirklich, dass ich da auf die Hilfe von NXP angewiesen bin. 
Falls du dich dafür interessierst, weißt du ja jetzt wo die mögliche 
Antwort von der netten Dame findest, die für NXP arbeitet.

[Johannes S. (Gast)]

Läuft das auf dem LPC845-BRK Board? Das habe ich auch und könnte das 
auch testen wenn du das Projekt hier hochlädst.

[Harald A. (embedded)]

Waffel schrieb:
> So lange du im Step Modus bist, werden die Interupts nicht ausgelöst.

Hm, ich hätte jetzt geschworen, dass ich genau das beim Debugging vom 
artverwandten LPC824 schon erlebt hätte. Kannst Du ergründen, warum er 
dort im Kreis läuft? Musst du vielleicht ein Flag selber zurücksetzen? 
Wenn er dort im Kreis läuft bist du der Lösung doch recht nahe, oder?

Waffel schrieb:
> weißt du ja jetzt wo die mögliche
> Antwort von der netten Dame findest, die für NXP arbeitet.

Natürlich Dame, ich bitte den Fauxpas zu entschuldigen. Ich hatte beim 
Kopieren irgendwie nur den Nachnamen im Blick. Ich hatte nur gesehen, 
dass die um Source bittet. Gibt es denn schon eine Lösung?

[Waffel (Gast)]

Sie hat noch nicht geantwortet, vermutlich arbeitet die nich am 
Wochenende.

[Peter D. (peda)]

Waffel schrieb:
> Der Satz heißt lediglich, dass alle
> vier Interupthandler den gleichen Inhalt haben und sich nur durch eine
> Zahl im Namen unterscheiden. Ich sehe es nicht als zielführend weil
> unübersichtlich, vier mal das gleiche zu posten.

Ich schon.
Du wärst nicht der erste, der C&P Fehler macht.
Es hat schon seinen Sinn, wenn man den echten und vollständigen Code 
postet. Schon allein die Typklarheit der "geheimen" Funktionen hilft dem 
Betrachter viel. Er kann ja nicht in Deinen Kopf schauen.
Nach Murphys Gesetz wird immer nur der Schnipsel gepostet, wo der Fehler 
nicht drin ist.
Vollständige Sourcen erlauben jedem, sie schnell mal durch den Compiler 
zu jagen und sich die Warnungen und Fehler anzeigen zu lassen. Schnipsel 
erlauben das nicht.
Du mußt im Forum nicht mit Speicherplatz sparen. Quelltexte werden ja 
nicht als BMP abgespeichert.

[Johannes S. (Gast)]

Ein Betrunkener geht die ganze Zeit auf dem Boden suchend um eine 
Straßenlaterne! Kommt ein Passant vorbei und fragt: "Suchen sie etwas?" 
"Ja, ich habe meinen Schlüssel verloren!" Der Passant hilft dem 
Betrunkenen zu suchen, doch sie finden den Schlüssel nicht! Nach einer 
Stunde fragt der Passant: "Sind sie sich sicher, dass sie den Schlüssel 
hier verloren haben?" Da antwortet der Betrunkene: "Nein, ich habe ihn 
irgendwo da hinten verloren, aber hier ist der einzige Ort, wo es Licht 
gibt!"

[Waffel (Gast)]

Danke für die dämlichen Kommentare. Aber das ist man in diesem Forum ja 
leider gewöhnt.

Das Problem ist inzwischen weiter eingegrenzt, auch wenn NXP wenig 
hilfreich war. Das erste Beispielprojekt hat einfach die polling 
Variante benutzt und so die Probleme mit dem Interrupt umgangen. Das 
nächste Beispiel war für ein anderes SDK. - Es gibt scheinbar einen 
Konflikt zwischen dem PINT (Pin-Interrupt) und dem USART Treiber aus dem 
NXP SDK. Die Documentation sagt dazu nichts, genau wie das 
Konfigurationstool keine Fehler meldet. Nachdem ich das PINT 
rausgenommen habe, was ich auch nur zum Debuggen brauchte, funktioniert 
jetzt die USART3 und USART4.

[Harald (Gast)]

Was mir auch zu dem Thema noch einfällt: Sind das die Routinen, die die 
ROM-API nutzen (weiß jetzt nicht genau, ob der LPC845 auch ROM-API für 
Serial hat)? Falls ja, da muss man doch im Linker einen RAM-Bereich 
reservieren/sperren, damit da nichts überschrieben wird. Die ROM-APIs 
nutzen ja auch RAM... Diese Info ist etwas schwierig zu finden, notfalls 
einem Beispielprojekt kopieren.

[Johannes S. (Gast)]

tja, aber genau darum ging es: der Fehler war nicht da wo du gesucht 
hast. Und wie sollen andere helfen wenn sie nur die Hälfte der Infos 
bekommen?