STM32H743 mit 32MByte externem SDRAM

[Hans-Georg L. (h-g-l)]

Hallo,
ich nehme hier gerade ein STM32H743 Board mit externem 32MByte SDRAM 
über FMC in Betrieb. Scheint alles zu funktionieren, das Ram lässt sich 
schreiben und lesen.  Ich habe mir dazu ein kleines Testprogramm 
geschrieben:

    DBG_log("\r\n -------------------- SDRAM 16 bit access -------------------\r\n"); 
    
    // -------------------- write ----------------------------- 
    ExecutionTime_Begin = HAL_GetTick(); // Start time

    for (i = 0; i < SDRAM_Size / 2; i++)
    {
        *(__IO uint16_t *)(SDRAM_BANK_ADDR + 2 * i) = (uint16_t)i; // Write data to SDRAM
    }
    ExecutionTime_End = HAL_GetTick();                                       // End time
    ExecutionTime = ExecutionTime_End - ExecutionTime_Begin;                 // Elapsed time
    ExecutionSpeed = (float)SDRAM_Size / 1024 / 1024 / ExecutionTime * 1000; // Speed MB/S

    DBG_log("\r\nWrite 16-bit data , size: %d MB, elapsed time: %d ms, write speed: %.2f MB/s\r\n", SDRAM_Size / 1024 / 1024, ExecutionTime, ExecutionSpeed);

    // ----------------------------- read -------------------------------
    ExecutionTime_Begin = HAL_GetTick(); // Start time

    for (i = 0; i < SDRAM_Size / 2; i++)
    {
        ReadData = *(__IO uint16_t *)(SDRAM_BANK_ADDR + 2 * i); // Read data from SDRAM
    }

    ExecutionTime_End = HAL_GetTick();                                       // End time
    ExecutionTime = ExecutionTime_End - ExecutionTime_Begin;                 // Elapsed time
    ExecutionSpeed = (float)SDRAM_Size / 1024 / 1024 / ExecutionTime * 1000; // Speed MB/S

    DBG_log("\r\nRead 16-bit data, size: %d MB, elapsed time: %d ms, read speed: %.2f MB/s\r\n", SDRAM_Size / 1024 / 1024, ExecutionTime, ExecutionSpeed);


    DBG_log("\r\n -------------------- 16 Bit data validation  -------------------\r\n"); 
 
    for (i = 0; i < SDRAM_Size / 2; i++)
    {
        ReadData = *(__IO uint16_t *)(SDRAM_BANK_ADDR + 2 * i); // Read data from SDRAM
        if (ReadData != (uint16_t)i)                            // Detect the data, if not equal, jump out of the function, return to the detection failure results.
        {
            DBG_log("\r\nSDRAM 16 Bit data validation failed!\r\n");
            return ERROR; //Returns the failure flag
        }
    }

    DBG_log("\r\nSDRAM 16-bit data validation pass!\r\n");

Und bekomme folgende Ergebnisse:

 -------------------- SDRAM 16 bit access -------------------

Write 16-bit data , size: 32 MB, elapsed time: 175 ms, write speed: 
182.86 MB/s

Read 16-bit data, size: 32 MB, elapsed time: 1487 ms, read speed: 21.52 
MB/s

 -------------------- 16 Bit data validation  -------------------

SDRAM 16-bit data validation pass!

-------------------- SDRAM 8 bit access  -------------------

Write 8-bit data, size: 32 MB, elapsed time: 350 ms, read speed: 91.43 
MB/s

Read 8-bit data, size: 32 MB, elapsed time: 2282 ms, read speed: 14.02 
MB/s

SDRAM 8-Bit data validation pass!

Ist da wirklich so ein großer Unterschied zwischen Schreiben und lesen 
?.
Hat vielleicht jemand ein ähnliches Board und kann das mit seinen 
Treibern nach vollziehen ?

Nachtrag das Ram ist ein W9825G6KH-6I

[Hans-Georg L. (h-g-l)]

Jetzt habe ich mal gezielt den ICache ein und ausgeschaltet. Wenn ich 
den DCache auch ausschalte läuft er in den faultHandler.

Dann ergibt sich folgendes Bild:

 -------------------- SDRAM 16 bit access ICache ein -------------------

Write 16-bit data , size: 32 MB, elapsed time: 175 ms, write speed: 
182.86 MB/s

Read 16-bit data, size: 32 MB, elapsed time: 1487 ms, read speed: 21.52 
MB/s

 -------------------- SDRAM 16 bit access ICache aus -------------------

Write 16-bit data , size: 32 MB, elapsed time: 1259 ms, write speed: 
25.42 MB/s

Read 16-bit data, size: 32 MB, elapsed time: 1487 ms, read speed: 21.52 
MB/s


 -------------------- SDRAM 8 bit access ICache ein  -------------------

Write 8-bit data, size: 32 MB, elapsed time: 350 ms, read speed: 91.43 
MB/s

Read 8-bit data, size: 32 MB, elapsed time: 2282 ms, read speed: 14.02 
MB/s

-------------------- SDRAM 8 bit access ICache aus -------------------

Write 8-bit data, size: 32 MB, elapsed time: 350 ms, read speed: 91.43 
MB/s

Read 8-bit data, size: 32 MB, elapsed time: 2283 ms, read speed: 14.02 
MB/s

Warum hat das nur auf den 16 Bit Zugriff eine Auswirkung ?

Ich brauche die 32MByte Ram als Messwertspeicher muss also nur schnell 
32Bit Werte schreiben und kann sie später langsamer wieder auslesen.
Hätte mich trotzdem interessiert was da abläuft ...

[J. S. (jojos)]

Im FMC init wird das Timing für den Speicherzugriff eingestellt, wie 
sieht das denn aus?

Wenn es beim abgeschalteten D-Cache Zugriff knallt dann wird vermutlich 
ein clean/clear Cache aufgerufen, die muss man dann auch deaktivieren.

[Hans-Georg L. (h-g-l)]

Die Initialisierungs Sequenz sieht so aus:
Und der CubeMx generierte Teil ist im Anhang.

void SDRAM_Initialization_Sequence(SDRAM_HandleTypeDef *hsdram)
{
    FMC_SDRAM_CommandTypeDef Command;
    __IO uint32_t tmpmrd = 0;

    /* Configure a clock configuration enable command */
    Command.CommandMode = FMC_SDRAM_CMD_CLK_ENABLE;  // Enable SDRAM clock
    Command.CommandTarget = FMC_COMMAND_TARGET_BANK; // Select area to be controlled
    Command.AutoRefreshNumber = 1;
    Command.ModeRegisterDefinition = 0;

    HAL_SDRAM_SendCommand(hsdram, &Command, SDRAM_TIMEOUT); //  Send control command
    HAL_Delay(1);                                           //  Wait
  
    /* Configure a PALL (precharge all) command */
    Command.CommandMode = FMC_SDRAM_CMD_PALL;        // Precharge command
    Command.CommandTarget = FMC_COMMAND_TARGET_BANK; // Select area to be controlled
    Command.AutoRefreshNumber = 1;
    Command.ModeRegisterDefinition = 0;

    HAL_SDRAM_SendCommand(hsdram, &Command, SDRAM_TIMEOUT); //  Send control command

    /* Configure a Auto-Refresh command */
    Command.CommandMode = FMC_SDRAM_CMD_AUTOREFRESH_MODE; // Using Auto Refresh
    Command.CommandTarget = FMC_COMMAND_TARGET_BANK;      // Select area to be controlled
    Command.AutoRefreshNumber = 8;                        // Number of automatic refreshes
    Command.ModeRegisterDefinition = 0;

    HAL_SDRAM_SendCommand(hsdram, &Command, SDRAM_TIMEOUT); //Send control command

    /* Program the external memory mode register */
    tmpmrd = (uint32_t)SDRAM_MODEREG_BURST_LENGTH_2 |
             SDRAM_MODEREG_BURST_TYPE_SEQUENTIAL |
             SDRAM_MODEREG_CAS_LATENCY_3 |
             SDRAM_MODEREG_OPERATING_MODE_STANDARD |
             SDRAM_MODEREG_WRITEBURST_MODE_SINGLE;

    Command.CommandMode = FMC_SDRAM_CMD_LOAD_MODE;   // Load Mode Register Command
    Command.CommandTarget = FMC_COMMAND_TARGET_BANK; // Select area to be controlled
    Command.AutoRefreshNumber = 1;
    Command.ModeRegisterDefinition = tmpmrd;

    HAL_SDRAM_SendCommand(hsdram, &Command, SDRAM_TIMEOUT); // Send control command

    HAL_SDRAM_ProgramRefreshRate(hsdram, 918); // Configuring refresh rate
}

[Hans W. (Firma: Wilhelm.Consulting) (hans-)]

Wie schauen deine Compiler Flags aus?
Wie ist die variable "ReadData" deklariert?
Schon Mal das asm-listing angefragt?

73

[Hans-Georg L. (h-g-l)]

J. S. schrieb:
> Im FMC init wird das Timing für den Speicherzugriff eingestellt, wie
> sieht das denn aus?
>
> Wenn es beim abgeschalteten D-Cache Zugriff knallt dann wird vermutlich
> ein clean/clear Cache aufgerufen, die muss man dann auch deaktivieren.

Sind die Caches default beim Start aktiviert ?
Da ist die ganze Zeit nicht passiert.
Könnte vielleicht auch sein, wenn ein eingeschalteter cache deaktiviert 
wird, das er vorher geleert werden muss ?

[Hans-Georg L. (h-g-l)]

Hans W. schrieb:
> Wie schauen deine Compiler Flags aus?
> Wie ist die variable "ReadData" deklariert?
> Schon Mal das asm-listing angefragt?
>
> 73
Die variablen sind so deklariert:

    uint32_t i = 0;

    uint16_t ReadData = 0;       // 16 Bit read/write

    uint8_t ReadData_8b = 0;     // 8 bit read / write

Makefile im Anhang.

Im asm ist ja nicht nur die FMC das wollte ich mir erstmal nicht antun 
;-)

[J. S. (jojos)]

Wenn der Code von CubeMX generiert wurde dann ist der Cache in den CPU 
Einstellungen ein- oder ausgeschaltet, default ist da eingeschaltet.
Die manuelle Cache Pflege ist aber hauptsächlich bei DMA nötig, ist noch 
anderer Code für Ethernet oder SD Karte drin? Da können die herkommen. 
Sonst mal im Projekt nach SCB_ suchen.
Das Write schneller ist als Read sieht jedenfalls nicht plausibel aus.

