STM32 - FMC: NAND Write blockiert Interrupts

Hast du mal versucht, den ISR-Vektor und den ISR-Code selbst in den RAM 
zu verlegen? Vielleicht wird der Zugriff auf den internen Flash 
irgendwie blockiert/verzögert.

Könnte das mit:

#if (USE_HAL_NAND_REGISTER_CALLBACKS == 1)

bzw. der Interrupt Prioritäten zu tun haben?

Thorsten S. schrieb:
> Es geht hier um externes NAND Flash am FMC.

Ich weiß.

Thorsten S. schrieb:
> .
> Mit dem internen NOR Flash des Controllers, in dem defaultmäßig auch die
> Vektortabelle steht, hat das gar nichts zu tun...

Würde man denken. Aber wer weiß, wie sich das beeinflusst und was da 
durch die selbe Logik geht.

Thorsten S. schrieb:
> Das Problem hier dürfte an der Verwendung blockierender HAL Routinen
> liegen.

In denen ist aber nichts von deaktivierten Interrupts zu sehen. Oder 
vielleicht in der nicht gezeigten HAL_NAND_Write_Page_8b Funktion?

Programmierer schrieb:
> Hast du mal versucht, den ISR-Vektor und den ISR-Code selbst in
> den RAM
> zu verlegen? Vielleicht wird der Zugriff auf den internen Flash
> irgendwie blockiert/verzögert.

Nein, der interne Flash sollte ja genau so wenig/viel beeinflusst sein 
wie der RAM. Zudem ist der RAM schon knapp ;)

pegel schrieb:
> Könnte das mit:
>
> #if (USE_HAL_NAND_REGISTER_CALLBACKS == 1)
>
> bzw. der Interrupt Prioritäten zu tun haben?

Thorsten S. schrieb:
> Das Problem hier dürfte an der Verwendung blockierender HAL Routinen
> liegen. Hab mich mit dem FMC bislang nicht beschäftigt, aber bei anderer
> Peripherie gibt's statt der blockierenden Varianten auch immer welche,
> die nichtblockierend über Callback-Interrupts arbeiten...

Ich habe ein FreeRTOS am laufen und der Aufruf erfolgt in einem Task. 
Die Interrupt-Priorität der anderen Interrupts sind auf 0, d.h. diese 
würden auf jeden Fall durchkommen. Vor dem Polling des Status kommen 
diese ja auch durch.

Die Zeile

1

  data = *(__IO uint8_t *)deviceaddress;

benötigt übrigens 20 Cycles habe ich gerade gesehen. Sonst wäre mir 
nichts aufgefallen was die Interrupts beeinflussen könnte. Bin weiter 
ratlos...

cc schrieb:
> Ich habe ein FreeRTOS am laufen und der Aufruf erfolgt in einem Task.

Funktioniert denn der Taskwechsel mittels (SysTick?) Timer Interrupt?

Hier übrigens die ganze Funktion - wer diese nicht selber suchen möchte. 
Die ITM_EVENTs habe ich eingefügt, um zu sehen welcher Teil wie lange 
benötigt und wo Interrupts blockiert werden. Von Abschalten der 
Interrupts ist leider nichts zu sehen...

Programmierer schrieb:
> Funktioniert denn der Taskwechsel mittels (SysTick?) Timer Interrupt?

Ja, problemlos.

Hallo,

such doch bitte mal raus, wie bei Dir die HAL_GetTick() implementiert 
ist. Das ist eine weak, die in der Defaultimplementation ohne 
Manipulation der Interruptmaske einen Zähler abfragt, der mit dem HAL 
1ms Timer ISR inkrementiert wird (das ist eines der Dinge, die ich an 
der ST HAL nicht mag). Es kann aber auch sein, dass die auf 
xTaskGetTickCount() gemappt wird, und da hast Du genau das Problem, das 
Peter in die Diskussion gebracht hat:

1

TickType_t xTaskGetTickCount( void )

2

{

3

TickType_t xTicks;

4

5

  /* Critical section required if running on a 16 bit processor. */

6

  taskENTER_CRITICAL();   <==== !!!!!!

7

  {

8

    xTicks = xTickCount;

9

  }

10

  taskEXIT_CRITICAL();    <==== !!!!!!

11

12

  return xTicks;

13

}

Peter D. schrieb:
> Irgendeine der HAL-Funktionen wird eine höhere Priorität haben, als der
> ADC-Interrupt und ihn daher ständig unterbrechen.
> Ich hätte da HAL_GetTick() in Verdacht.

Nein, das ist lediglich eine Getter Funktion die eine Variable 
zurückgibt. Die ganzen Libraries sind ja an sich nur C code welche keine 
Priorität im Sinn eines Interrupts besitzen können.

Das Auslesen des NAND-Status, welches beim schrittweise Debuggen 20 
Taktzyklen braucht benötigt - wenn ich vorher und nachher den 
Cyclecounter des Kerns auslese doch wesentlich länger, eher so im 
Bereich 300us. Das könnte das Problem sein.

RAc schrieb:
> such doch bitte mal raus, wie bei Dir die HAL_GetTick() implementiert
> ist. Das ist eine weak, die in der Defaultimplementation ohne
> Manipulation der Interruptmaske einen Zähler abfragt, der mit dem HAL
> 1ms Timer ISR inkrementiert wird (das ist eines der Dinge, die ich an
> der ST HAL nicht mag). Es kann aber auch sein, dass die auf
> xTaskGetTickCount() gemappt wird, und da hast Du genau das Problem, das
> Peter in die Diskussion gebracht hat:

Nein, wird nicht überschrieben. Die Funktion wird hier auch gar nie 
aufgerufen, die Funktion HAL_NAND_Read_Status liefert beim ersten Aufruf 
das OK.