[Hans-Georg L. (h-g-l)]

Da hier alle so wissbegierig sind und gleich Fragen nach der Hardware 
kommen ;-)

Es handelt sich um dieses Board:

https://de.aliexpress.com/item/1005006147123388.html

Schaltplan dazu im Anhang.

[J. S. (jojos)]

Interessant, das ist glaube ich noch nicht in meiner Sammlung, muss mal 
nachschauen.

Beim DMA ist bekannt das man den Cache manuell pflegen muss, aber ich 
muss auch noch einen Fehler suchen bei dem Daten aus dem Flash nicht 
aktualisiert werden. Da bin ich mir auch sicher das es mit dem Cache 
zusammenhängt. Jedenfalls hat der starken Einfluß auf die Laufzeit.
Der Cache beim H7 ist sehr tückisch.

[Hans-Georg L. (h-g-l)]

J. S. schrieb:
> Wenn der Code von CubeMX generiert wurde dann ist der Cache in den CPU
> Einstellungen ein- oder ausgeschaltet, default ist da eingeschaltet.
> Die manuelle Cache Pflege ist aber hauptsächlich bei DMA nötig, ist noch
> anderer Code für Ethernet oder SD Karte drin? Da können die herkommen.
> Sonst mal im Projekt nach SCB_ suchen.
> Das Write schneller ist als Read sieht jedenfalls nicht plausibel aus.

CubeMx setzt die caches "normalerweise" am Anfang der Main. Und dort 
habe
ich mit  SCB_EnableICache(); / SCB_DisableICache(); und 
SCB_EnableDCache();/
SCB_DisableDCache(); herumgespielt.

Ist im Moment nur QSPI Flash (8Mb), USB CDC und 2 x SPI für ein ILI9488 
TFT mit Touch drin.

Nachtrag und eine USART für debug;

[J. S. (jojos)]

Hans-Georg L. schrieb:

> CubeMx setzt die caches "normalerweise" am Anfang der Main. Und dort
> habe
> ich mit  SCB_EnableICache(); / SCB_DisableICache(); und
> SCB_EnableDCache();/
> SCB_DisableDCache(); herumgespielt.
>

Ist richtig, das kann aber in CubeMX in den CPU Einstellungen gesetzt 
werden ob Enabled oder Disabled.
Bei Disabled darf man dann nicht die SCB_Invalidate oder SCB_Clear 
aufrufen, das könnte z.B. auch im USB Code drinstehen. Oder SPI wenn der 
mit DMA arbeitet. Es crasht also woanders.

[Mi N. (msx)]

Ich würde zunächst die Schreib-/Lesesignale mit dem Skope am SDRAM 
ansehen. Ggf. sind dort schon viele 'waitstates' vorhanden.
Alternativ eine Initialisierung ohne CubeMX schreiben, die sich 
vielleicht an anderer Stelle im Netz findet - zumindest als Grundlage.

[Hans-Georg L. (h-g-l)]

J. S. schrieb:
> Hans-Georg L. schrieb:
>
>> CubeMx setzt die caches "normalerweise" am Anfang der Main. Und dort
>> habe
>> ich mit  SCB_EnableICache(); / SCB_DisableICache(); und
>> SCB_EnableDCache();/
>> SCB_DisableDCache(); herumgespielt.
>>
>
> Ist richtig, das kann aber in CubeMX in den CPU Einstellungen gesetzt
> werden ob Enabled oder Disabled.
> Bei Disabled darf man dann nicht die SCB_Invalidate oder SCB_Clear
> aufrufen, das könnte z.B. auch im USB Code drinstehen. Oder SPI wenn der
> mit DMA arbeitet. Es crasht also woanders.

Mit:
  SCB_CleanDCache();
vor
  SCB_DisableDCache();

läuft es durch;

[J. S. (jojos)]

Ok, guter Hinweis.
Ändert sich denn ohne D-Cache etwas an den Zeiten?

[Hans-Georg L. (h-g-l)]

Mi N. schrieb:
> Ich würde zunächst die Schreib-/Lesesignale mit dem Skope am SDRAM
> ansehen. Ggf. sind dort schon viele 'waitstates' vorhanden.
> Alternativ eine Initialisierung ohne CubeMX schreiben, die sich
> vielleicht an anderer Stelle im Netz findet - zumindest als Grundlage.

Und warum sollten diese "waitstates" nur beim lesen und nicht beim 
schreiben auftauchen ?

CubeMx initialisiert ja nur die FMC Register die Ram Initialisierung und 
das schreiben und lesen ist von dem Code für STM Disco Boards abgeschaut 
und angepasst.

[Hans-Georg L. (h-g-l)]

J. S. schrieb:
> Ok, guter Hinweis.
> Ändert sich denn ohne D-Cache etwas an den Zeiten?

Ja, jetzt sehen die schreib/lese Zugriffe im 8 Bit modus logischer aus.

 ----------------  FK743M5 Board Tests  -----------------

 -------------------- SDRAM 16 bit access -------------------

Write 16-bit data , size: 32 MB, elapsed time: 175 ms, write speed: 
182.86 MB/s

Read 16-bit data, size: 32 MB, elapsed time: 1487 ms, read speed: 21.52 
MB/s

-------------------- SDRAM 8 bit access -------------------

Write 8-bit data, size: 32 MB, elapsed time: 2377 ms, read speed: 13.46 
MB/s

Read 8-bit data, size: 32 MB, elapsed time: 2283 ms, read speed: 14.02 
MB/s

[Hans-Georg L. (h-g-l)]

Wenn ich nur FMC und meine Debug Uart laufen lasse und keinen Cache 
enable

Bekomme ich das:

 -------------------- SDRAM 16 bit access -------------------

Write 16-bit data , size: 32 MB, elapsed time: 1329 ms, write speed: 
24.08 MB/s

Read 16-bit data, size: 32 MB, elapsed time: 1487 ms, read speed: 21.52 
MB/s

 -------------------- SDRAM 8 bit access  -------------------

Write 8-bit data, size: 32 MB, elapsed time: 2378 ms, read speed: 13.46 
MB/s

Read 8-bit data, size: 32 MB, elapsed time: 2282 ms, read speed: 14.02 
MB/s

Mein Fazit:

A.) ICache beschleunigt mein FMC Test beim schreiben aber nicht beim 
lesen, DCache hat darauf keinen Einfluß.

B.) Irgend ein anderes Teil in meinem Programm aktiviert den ICache 
zwischen dem 16 Bit und dem 8 Bit Test, das erklärt warum das 8 Bit 
Schreiben immer schnell ist.

Einwände ?

[J. S. (jojos)]

Der D-Cache scheint keinen Einfluss zu haben, beim I-Cache ist es eher 
der Code der dann darein passt. So würde ich das interpretieren.

[Hans-Georg L. (h-g-l)]

J. S. schrieb:
> Der D-Cache scheint keinen Einfluss zu haben, beim I-Cache ist es eher
> der Code der dann darein passt. So würde ich das interpretieren.

Das sehe ich auch so, aber warum passt die Schreibschleife in den Cache 
und die Leseschleife nicht ?

[Hans-Georg L. (h-g-l)]

Hans-Georg L. schrieb:
> Da hier alle so wissbegierig sind und gleich Fragen nach der Hardware
> kommen ;-)
>
> Es handelt sich um dieses Board:
>
> https://de.aliexpress.com/item/1005006147123388.html
>
> Schaltplan dazu im Anhang.

Noch ein Nachtrag zu diesem Board:

Falls es jemand braucht ...
USB 2.0 ist damit nicht möglich weil sich ULPI und FMC überschneiden.

PIN PC0  OTG_HS_ULPI_STP ist bereits mit FMC_SDNWE belegt und kann nicht 
umkonfiguriert werden.

[J. S. (jojos)]

Hat das denn einen externen ULPI Phy?

[Hans-Georg L. (h-g-l)]

J. S. schrieb:
> Hat das denn einen externen ULPI Phy?

On Board ist keiner aber es lässt sich extern aus dem genannten Grund 
auch keiner anschließen. Den FMC PIN könnte man umlegen aber dazu müsste 
man den Hersteller finden und überzeugen ;-) Und BGA fädeln macht auch 
keinen Spaß.

[J. S. (jojos)]

Ok, ja Schade, so externe ULPI Boards gibt es ja auch für ein paar Euro. 
Es gibt die STM Disco Boards mit zusätzlichem Speicher und Display, aber 
die sind leider ein ganzes Stück teurer.

[Hans-Georg L. (h-g-l)]

J. S. schrieb:
> Ok, ja Schade, so externe ULPI Boards gibt es ja auch für ein paar Euro.
> Es gibt die STM Disco Boards mit zusätzlichem Speicher und Display, aber
> die sind leider ein ganzes Stück teurer.

Also On Board sind:
32MByte RAM, 8MByte QSPI Flash, SD-Karten Slot, Kamera Anschluss, LCD 
Schnittstelle SPI und Parallel dazu noch ca. 80 Pin über Steckerleiste.

[Mi N. (msx)]

Hans-Georg L. schrieb:
> Das sehe ich auch so, aber warum passt die Schreibschleife in den Cache
> und die Leseschleife nicht ?

Beide passen da rein, mit dem Unterschied, daß beim Schreiben zunächst 
in ein FIFO des FMC geschrieben wird bzw. werden kann. Gepufferte Daten 
können dann schneller gespeichert werden. Beim Lesen muß immer gewartet 
werden, bis das SDRAM die Daten auch geliefert hat.

Darum würde ich mir ansehen, wie die Zugriffe auf das SDRAM aussehen. 
Läuft alles in einem Rutsch, was kaum zu glauben wäre, oder wird Byte 
für Byte mit vielen Taktzyklen und womöglich noch mit Pausen gelesen.
Aber gut, das interessiert nur, wenn man die Zugriffe möglichst schnell 
ausgeführt haben möchte.

[Hans-Georg L. (h-g-l)]

Mi N. schrieb:
> Darum würde ich mir ansehen, wie die Zugriffe auf das SDRAM aussehen.
> Läuft alles in einem Rutsch, was kaum zu glauben wäre, oder wird Byte
> für Byte mit vielen Taktzyklen und womöglich noch mit Pausen gelesen.
> Aber gut, das interessiert nur, wenn man die Zugriffe möglichst schnell
> ausgeführt haben möchte.

Ach Michael ich bin jetzt 75 Jahre, halb blind und zittrig ;-).
Da würde ich ungern Drähtchen an den BGA Chip oder das Ram zum messen 
löten.  Falls ich es mal schneller brauche gibt es auch noch den 
Schreib/Lese Burst-Mode und kann vielleicht ja auch noch an den 
Parametern drehen.

QSPI geht auch

 -------------------- QSPI Test -------------------

W25Q64 Initialization OK, Flash ID:EF4017

QSPI Erase 32k Block, 223 ms

QSPI Write Buffer, size: 32 KB, elapsed time: 50 ms, speed: 640.00 KB/s

QSPI Read Buffer, size: 32 KB, elapsed time: 5 ms, speed: 6400.00 KB/s

PASS QSPI Read and Write Buffer are identical

QSPI Read entire Flash, size: 8 MB, elapsed time: 1067 ms, speed: 29.99 
MB/s

! Wegen der kurzen Messzeit und der Auflösung von 1ms sind manche Werte 
nur grob

[Mi N. (msx)]

Hans-Georg L. schrieb:
> Ach Michael ich bin jetzt 75 Jahre, halb blind und zittrig ;-).
> Da würde ich ungern Drähtchen an den BGA Chip oder das Ram zum messen
> löten.

Ja, ich verstehe. Man kann unter Umständen auch viel kaputt machen.
Deinen zuerst genannten Wert von rund 180 MB/s fand ich nur so 
verlockend, daß das dann gleich die Messlatte für alle Zugriffe sein 
sollte ;-)
Für Messwerspeicherung reicht es wohl allemal.

[J. S. (jojos)]

Hans-Georg L. schrieb:
> ich nehme hier gerade ein STM32H743 Board mit externem 32MByte SDRAM
> über FMC in Betrieb.

hast du zu diesem Board mehr Infos? Ich konnte nicht widerstehen und 
habe es auch gekauft.
Da ist schon eine Software drauf, am UART am Programmer Anschluss 
bekommt man einige Logs. Den richtigen Zeichensatz habe ich nicht 
gefunden, aber es scheint ein Test des SDRAM zu sein, ein LCD mit Touch 
sowie ein Kameramodul wird gesucht.
Der Kameraanschluss hat leider 20 Pins statt wie die 24 bei der ESP Cam, 
die Module passen so direkt nicht. Auch für das LCD mit RGB muss ich mir 
einen Adapter bauen, habe da nur was mit 6 Bit RGB.

21:12:49.116> W25Q64 OK,flash ID:EF4017
21:12:49.116> RTOS ÈÎÎñ²âÊÔ
21:12:49.174> LCDÃæ°åʶ±ð£º02
21:12:49.549> Touch Error
21:12:49.549> 
21:12:49.610> **************************** SDRAM²âÊÔ **************************** 
21:12:49.673> ÒÔ16λÊý¾Ý¿í¶ÈдÈëÊý¾Ý£¬´óС£º16 MB
21:12:50.364> ¶ÁÈ¡Êý¾ÝÍê±Ï£¬´óС£º16 MB
21:12:50.364> ½øÐÐÊý¾ÝУÑé>>>
21:12:51.174> 16λÊý¾Ý¿í¶È¶Áдͨ¹ý£¬ÒÔ8λÊý¾Ý¿í¶ÈдÈëÊý¾Ý
21:12:51.174> дÈëÍê±Ï£¬¶ÁÈ¡Êý¾Ý²¢±È½Ï...
21:12:51.174> 8λÊý¾Ý¿í¶È¶Áдͨ¹ý
21:12:51.174> SDRAM¶Áд²âÊÔͨ¹ý£¬ÏµÍ³Õý³£
21:12:51.174> 
21:12:51.174> **************************** SD¿¨²âÊÔ **************************** 
21:12:51.174> ¼ì²â²»µ½SD¿¨
21:12:51.174> 
21:12:51.174> **************************** W25Q64²âÊÔ **************************** 
21:12:51.360> W25Q64 ²Á³ý³É¹¦>>>
21:12:51.424> дÈë³É¹¦>>>
21:12:51.424> ½øÈëÄÚ´æÓ³Éäģʽ³É¹¦£¬¿ªÊ¼¶ÁÈ¡>>>>
21:12:51.424> ¶ÁÈ¡³É¹¦>>>
21:12:51.424> УÑéͨ¹ý!!!!! QSPIÇý¶¯W25Q64²âÊÔÕý³£
21:12:51.424> 
21:12:51.424> **************************** ÉãÏñÍ· ²âÊÔ **************************** 
21:12:51.424> OV2640 ERROR!!!!!  ID:0
21:12:51.551> OV5640 ERROR!!!!!  ID:0
21:12:51.551> δ¼ì²âµ½ÉãÏñÍ·Ä£¿é£¡£¡£¡£¡£¡

[Andreas M. (amesser)]

Lesebefehle auf einer CPU sind immer langsamer als Schreibbefehle. Wenn 
etwas geschrieben werden muss, dann kann die CPU Daten und Adresse auf 
den Bus schicken und einfach weiter machen, sie muss normalerweise nicht 
darauf warten, dass die Daten im Ziel angekommen sind. Beim Lesen 
hingegen muss zuerst eine Adresse abgesetzt werden, dann wird auf die 
Daten gewartet und dann gehts erst weiter. Das kann man zwar ein bischen 
in der Pipeline verstecken, hilft aber nix wenn man von langsamer 
Peripherie (z.B. SDRAM liest) Deswegen gibts ja Caches.

Allerdings erscheint mir hier der Unterschied viel zu groß. Zumal der 
FSMC eine Read-Fifo hat, die genau bei solchen Sequentiellen Reads 
helfen sollte die Wait-States zu minimieren.

Ausnahme zu der Regel oben: Speicherbereiche die als "strongly order" 
markiert sind. Da muss der Zugriff komplett fertig sein, bevor der 
nächste gemacht wird.

Möglicherweise ist die MMU/MPU nicht richtig eingestellt so das SDRAM 
nicht als "Normal" memory getagt ist.

[Hans-Georg L. (h-g-l)]

Andreas M. schrieb:
> Möglicherweise ist die MMU/MPU nicht richtig eingestellt so das SDRAM
> nicht als "Normal" memory getagt ist.

FMC SDRAM Bank1 0xCC000000 - 0xCFFFFFFF
Attribute: "device" "Non-shareable" "execute never"

Speculative data reads and speculative cache linefills are never made to 
Device memory addresses.

[Hans-Georg L. (h-g-l)]

J. S. schrieb:
> hast du zu diesem Board mehr Infos?

Nein, habe ich leider nicht ;-(

Wie ich zu dem Board gekommen bin hat eine kleine Vorgeschichte.

Zuerst hatte ich ein STMh750 Board gefunden und gleich 2 bestellt. 
Leider nur 128Kb Flash intern, aber 8Mbyte Flash on Board.
Dann habe ich das STM32H743 Board gefunden ohne externes RAM ( 1 
bestellt).
Als nächstes ein STM32H7 Board mit externem RAM. MCU im FP Gehäuse ( 0 
bestellt). Und dann habe ich dieses Board gefunden mit MCU im BGA 
Gehäuse. Nachdem ich ein Schaltbild dazu gefunden hatte. (2 bestellt).
Den QSPI (für  das H750) Treiber habe ich von irgendeiner chinesischen 
Seite und die Kommentare in englisch übersetzt. Der SDRAM Treiber ist 
einem Disco Board nachempfunden. Das ioc File für CubeMX ist gewachsen 
;-)
Mein ILI9488 LCD und der Touch XPT2046 laufen über SPI5 und SPI6.
Viel mehr läuft noch nicht.

Am 743 Board ohne externes Ram hängt im Moment ein 3300 ULPI Board, 
funktioniert aber noch nicht.

Aufbau siehe:
Beitrag "Re: Quick&dirty - schnelle Problemlösungen selbst gebaut"

[J. S. (jojos)]

Das H743 Board ohne ext. RAM habe ich auch, DevEBox, Ver.2.0. Da habe 
ich ein Display mit lvgl dran und mal q'd IRMP zum Testen eingebaut. Die 
sind recht gut, haben aber eben kein ext. RAM.

Von den H743 mit SDRAM habe ich jetzt auch beide Versionen, die sind 
durch die großen H743 mit den vielen Pins auch interessant. Da möchte 
ich auch ein RGB Display anschließen.
Bei Ali habe ich mehrere Händler für diese Boards gefunden, einer 
(Online-parts Store) hat auch Varianten mit Display sowie das passende 
Kameraboard.
Ich hatte die in einem gekauft, den Link zum Schaltplan haben die mir 
auf Anfrage innerhalb von 10 Minuten geschickt, aber nichts zur Demo 
Software.

Deine Adapter mit VG Leiste für die doppelreihigen Pinheader sind 
interessant :) Ich habe lange Pinheader eingelötet die von oben und 
unten kontaktiert werden können, die sind für so Testaufbauten auch 
praktisch.

[Hans-Georg L. (h-g-l)]

Hallo J.S

Ich habe dir mal alles was ich so für das Board habe gezippt.
Mit dem CubeMx ioc File kannst du dir ein make Projekt generieren und 
dann die QSPI und SDRam Files einfügen.

Das ioc ist mit dem aller neuesten CubeMX 6.12.1 und FW H7 V1.11.2 
erzeugt, da ist aber ein Bug und das erzeugt Linkerscript funktioniert 
nicht. Ich habe ein funktionierendes hinzugefügt.

Im Excel Sheet steht die Pinbelegung.

Wenn du auch noch die Tests und Debug-Ausgabe an UART1 brauchst sag 
bescheid.

[J. S. (jojos)]

Danke,
habe mir gerade einen Adapter für den STLink V3 gebaut. Bekomme aber 
keine Verbindung zum Target, bei beiden Boards die gleiche 
Fehlermeldung.

 22:48:33 : ST-LINK FW  : V3J13M4
 22:48:33 : Board       : STLINK-V3MINI
 22:48:33 : Voltage     : 3.30V
 22:48:33 : Error: No STM32 target found! If your product embeds Debug Authentication, please perform a discovery using Debug Authentication

Debug Authentication hat der H7 soweit ich weiß aber nicht.

[Hans-Georg L. (h-g-l)]

J. S. schrieb:
> Danke,
> habe mir gerade einen Adapter für den STLink V3 gebaut. Bekomme aber
> keine Verbindung zum Target, bei beiden Boards die gleiche
> Fehlermeldung.
>
>

>  22:48:33 : ST-LINK FW  : V3J13M4
>  22:48:33 : Board       : STLINK-V3MINI
>  22:48:33 : Voltage     : 3.30V
>  22:48:33 : Error: No STM32 target found! If your product embeds Debug 
> Authentication, please perform a discovery using Debug Authentication
>

>
> Debug Authentication hat der H7 soweit ich weiß aber nicht.

Kenn ich auch nicht .. ich benutze hier Stlink v2.1 von den Nucleo 
Boards und auf JLink umgeflashed oder einen JLink EDU mini. Versuch mal 
mit dem St-Programmer eine Verbindung zu finden.

[J. S. (jojos)]

Ich benutze den STM32CubeProgrammer, V 2.15. Es gibt einen neueren, aber 
das Update zickt auch, auch wenn ich den als Admin starte.

[Hans-Georg L. (h-g-l)]

J. S. schrieb:
> Ich benutze den STM32CubeProgrammer, V 2.15. Es gibt einen neueren, aber
> das Update zickt auch, auch wenn ich den als Admin starte.

Hast du vielleicht einen H7R als Target eingestelllt, der hat 
Authentication.

[J. S. (jojos)]

nein, der Programmer liest ja normalerweise erstmal die CPUID zeigt 
wenigstens diese an, aber da kommt schon die Fehlermeldung.

[Hans-Georg L. (h-g-l)]

J. S. schrieb:
> nein, der Programmer liest ja normalerweise erstmal die CPUID zeigt
> wenigstens diese an, aber da kommt schon die Fehlermeldung.

Hmmm ... ich hatte mit keinem der 5 Boards Probleme.

Hast du vielleicht noch ein Nucleo Board, da kannst du es mit dem Stlink 
V2 probieren.

[J. S. (jojos)]

es lag an meinem Adapter, Verbindung zwischen Ober- und Unterseite bei 
einem Pin. Als ich nur die Buchse aufgelötet hatte, da habe ich es noch 
durchgemessen und es war ok. Mit Kabel zum STLink habe ich nicht mehr 
gemessen...

Mit dem CubeProgrammer unter WSL2 bekomme ich jetzt die Verbindung, mit 
der Windows Version nicht, obwohl ich die bisher schon unzählige Male 
benutzt habe. Ich probiere morgen weiter, jetzt habe ich keinen Nerv 
mehr.

Doch, jetzt klappt es auch unter Windows. Hurra, es kann weitergehen. 
Morgen.

[Hans-Georg L. (h-g-l)]

Meine Files sind für das BGA Board. Das ist Klar oder ?

[J. S. (jojos)]

ja, der SWD Anschluss ist bei beiden gleich. Ich wollte erst ein blinky 
auf diesem Board ans laufen bekommen. Dieses hat auch irgendeinen Code 
drauf, eine blaue LED blinkt langsam, aber über die serielle kommt 
nichts raus. Am USB-C macht das einen virtuellen COM Port auf, aber auch 
da kommt nichts. Ist eventuell ein Bootloader drauf.

[Hans-Georg L. (h-g-l)]

Hans-Georg L. schrieb:
> Andreas M. schrieb:
>> Möglicherweise ist die MMU/MPU nicht richtig eingestellt so das SDRAM
>> nicht als "Normal" memory getagt ist.
>
> FMC SDRAM Bank1 0xCC000000 - 0xCFFFFFFF

Das ist ein Vertipper richtig ist:
FMC SDRAM Bank1 0xC1000000 - 0xCFFFFFFF

> Attribute: "device" "Non-shareable" "execute never"
>
> Speculative data reads and speculative cache linefills are never made to
> Device memory addresses.

Jetzt habe ich mal zum Spaß für den SDRAM Bereich den Caches enabled und 
lande dann beim Zugriff im memory fault handler.  Das scheint die 
falsche Schraube zu sein ;-)

[J. S. (jojos)]

ja, falsche Cache Einstellungen nimmt er schnell übel.

Ich habe mein Adapterkabel verbessert, durch einen gecrimpten Stecker 
ersetzt. Weiß nicht warum ich das nicht sofort so gemacht habe...
Trotzdem war die Verbindung nicht stabil, mal ging es und meist nicht, 
mit verschiedenen Fehlermeldungen. Dann fiel mir ein das der USB-C Hub 
an meinem Dell Laptop rumzickt, die Verbindung zum Headset ist darüber 
z.B. auch schlecht. STLink an einen anderen, USB 2.0 Hub eingesteckt und 
zack lief es.
Jetzt hangele ich mich auch weiter.

[Hans-Georg L. (h-g-l)]

Wie heißt doch gleich der Spruch:
Kaum macht man es richtig - funktionierts ;-)

 ----------------  FK743M5 Board Tests  -----------------

 -------------------- SDRAM 16 bit access -------------------

Write 16-bit data , size: 32 MB, elapsed time: 178 ms, write speed: 
179.78 MB/s

Read 16-bit data, size: 32 MB, elapsed time: 301 ms, read speed: 106.31 
MB/s

 -------------------- 16 Bit data validation  -------------------

SDRAM 16-bit data validation pass!

 -------------------- SDRAM 8 bit access  -------------------

Write 8-bit data, size: 32 MB, elapsed time: 280 ms, read speed: 114.29 
MB/s

Read 8-bit data, size: 32 MB, elapsed time: 390 ms, read speed: 82.05 
MB/s

SDRAM 8-Bit data validation pass!

-------------------- LCD Test -------------------

LCD_FillScreen Test takes: 62 ms

-------------------- Bitmap LCD Test -------------------

LCD_Draw_Bitmap 480x320 RGB takes: 214 ms

[J. S. (jojos)]

und was war es?

> read speed: 114.29
hier ist noch eine Kleinigkeit, da sollte write speed stehen (beim 8 Bit 
Test).

Mein Blinky bzw. printf auf Konsole läuft auch, ich baue das Ganze mit 
Mbed. Die Boards gibt es dafür natürlich nicht, das ist erst die meiste 
Arbeit die einzupflegen.
Für den fmc Code wollte ich dein .ioc öffnen, dazu musste ich noch 
einige Updates installieren. Ich hoffe es schreddert nicht meine 
wichtigen Projekte...

[Andreas M. (amesser)]

Hans-Georg L. schrieb:
>> Attribute: "device" "Non-shareable" "execute never"
>>
>> Speculative data reads and speculative cache linefills are never made to
>> Device memory addresses.
>
> Jetzt habe ich mal zum Spaß für den SDRAM Bereich den Caches enabled und
> lande dann beim Zugriff im memory fault handler.  Das scheint die
> falsche Schraube zu sein ;-)

Ja klar geht der in Fault, der Fehler hier ist zunächstmal das der 
Speicher als "Device" getaggt ist. "Device" Memory kann bzw darf nicht 
gecached sein. SDRAM sollte "Normal" sein. Dazu kommt, das beim STM32H7 
der Bereich nicht "Shareable" sein darf, weil dann der D-Cache 
abgeschaltet wird. (Dem fehlen die Units um "Shareable" zu 
synchronisieren)

Hans-Georg L. schrieb:
> Wie heißt doch gleich der Spruch:
> Kaum macht man es richtig - funktionierts ;-)

Was meinst du damit? Was hast Du geändert? Schön das es jetzt geht!

[Hans-Georg L. (h-g-l)]

Andreas M. schrieb:
> Hans-Georg L. schrieb:
>>> Attribute: "device" "Non-shareable" "execute never"
>>>
>>> Speculative data reads and speculative cache linefills are never made to
>>> Device memory addresses.
>>
>> Jetzt habe ich mal zum Spaß für den SDRAM Bereich den Caches enabled und
>> lande dann beim Zugriff im memory fault handler.  Das scheint die
>> falsche Schraube zu sein ;-)
>
> Ja klar geht der in Fault, der Fehler hier ist zunächstmal das der
> Speicher als "Device" getaggt ist. "Device" Memory kann bzw darf nicht
> gecached sein. SDRAM sollte "Normal" sein. Dazu kommt, das beim STM32H7
> der Bereich nicht "Shareable" sein darf, weil dann der D-Cache
> abgeschaltet wird. (Dem fehlen die Units um "Shareable" zu
> synchronisieren)
>
> Hans-Georg L. schrieb:
>> Wie heißt doch gleich der Spruch:
>> Kaum macht man es richtig - funktionierts ;-)
>
> Was meinst du damit? Was hast Du geändert? Schön das es jetzt geht!

Ich habe an 2. Stellen geändert.

1.)  I/O Cell compensation eingeschaltet

  __HAL_RCC_CSI_ENABLE() ;
    
  __HAL_RCC_SYSCFG_CLK_ENABLE();

  HAL_EnableCompensationCell(); 

2.) Die MPU so eingestellt.

  /* Configure the MPU attributes as WB for SDRAM */
  MPU_InitStruct.Enable = MPU_REGION_ENABLE;
  MPU_InitStruct.BaseAddress = 0xC0000000;   // SDRAM_ADDRESS;
  MPU_InitStruct.Size = MPU_REGION_SIZE_32MB;
  MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
  MPU_InitStruct.IsBufferable = MPU_ACCESS_BUFFERABLE;
  MPU_InitStruct.IsCacheable = MPU_ACCESS_CACHEABLE;
  MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
  MPU_InitStruct.Number = MPU_REGION_NUMBER1;
  MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
  MPU_InitStruct.SubRegionDisable = 0x00;
  MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;




Und die FMC Einstellung ist geblieben  FMC_SDRAM_CAS_LATENCY_2 ist zu kurz;

  /** Perform the SDRAM1 memory initialization sequence
  */
  hsdram1.Instance = FMC_SDRAM_DEVICE;
  /* hsdram1.Init */
  hsdram1.Init.SDBank = FMC_SDRAM_BANK1;
  hsdram1.Init.ColumnBitsNumber = FMC_SDRAM_COLUMN_BITS_NUM_9;
  hsdram1.Init.RowBitsNumber = FMC_SDRAM_ROW_BITS_NUM_13;
  hsdram1.Init.MemoryDataWidth = FMC_SDRAM_MEM_BUS_WIDTH_16;
  hsdram1.Init.InternalBankNumber = FMC_SDRAM_INTERN_BANKS_NUM_4;
  hsdram1.Init.CASLatency = FMC_SDRAM_CAS_LATENCY_3;
  hsdram1.Init.WriteProtection = FMC_SDRAM_WRITE_PROTECTION_DISABLE;
  hsdram1.Init.SDClockPeriod = FMC_SDRAM_CLOCK_PERIOD_2;
  hsdram1.Init.ReadBurst = FMC_SDRAM_RBURST_ENABLE;
  hsdram1.Init.ReadPipeDelay = FMC_SDRAM_RPIPE_DELAY_1;
  /* SdramTiming */
  SdramTiming.LoadToActiveDelay = 2;
  SdramTiming.ExitSelfRefreshDelay = 7;
  SdramTiming.SelfRefreshTime = 4;
  SdramTiming.RowCycleDelay = 7;
  SdramTiming.WriteRecoveryTime = 3;
  SdramTiming.RPDelay = 2;
  SdramTiming.RCDDelay = 2;

Nachtrag bei dem Wert bin ich mitr nich sicher  MPU_REGION_SIZE_32MB
sind mit size Bytes gemneint oder hängt das von der RAM busbreite ab ?.
(32M x16)
Wenn Bytes gemeint sind müsste es auf 64 ist ein 256Megabit Ram

[J. S. (jojos)]

mbed-ce hello-world
Hello from FK743M2_IIT6
Mbed OS version: 6.17.0


Write 16-bit data , size: 32 MB, elapsed time: 176 ms, write speed: 181.82 MB/s

Read 16-bit data, size: 32 MB, elapsed time: 1494 ms, read speed: 21.42 MB/s

 -------------------- 16 Bit data validation  -------------------

SDRAM 16 Bit data validation failed!

bis auf den Fail sind es ziemlich die gleichen Zahlen wie im ersten 
Post.

Hans-Georg L. schrieb:
> Nachtrag bei dem Wert bin ich mitr nich sicher  MPU_REGION_SIZE_32MB
> sind mit size Bytes gemneint

sind afaik Bytes

[Hans-Georg L. (h-g-l)]

Du musst die MPU einstellungen in main.c  per Hand hinzufügen dann sieht 
es so aus.

void MPU_Config(void)
{
  MPU_Region_InitTypeDef MPU_InitStruct = {0};

  /* Disables the MPU */
  HAL_MPU_Disable();

  /** Initializes and configures the Region and the memory to be protected
  */
  MPU_InitStruct.Enable = MPU_REGION_ENABLE;
  MPU_InitStruct.Number = MPU_REGION_NUMBER0;
  MPU_InitStruct.BaseAddress = 0x08000000;
  MPU_InitStruct.Size = MPU_REGION_SIZE_2MB;
  MPU_InitStruct.SubRegionDisable = 0x0;
  MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
  MPU_InitStruct.AccessPermission = MPU_REGION_PRIV_RO;
  MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;
  MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
  MPU_InitStruct.IsCacheable = MPU_ACCESS_CACHEABLE;
  MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;

  HAL_MPU_ConfigRegion(&MPU_InitStruct); 
  

    /* Configure the MPU attributes as WB for SDRAM */
  MPU_InitStruct.Enable = MPU_REGION_ENABLE;
  MPU_InitStruct.BaseAddress = 0xC0000000;   // SDRAM_ADDRESS;
  MPU_InitStruct.Size = MPU_REGION_SIZE_32MB;
  MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
  MPU_InitStruct.IsBufferable = MPU_ACCESS_BUFFERABLE;
  MPU_InitStruct.IsCacheable = MPU_ACCESS_CACHEABLE;
  MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
  MPU_InitStruct.Number = MPU_REGION_NUMBER1;
  MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
  MPU_InitStruct.SubRegionDisable = 0x00;
  MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;

  HAL_MPU_ConfigRegion(&MPU_InitStruct);


  /* Enables the MPU */
  HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);

}

und controlliere die FMC einstellungen.

[J. S. (jojos)]

hattest du denn auch den Verify Fehler ohne MPU?
Evtl. ist noch das Init falsch, habe beide so drin:

  MX_FMC_Init();
  SDRAM_Initialization_Sequence(&hsdram1);

[Hans-Georg L. (h-g-l)]

J. S. schrieb:
> bis auf den Fail

Hast du die SDRAM Initialisierungs sequence vorher aufgerufen ?

[Hans-Georg L. (h-g-l)]

J. S. schrieb:
> hattest du denn auch den Verify Fehler ohne MPU?
> Evtl. ist noch das Init falsch, habe beide so drin:
>

>   MX_FMC_Init();
>   SDRAM_Initialization_Sequence(&hsdram1);
>

Der verify hat schon immer funktioniert. Hat nichts mit der MPU zu tun.

[Hans-Georg L. (h-g-l)]

Blöde Frage ... Benutzt du auch das Board mit BGA Gehäuse ?

[J. S. (jojos)]

beide liefen den gleichen Fehler, beim IIT6 könnte die SDRAM Belegung 
natürlich anders sein, habe ich jetzt nicht verglichen.
Das low level hardware Init wird noch fehlen.
Aber ich muss langsam Schluss machen für heute.

[Hans-Georg L. (h-g-l)]

J. S. schrieb:
> beide liefen den gleichen Fehler, beim IIT6 könnte die SDRAM Belegung
> natürlich anders sein, habe ich jetzt nicht verglichen.
> Das low level hardware Init wird noch fehlen.
> Aber ich muss langsam Schluss machen für heute.

Anbei mal mein Core verzeichnis da kannst du morgen vergleichen.

[J. S. (jojos)]

Das BoardTest() fehlt noch. Aber meine beiden Init calls sehen erstmal 
gut aus.
Die beiden Board Versionen haben das SDRAM natürlich anders 
angeschlossen, wenn ich das so übernehme dann läuft es nur das BGA 
Board. Aber das müsste der einzige Unterschied sein um den Code auf 
beiden zu nutzen.

[Hans-Georg L. (h-g-l)]

bitteschön ;-)

[J. S. (jojos)]

Von dem Online-Parts Ali Shop habe ich eine Antwort mit Link bekommen, 
1,3 GB mit vielen Beispielprojekten und Dokumentation. Leider alles in 
Chinesisch...
https://mail.qq.com/cgi-bin/ftnExs_download?k=5135353317ec559b518e5b6d1765021b4e4101500304010d1b030605084856060703180008515419050505055053520701040c5231573083828af860652803067e020100692c78028cfee5f78180939c667677e3fcdff5727d0201007c501d6c7f7d0390984b4255443508&t=exs_ftn_download&code=65531e04

Ich kämpfe noch mit dem Debugger, das klappt in meiner Umgebung (VSCode 
mit Cortex-Debug Extension) noch nicht.
Das messen der SDRAM Signale ist auch schwierig, die liegen nicht an den 
Pinheadern.

[Hans-Georg L. (h-g-l)]

Du brauchst einen Ordner ".vscode" in deinem Projekt und darin ein File 
launch.json mit folgendem Inhalt. Musst du natürlich auf dein Projekt 
und deine Pfade anpassen

{

    "version": "0.2.0",
    "configurations": 
    [
        

        {
           // "showDevDebugOutput": "raw",
            "name": "Debug ST-Link",
      "type": "cortex-debug",
      "request": "launch",           
          "cwd": "${workspaceRoot}",
            "executable": "${workspaceRoot}/build/Blink_hal.elf",
            "runToEntryPoint": "main",
            "servertype": "stlink",
            "device": "STM32H753ZI",
            "svdFile": "C:/STM32_SVD/STM32H753x.svd", 
            "interface": "swd",
            "serverpath" :"C:/STM32Tools/Stlink_GDB_Server/tools/bin/ST-LINK_gdbserver",
            "configFiles": 
            [
                "config.txt",
            ],           
        }
    ]
}

Habe mir mal das China zeug heruntergeladen. Der Hersteller des Boards 
scheint "Fanke electronics" zu sein. Habe die Firma aber nicht im 
Internet gefunden.

[J. S. (jojos)]

Fanke könnte eine Unterdivision von Guilin Technologies sein, der Name 
stand ein einem Dokument in Chinesich über dem Fanke Schriftzug. Fanke 
stand auch in dem Schaltplan vom IIT6 Board.

Mit dem Cortex-Debug habe ich schon eine Menge gemacht, auch andere H743 
laufen damit. Die Konfig wird hier jetzt von Mbed-CE generiert, das geht 
über arm-gdb und STLinkGDBServer. Den servertype stlink probiere ich 
auch nochmal.
Es hatte auch anfangs mal geklappt, dann habe ich die Target Anpassung 
für das Board sauberer gemacht und seitdem geht es nicht mehr, das 
bekomme ich aber hin.
Der STLinkGDBServer bekommt eine Verbindung, hängt sich dann aber auf 
beim lesen von Registern auf. Da ist die Meldung 'CM4 failed' komisch, 
das ist ja ein CM7 single core.

CM4 Failed to read all registers
ST-LINK device status: Failed to get status, Target not responding, retrying... 19
Target is not responding, retrying...
Failed to read registers from target

[Hans-Georg L. (h-g-l)]

J. S. schrieb:
> Das messen der SDRAM Signale ist auch schwierig, die liegen nicht an den
> Pinheadern.

Die haben da auch nichts zu suchen.

Habe mir mal das China zeug heruntergeladen...

Die FMC Einstellungen und Initialisierung vom Ram sind identisch wie bei 
mir, die Pinbelegung habe ich nicht verglichen.

[Andreas M. (amesser)]

J. S. schrieb:
> Das messen der SDRAM Signale ist auch schwierig, die liegen nicht an den
> Pinheadern.

Messen? Du hast ein Oszi mit 1GHz Bandbreite? (Nicht Sampling Rate!) 
Wenn Nein, dann vergiss das mit dem Messen mal ganz schnell wieder. Bei 
den Taktraten muss man sich auch langsam um Signallaufzeiten, Impedanzen 
(und Reflektionen) Gedanken machen. Insbesondere da SDRAM noch 
"Single-Ended" ist. z.B. sollte auch bei 100MHz die Clock Leitung 
zumindest länger als die Daten/Adressleitungen sein.

Und wer jetzt meint das wäre übertrieben. Ja, für den 
Schreibtisch/Bastler mag das ohne all das gehen. Wenn man sowas in einem 
Schaltschrank mit erweitertem Temperaturbereich packt wo auch noch 
andere Sachen unterwegs sind... viel Spaß. Wir hatten schon Rückläufer 
wegen ungünstigem Layout. "Geht" heißt halt nicht "geht immer".

[J. S. (jojos)]

Mit dem Oszi würde ich die CS  RAS  CAS Signale sehen wollen ob sich 
da überhaupt etwas tut, also die Konfiguration gelaufen ist.
Es gibt andere Boards wo zusätzliches RAM Optional ist und die Signale 
daher auch extern verfügbar sind. Hier ist es fest auf dem Board und da 
macht es natürlich Sinn diese hochfrequenten Signale nicht unnötig über 
das Board zu führen.

[Hans-Georg L. (h-g-l)]

J. S. schrieb:
> Mit dem Oszi würde ich die CS  RAS  CAS Signale sehen wollen ob sich
> da überhaupt etwas tut, also die Konfiguration gelaufen ist.
> Es gibt andere Boards wo zusätzliches RAM Optional ist und die Signale
> daher auch extern verfügbar sind. Hier ist es fest auf dem Board und da
> macht es natürlich Sinn diese hochfrequenten Signale nicht unnötig über
> das Board zu führen.

Da sitzt ein STM32H7 in der Revision V drauf, der läuft mit 480 MHz das 
bedeutet das Ram läuft mit 120 MHz. Deshalb hatte ich ja das BGA Board 
gewählt. Board mit Ram und parallel Stichleitungen zu den Pin-Headern 
bringen doch nur zusätzliche Leitungskapazitäten und Kopplung.

[Gregor J. (Firma: Jasinski) (gregor_jasinski)]

Hans-Georg L. schrieb:
> Da sitzt ein STM32H7 in der Revision V drauf, der läuft mit 480 MHz das
> bedeutet das Ram läuft mit 120 MHz. Deshalb hatte ich ja das BGA Board
> gewählt. Board mit Ram und parallel Stichleitungen zu den Pin-Headern
> bringen doch nur zusätzliche Leitungskapazitäten und Kopplung.

Ja, und solche parasitären Kapazitäten bei diesen Frequenzen gilt es zu 
vermeiden, denn die werden schneller zuschlagen als irgendwelche 
Signallaufzeitdifferenzen.

[J. S. (jojos)]

Ich habe bei dem Board noch Probleme mit dem Debugger (STLinkV3):
Wenn ich durch SetSysClock() steppe, dann verliert der Debugger die 
Verbindung nach 
__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);
mit der Meldung:
"Failed to read registers from target".
Zu diesem Problem habe ich zwei Beiträge in der STCommunity gefunden, 
einmal sollen Debug Einstellungen geholfen haben, die ändern hier aber 
nicht. Dann eine andere, externe Spannungsversorgung. Damit komme ich 
ein paar Schritte weiter, richtig zuverlässig ist es aber immer noch 
nicht. Stromversorgung habe ich über eine angzapfte VUSB zum 
Programmierstecker und da auch zwei verschiedene USB probiert, die 
liefern 5.0 V / 4,65 V über ext. Hubversorgung.
Dann die 5V extern von einen LaborNT eingespeist, damit geht es etwas 
besser, aber eben nicht 100 %.
Der Fehler tritt gleichermaßen auf in der CubeIDE (in WSL2) sowie mit 
VSCode, was aber auch arm-none-eabi-gdb und STLINK GDB Server nutzt.

@Hans-Georg: könntest du das auch mal probieren, einen BP in SetSysClock 
setzen und mit Step Over da durch gehen?

[Hans-Georg L. (h-g-l)]

J. S. schrieb:
> @Hans-Georg: könntest du das auch mal probieren, einen BP in SetSysClock
> setzen und mit Step Over da durch gehen?

Kein Problem bei mir ich kann da durchsteppen.

Ich hatte nur mal mit einer früheren CubeMx version das Problem das 
Flash Latency falsch gesetzt war.

Aber nicht bei diesen Boards.

[J. S. (jojos)]

ok, Danke.
Ich habe die CubeIDE im WSL2 laufen und auf 1.16.1 aktualisiert. Auch 
VSCode läuft im WSL, ich werde es noch mal auf einem Rechner ohne WSL 
testen um das ohne die usbidp Brücke zu testen. Das hat allerdings immer 
sehr zuverlässig funktioniert, auch mit anderen H7.

[Hans-Georg L. (h-g-l)]

CubeIDE und WSL verwende ich nicht.

Nur CubeMx als Code Generator und VsCode (Erweiterungen siehe Bild).

[Hans-Georg L. (h-g-l)]

J. S. schrieb:
> ok, Danke.
> Ich habe die CubeIDE im WSL2 laufen und auf 1.16.1 aktualisiert. Auch
> VSCode läuft im WSL, ich werde es noch mal auf einem Rechner ohne WSL
> testen um das ohne die usbidp Brücke zu testen. Das hat allerdings immer
> sehr zuverlässig funktioniert, auch mit anderen H7.

Schalte mal die Taktfrequenz auf 400Mhz runter vielleicht sind das auf V 
umgelabelte  Y Revisionen.

[J. S. (jojos)]

Die Revision wird über eine ID ausgelesen, danach passt das. Mit HSI als 
Clock lief es auch etwas besser, aber nicht so gut wie mit ext. 
Versorgung.

[Luca (spaghetto)]

Hi guys,
sorry for my english post but as an Italian person my languages 
knowledge include a lot of local dialects but, unfortunately,  not the 
German. And I totally refuse to include an answer translated by Google.

I was reading by days this thread looking at your development on 
FK743M5-XIH6 board, which I've bought in the meanwhile.

I was doing some test on the SDRAM maximum achievable speed, running a 
mix of Fanke code and above one and, despite the values of the first 
post, I got a speed under 100MB/s!

 -------------------- SDRAM 16 bit access -------------------
Write 16-bit data , size: 8 MB, elapsed time: 96 ms, write speed: 83.33 MB/s
Read 16-bit data, size: 8 MB, elapsed time: 142 ms, read speed: 56.34 MB/s
SDRAM 16-Bit data validation pass, elapsed time: 186 ms
-------------------- SDRAM 8 bit access  -------------------
Write 8-bit data, size: 8 MB, elapsed time: 174 ms, write speed: 45.98 MB/s
Read 8-bit data, size: 8 MB, elapsed time: 238 ms, read speed: 33.61 MB/s
SDRAM 8-Bit data validation pass, elapsed time: 326 ms

MPU is enabled on the memory, D/ICache is enabled in the .ioc, the test 
are the same and the very only difference is a FMC speed of 220MHz 
(because I've read of 110MHZ max FMC speed here: 
https://community.st.com/t5/stm32-mcus/how-to-set-up-the-fmc-peripheral-to-interface-with-the-sdram/ta-p/49457 
), but the 240MHz makes no substantial differences (only in decimals). 
I've also checked the .ioc attached above and nothing changes.

Please could you share your project\ioc\check out my configuration 
below, in order to let me achieve higher (w\r aligned) speeds?

Thanks,
Luca

Full code attached to this post, snippets of relatable configurations 
follows below.


FMC config:

  hsdram1.Instance = FMC_SDRAM_DEVICE;
  /* hsdram1.Init */
  hsdram1.Init.SDBank = FMC_SDRAM_BANK1;
  hsdram1.Init.ColumnBitsNumber = FMC_SDRAM_COLUMN_BITS_NUM_9;
  hsdram1.Init.RowBitsNumber = FMC_SDRAM_ROW_BITS_NUM_13;
  hsdram1.Init.MemoryDataWidth = FMC_SDRAM_MEM_BUS_WIDTH_16;
  hsdram1.Init.InternalBankNumber = FMC_SDRAM_INTERN_BANKS_NUM_4;
  hsdram1.Init.CASLatency = FMC_SDRAM_CAS_LATENCY_3;
  hsdram1.Init.WriteProtection = FMC_SDRAM_WRITE_PROTECTION_DISABLE;
  hsdram1.Init.SDClockPeriod = FMC_SDRAM_CLOCK_PERIOD_2;
  hsdram1.Init.ReadBurst = FMC_SDRAM_RBURST_ENABLE;
  hsdram1.Init.ReadPipeDelay = FMC_SDRAM_RPIPE_DELAY_1;
  /* SdramTiming */
  SdramTiming.LoadToActiveDelay = 2;
  SdramTiming.ExitSelfRefreshDelay = 7;
  SdramTiming.SelfRefreshTime = 4;
  SdramTiming.RowCycleDelay = 7;
  SdramTiming.WriteRecoveryTime = 3;
  SdramTiming.RPDelay = 2;
  SdramTiming.RCDDelay = 2 ;

MPU config:

  MPU_InitStruct.Enable = MPU_REGION_ENABLE;
  MPU_InitStruct.Number = MPU_REGION_NUMBER0;
  MPU_InitStruct.BaseAddress = 0xC0000000;
  MPU_InitStruct.Size = MPU_REGION_SIZE_32MB;
  MPU_InitStruct.SubRegionDisable = 0x0;
  MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
  MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
  MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;
  MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
  MPU_InitStruct.IsCacheable = MPU_ACCESS_CACHEABLE;
  MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;

Clock config:

  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE|RCC_OSCILLATORTYPE_LSE;
  RCC_OscInitStruct.HSEState = RCC_HSE_ON;
  RCC_OscInitStruct.LSEState = RCC_LSE_ON;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
  RCC_OscInitStruct.PLL.PLLM = 5;
  RCC_OscInitStruct.PLL.PLLN = 192;
  RCC_OscInitStruct.PLL.PLLP = 2;
  RCC_OscInitStruct.PLL.PLLQ = 8;
  RCC_OscInitStruct.PLL.PLLR = 2;
  RCC_OscInitStruct.PLL.PLLRGE = RCC_PLL1VCIRANGE_2;
  RCC_OscInitStruct.PLL.PLLVCOSEL = RCC_PLL1VCOWIDE;
  RCC_OscInitStruct.PLL.PLLFRACN = 0;

[J. S. (jojos)]

I’m not at my PC right now, but the SDRAM timing settings look the same 
as mine or what Hans Georg has published here.
Have you checked the clock tree if the clock settings are ok? The values 
in your snippet look also ok, but e.g. the FMC clock source could be 
wrong.
I can check your code later.

[Andreas M. (amesser)]

Your MPU Config is not optimal. Your setting only enables caches for 
SDRAM but not for instruction memory. Thus the instructions are not 
cached an need to be loaded every time from flash. (Flash is slow, the 
maximum speed of internal flash of this device is 70MHz)

Please note the settings above were two MPU regions are configured. The 
first MPU region is for caching the instructions and the second is for 
caching SDRAM. Also the SDRAM Region should be set to "Bufferable", this 
improves Write Speed.

You should also check that your code is compiled with optimizations 
enabled and not in debug mode without any optimizations. ("Optimization 
Level" should be set to -O2 or -Os)

[Hans-Georg L. (h-g-l)]

Hi Luca,

in your main.c change the function void MPU_Config(void) to

  
void MPU_Config(void)
{
  MPU_Region_InitTypeDef MPU_InitStruct = {0};

  /* Disables the MPU */
  HAL_MPU_Disable();

  /** Initializes and configures the Region and the memory to be protected
  */
  MPU_InitStruct.Enable = MPU_REGION_ENABLE;
  MPU_InitStruct.Number = MPU_REGION_NUMBER0;
  MPU_InitStruct.BaseAddress = 0x08000000;
  MPU_InitStruct.Size = MPU_REGION_SIZE_2MB;
  MPU_InitStruct.SubRegionDisable = 0x0;
  MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
  MPU_InitStruct.AccessPermission = MPU_REGION_PRIV_RO;
  MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;
  MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
  MPU_InitStruct.IsCacheable = MPU_ACCESS_CACHEABLE;
  MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;

  HAL_MPU_ConfigRegion(&MPU_InitStruct);

/* USER CODE BEGIN 1 */

    /* Configure the MPU attributes as WB for SDRAM */
  MPU_InitStruct.Enable = MPU_REGION_ENABLE;
  MPU_InitStruct.BaseAddress = 0xC0000000;   // SDRAM_ADDRESS;
  MPU_InitStruct.Size = MPU_REGION_SIZE_64MB;
  MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
  MPU_InitStruct.IsBufferable = MPU_ACCESS_BUFFERABLE;
  MPU_InitStruct.IsCacheable = MPU_ACCESS_CACHEABLE;
  MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
  MPU_InitStruct.Number = MPU_REGION_NUMBER1;
  MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
  MPU_InitStruct.SubRegionDisable = 0x00;
  MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;

  HAL_MPU_ConfigRegion(&MPU_InitStruct);

/* USER CODE END 1 */
 

  /* Enables the MPU */
  HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);

}

>

[Hans-Georg L. (h-g-l)]

Andreas M. schrieb:

> You should also check that your code is compiled with optimizations
> enabled and not in debug mode without any optimizations. ("Optimization
> Level" should be set to -O2 or -Os)

Der Unterschied hat mich mal interessiert hier der Vergleich:

**************** Debug build  DEBUG =1 OPT = Og **************************
 
 -------------------- SDRAM 16 bit access -------------------

Write 16-bit data , size: 32 MB, elapsed time: 178 ms, write speed: 179.78 MB/s

Read 16-bit data, size: 32 MB, elapsed time: 301 ms, read speed: 106.31 MB/s

 -------------------- 16 Bit data validation  -------------------

SDRAM 16-bit data validation pass!

 -------------------- SDRAM 8 bit access  -------------------

Write 8-bit data, size: 32 MB, elapsed time: 280 ms, write speed: 114.29 MB/s

Read 8-bit data, size: 32 MB, elapsed time: 390 ms, read speed: 82.05 MB/s

****************** Release build  DEBUG =0 , OPT = O2  ******************

-------------------- SDRAM 16 bit access -------------------

Write 16-bit data , size: 32 MB, elapsed time: 144 ms, write speed: 222.22 MB/s

Read 16-bit data, size: 32 MB, elapsed time: 232 ms, read speed: 137.93 MB/s

 -------------------- 16 Bit data validation  -------------------

SDRAM 16-bit data validation pass!

 -------------------- SDRAM 8 bit access  -------------------

Write 8-bit data, size: 32 MB, elapsed time: 209 ms, write speed: 153.11 MB/s

Read 8-bit data, size: 32 MB, elapsed time: 243 ms, read speed: 131.69 MB/s

[J. S. (jojos)]

I don't see a difference wether the MPU region for 0x8000000 is enabled 
or not. Usually, enabling the ICache does not need a MPU setting.

[Luca (spaghetto)]

It's been years since I didn't get in touch to such a collaborative 
forum, kudos to all of you.

Thanks, furthermore, for the info provided. I've made some tests and 
results follow below. Actual configuration is -O1 + D/ICache Enabled + 
MPU on SDRAM (not shareadble, cacheable, not bufferable). ioc attached 
to this post.

  -------------------- SDRAM 16 bit access -------------------
Write 16-bit data , size: 8 MB, elapsed time: 39 ms, write speed: 205.13 MB/s
Read 16-bit data, size: 8 MB, elapsed time: 60 ms, read speed: 133.33 MB/s
SDRAM 16-Bit data validation pass, elapsed time: 89 ms
-------------------- SDRAM 8 bit access  -------------------
Write 8-bit data, size: 8 MB, elapsed time: 39 ms, write speed: 205.13 MB/s
Read 8-bit data, size: 8 MB, elapsed time: 66 ms, read speed: 121.21 MB/s
SDRAM 8-Bit data validation pass, elapsed time: 168 ms
Waiting for reboot...

1. Code optimization seems to play an important role, -O1, -O2, -O3, 
-0fast seems to get all the same (fast) results, above all -O1 get a ten 
of MB more in reading on 16bit; others configuration get slight worse 
speed.
2. Enabling ICache and DCache also is fundamental. Turning off ICache 
slows the 8bit read to 13.40 MB/s. Turning off DCache slows both 8 and 
16 bit reads to  23.05 MB/s and 15.01 MB/s.
3. Configuring MPU on 0x8000000 seems to have no substantial effect at 
all if I\DCache are disabled.
4. Configuring MPU on SDRAM seems to have an important effect, but, 
enabling the bufferability seems to have no effect at all. Enabling the 
shareability when DCache is disabled get slow reading speeds: both 22.47 
MB/s.

My actual problem is, since I use SDRAM to store "slow" data (10Sa/s 
ADC) which have to be used for "very fast" analysis (RMS calculation), I 
have to enhance reading speeds which still get slow if compared to 
reading. I've understand what Andreas said above (31.10), but I have 
seen no additional answers so I was wondering if any of you get the 
problem solved.

Thanks,
Luca

[J. S. (jojos)]

The test loop is very short with a few cpu cycles, and so a difference 
of +/- 1 cycle caused by the optimization has a big effect on the 
result. The loop should also fit into the instruction cache, which makes 
it fast or much slower when it gets larger and does not fit.
So I think for a real application these speed results have a limited 
relevance.

[Andreas M. (amesser)]

Luca schrieb:
> My actual problem is, since I use SDRAM to store "slow" data (10Sa/s
> ADC) which have to be used for "very fast" analysis (RMS calculation), I
> have to enhance reading speeds which still get slow if compared to
> reading. I've understand what Andreas said above (31.10), but I have
> seen no additional answers so I was wondering if any of you get the
> problem solved.

Hi Luca. Are you sure its the SDRAM and not you algorithm by itself? RMS 
sounds like Sqare-Roots (Slow), Multiplication & Additions (Should be 
fast). You could also consider an improved alogrithm. For instance if 
you have a moving average algorithm, one approach could be to store the 
sum in a single variable and each sampled value in a ring buffer (length 
= number of samples). When a new sample comes in, you take the sum, 
subtract the value of current ring buffer index, add the new sample to 
the sum and store the new sample to ringbuffer index, increment ring 
buffer index. (Divide sum by number of samples to yield result). Thus it 
does not matter if your moving avg is 100 or 100000 samples. The update 
is always constant in time.

[Axel V. (axel-f)]

Gutes Neues Jahr erstmal!

Kannst Du mir sagen, mit welchem Frequenz bei Dir das QSPI angesprochen 
wird? Auf meinem selbsterstellten Board komme ich nur bis 40 MHz SCLK. 
Leider habe ich die Längswiderstände im QSPI nicht layoutet, aber auf 
dem chin. Testboard, von dem Du den Schaltplan gezeigt hast, sind auch 
keine drin.

Danke, Axel

[Hans-Georg L. (h-g-l)]

Axel V. schrieb:
> Gutes Neues Jahr erstmal!
>
> Kannst Du mir sagen, mit welchem Frequenz bei Dir das QSPI angesprochen
> wird? Auf meinem selbsterstellten Board komme ich nur bis 40 MHz SCLK.
> Leider habe ich die Längswiderstände im QSPI nicht layoutet, aber auf
> dem chin. Testboard, von dem Du den Schaltplan gezeigt hast, sind auch
> keine drin.
>
> Danke, Axel

Wünsche auch allen ein gutes neues Jahr.

Hallo Axel, QSPI hängt am HCLK3 (240 MHz) und der Prescaler steht auf 1 
( div 2) also läuft es mit 120 MHz.

Und die GPIO sind auf GPIO_SPEED_FREQ_VERY_HIGH initialisiert.

[Axel V. (axel-f)]

120 MHz, das ist mal wirklich zackig! Aber ich sehe gerade, daß bei mir 
die GPIO auf GPIO_SPEED_FREQ_LOW initialisiert sind. Das ist natürlich 
Quark.

Danke nochmals,
Axel

[Axel V. (axel-f)]

Hallo Hans-Georg,

habe es entsprechend geändert; jetzt läuft es sogar mit 133 MHz stabil!

Gruß
Axel

[Luca (spaghetto)]

Andreas M. schrieb:
> Hi Luca....You could also consider an improved alogrithm. For instance if
> you have a moving average algorithm, one approach could be to store the
> sum in a single variable and each sampled value in a ring buffer (length
> = number of samples).

That changed really the scenario, the solution is kinda perfect but, for 
completely other reasons, the solution still is not working.

Let me expand the scenario to better explain the project I'm working on: 
A 4ch 1MSa/s 16bit acquisitor which outputs via USB the RMS value of 
last 100ms window every 100ms.

So I've setted up a:

*SDRAM*: We've already talked in depth about this.

*ADC1*:
- Resolution: ADC 16-bit resolution,
- Scan Conversion Mode: Enabled,
- End Of Conversion Selection: End of sequence of conversion
- Conversion Data Management Mode: DMA Circular Mode
- Enable Regular Conversions: Enable
- Number of Conversion: 4
- External Rrigger Conversion Edge: Trigger detection on the rising edge
..setted up the 4 Ranks with channels 4-5-1-19
...setted up the DMA Settings as: DMA1 Stream 0 Circular, Memory\Word, 
Priority Very High

*TIM1*: 1MHz (prescaler:23 / counter:9) + PWM Generation CH1 Update 
Event

*TIM13*: 10Hz (prescaler:59999 / counter:399)

Then (with Xcnt=100000),

void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef *hadc){ 
...  if(hadc1.Init.NbrOfConversion>0){ //<-Optimization delete the unused conversions when configured via .IOC
    tempval=*(__IO uint16_t *)(Ablock + 2*i);
    Asum -= tempval*tempval;
    tempval=AD_RES_BUFFER[0];
    *(__IO uint16_t *)(Ablock + 2*i)=tempval;
    Asum += (uint64_t)tempval*tempval;
  }

... (does the same for the other 3 channels)...

  //Advance index
  i=(i==Xcnt-1)?0:i+1;
...
}

In the main:

...
if(PrintFlag){ //todo Print data on TIM14 interrupt (10Hz)
      sprintf(text,"A:%f,B:%f,C:%f,D:%f\r\n",
          (q*sqrt(Asum/Xcnt)),
          (q*sqrt(Bsum/Xcnt)),
          (q*sqrt(Csum/Xcnt)),
          (q*sqrt(Dsum/Xcnt))
          );
      usb_print(text);

      PrintFlag=0;
   }

I was so happy with the results on 2 channels, but *when I scaled up to 
4 channels, everything stopped working*...
I'm attaching the full code actually configured for 2ch A:R1:ADC1.4 / 
B:R2:ADC1.5, please give it a try enabling 3 or 4 on "Number of 
Conversion" and configuring ranks with ADC1.1 or ADC1.19 (Already 
configured) and you'll see strange behaviours I really can't debug! :(

It has been two days trying to change configurations and code with no 
success, I'm kinda desperate.

Thanks all in advance for anyone will help.

Luca

[Andreas M. (amesser)]

Hi,

Luca schrieb:
> It has been two days trying to change configurations and code with no
> success, I'm kinda desperate.

I did not yet check you project in detail but: I assume 4 Channels, each 
with 1 MS/s is just too fast what this CPU can handle in such a design. 
As of your algo I assume these are about (10 to 20) instructions times 4 
channels. This alone costs about 80MIPs. I further assume 
"HAL_ADC_ConvCpltCallback" run in some interrupt context which is 
somehow abstracted in some layers of the STM Cube code. This abstraction 
costs performance in addition to interrupt entry itself. (For instance a 
Cortex M7 CPU has 12 clocks latency for ITCM Code in optimal situation, 
thus a 100 MHz clocked Cortex M7 can handle no more than about 8 Million 
Interrupts/s when the handlers are empty and CPU is not doing anything 
else) I would assume in your design the interrupt handling costs again 
something in the order of 10 to 100 MIPs.

What you can do is use a different DMA Buffer scheme: Since you only 
look at 10 Hz intervals, an idea would be to process data in blocks:

Each DMA Buffer contains more than one sample/per channel: E.g. 128 
Entries 4 Samples per Entry (one per channel). Thus you get 1MS/s / 128 
~ 8 kHz Interrupt rate. You process 128 Samples en block per channel. 
This saves you from wasting CPU time with interrupt entry / leave. You 
can even optimize the summing since you only need to store one sum per 
128 elements. You use two dma buffers, one is filled  by ADC/DMA, the 
other is processed. (Double buffer scheme)

Just google about STM32, ADC & Double buffer will show some examples how 
to do that.

[Josep (controlxic)]

Hello everyone
After I visit this post sometimes and I beneficied to your comments and 
files.
I know so this post is only for SDRAM but... I don't find another 
references for tihis board, so I upload my project for FK743M5 board raw 
for gratitude in case anyone wants to take advantage of something.

The project contains:
SDRAM
QSPI + .stldr
LTDC
CDC
Soft I2C for touch
Screen config for LCD 5inc

Maked with stm32cubeide1.17.0

Best regards

Materials:
https://es.aliexpress.com/item/1005008122901025.html
http://www.lcdwiki.com/5.0inch_RGB_Display
https://de.aliexpress.com/item/1005007419018735.html?spm=a2g0o.order_list.order_list_main.5.21ef194dEkU9jJ&gatewayAdapt=glo2deu_list.order_list_main.5.21ef194dEkU9jJ&gatewayAdapt=glo2deu

[J. S. (jojos)]

I've loaded your .elf files, but I get only
'15:23:30.249> Address: 0x0 Data:' over the USB serial.

So it looks like your display is different, I have the 5" display that 
comes bundled with the FK boards. It has a GT911 multitouch controller, 
so that seems to be different.
I have added Mbed Suspport for this Board and display and lvgl is 
running fine on this board due to a lot of RAM.

edit:
when I remove the I2C read, the it works, also your logo is displayed on 
the screen.

[Josep (controlxic)]

Hello J.S.

Thanks for testing the code, in relation to the usb.
It may be that it needs to be configured in ?
Project Properties > Build > settings > misc > Other flags.
Add: -u printF_float

I still have to make the library for the FT5426 driver but the soft I2C 
communication already works. This driver is also 10 touch points.
The screen works with the adapter from the previous link, also if you 
can put a 7 inch screen.
The final intention is also to run LVGL, I really believe in the 
author's project.

Greetings.

PD: SDRAM addresses do not correspond to sector sizes.

[J. S. (jojos)]

This display adapter is nice, have not seen it before. The FK boards 
have a non standard pin assignment for the LCD screens, so with this 
adapter it is possible to use other displays as well. I wanted to design 
such an adapter also, but it is easier to order the ready one :)

Also, there is a large documentation from Fanke for this board, it 
contains a lot of samples also for lvgl.

[Luca (spaghetto)]

Andreas M. schrieb:
> ...What you can do is use a different DMA Buffer scheme: Since you only
> look at 10 Hz intervals, an idea would be to process data in blocks...

Good evening Andreas, thanks for your answer. I had problems running 
that code because of a well known issue concerning DMA when D-Caching is 
enabled, fully covered in st community forum here 
https://community.st.com/t5/stm32-mcus/dma-is-not-working-on-stm32h7-devices/ta-p/49498. 
I understood that a direct workaround was moving DMA buffer to separate 
memory (RAM_D2), I just missed that memory had to be protected via MPU.

In STM32H743XIHX_FLASH.ld:

  .dma_buffer :
  {
    *(.dma_buffer)
  } >RAM_D2

In main.c:

...
__attribute__((section(".dma_buffer"))) uint16_t   ADCbuf[4];    //ADC to DMA buffer
...
void MPU_Config(void)
{
...
  MPU_InitStruct.Number = MPU_REGION_NUMBER1;
  MPU_InitStruct.BaseAddress = 0x30000000;
  MPU_InitStruct.Size = MPU_REGION_SIZE_1KB;
  MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
...

I don't know if 480MHz and pipelining of some sort...or just luck, but 
the code is running with no issues 4ch @16bit f_adc=50MHz tsample=2.5cyc 
RMSout every 100ms (a manual of overrun check which confirmed not a 
single count is lost).

I abandoned the SDRAM cyclic buffering (since I accumulate data for 
100ms and output the value in the main at the very last count, I don't 
need past data), to push things faster I tried also to reduce the 
interrupt time moving buffer reset (at the beginning of the cycle) in 
main() (using a 2 buffers scheme), but with no luck, I've just confirmed 
the fact you underlined in your last post that the biggest problem is 
the cpu overhead for context saving\restore in every interrupt event 
which is already taking too much time to get other operations in a 1us 
window.
So, if needed, I confirm other different implementations are needed.

FYI, I've just seen that on the FANKE shop 
(https://shop212360197.world.taobao.com/) many other boards are 
available, among them there is also an interesting STM32H750XBH6 version 
of the ours.

I've just released the beta of the project (a demonstrator for a 16bit 
acquisition module which we're going to design for an academic research 
project), I've the validation of the system in this week, finger 
crossed. Thanks everyone for the priceless help.

Luca

[Julius W. (Firma: None) (julius_wj)]

Hello everyone,

I was reading this forum quite a while ago and decide to buy the board.
after the board arrived, I tried to follow the example from this forum 
and I don't know what I do wrong, I can't read the memory at all.

I use stm32 cube ide, and when I tried to read memory address 
0xC0000000, it shows '????????', not a random hex, even when I tried to 
write some data, nothing changed.

This is my first time dealing with sdram so I follow all the setting 
that was written on this forum.

I need help.
Thank you.

Julius.

[J. S. (jojos)]

What about the FMC init, have you used the init from CubeMX? There you 
need to set the alternate functions to match the schematics. The default 
does not work, there are many different alternatives for the pins.

[Julius W. (Firma: None) (julius_wj)]

the mistake is on me,

I should have read the schematic carefully :(

my mistake in assigning the sdram pin to default.
I assign the correct pin now,

SDNE0  -> PH3
SDCKE0 -> PH2

the default pin from MX was

SDNE0  -> PC2
SDCKE0 -> PC3

the result is as intended:

0xC0000000 : 0xC0000000 <Unsigned Integer>
  Address   0 - 3             4 - 7             8 - B             C - F
  C0000000  0                 1                 2                 3
  C0000010  4                 5                 6                 7
  C0000020  8                 9                 10                11
  C0000030  12                13                14                15
  C0000040  16                17                18                19
  C0000050  20                21                22                23
  C0000060  24                25                26                27
  C0000070  28                29                30                31
  C0000080  32                33                34                35