STM32F7 und EMACpuffer an 0x2004C000 (SRAM2)

[Dieter Gräf (Gast)]

Hat schon jemand lwip mit dieser Einstellung zum laufen bekommen? Bei 
mir ist es so das ich mit dieser Einstellung gar nicht soviel Speicher 
zur Verfügung stellen kann wie lwip verbraucht.Im ungepufferten DTCM_RAM 
funktioniert alles bestens.
Vieleicht übersehe ich ja irgendwas.

m.f.G.
Dieter

[ARJ (Gast)]

Wo hast Du denn den LWIP her?
Verwendest Du CubeHAL oder die ältere StdLib?

[Dieter Gräf (Gast)]

ARJ schrieb:
> Wo hast Du denn den LWIP her?

von hier: 
https://github.com/NETMF/netmf-interpreter/tree/dev/DeviceCode/pal/lwip_1_4_1_os/lwip/src

ARJ schrieb:
> Verwendest Du CubeHAL oder die ältere StdLib?

HAL Treiber von 
hier:https://github.com/mbedmicro/mbed/tree/master/libraries/mbed

das RTOS von 
hier:https://github.com/mbedmicro/mbed/tree/master/libraries/rtos

und den Treiber modifiziert und fehlerbereinigt von 
hier:https://github.com/mbedmicro/mbed/tree/master/libraries/net/eth/lwip-eth/arch/TARGET_STM

Es läuft auch alles stabil nur eben nicht mit dem Speicher an der 
eigentlich dafür vorgesehenen Stelle.Deswegen kann ich vermutlich auch 
die Daten leider nur mit ca. 24MBit/s per Webserver rausschieben.

m.f.G.
Dieter

[itzztitz (Gast)]

ich grabe den thread nochmal aus.
Ich habe ähnliches problem..

mit den standard linkerscripten kommt der RTOS heap und eth buiffer
auf den DTCM .. solange er unter 64kb bleibt

Das problem tritt schon auf wenn ich den RAM statt im DTCM im normalen
240kb SRAM anfangen lassen will.

also einfach mal im linkerscript RAM auf 0x20010000 setzen und größe auf 
256K
Hier geht es manchmal aber oft auch nicht... purer zufall

der effekt tritt also ein sobald man den DTCM verlässt.



Ich würde gern den 64k als RTOS heap mit 64k verwenden

die 240k als stack und restlicher statischer speicher

und die 16k SRAM2 für Ethernet

wenn es geht die 16k ITCM für cpu berechnete konvertierungen

[itzztitz (Gast)]

ok ..


http://chibios.org/dokuwiki/doku.php?id=chibios:articles:cortexm7_dma_guide

cache und so
da muss man sich durchfriemeln  :-/

[itzztitz (Gast)]

lösung ist wirklich den Dcache zu deaktivieren
dann kann man sich die sections hinlegen wie man will

stack & global  -> SRAM1
ethernet        -> SRAM2
rtos heap       -> DTCM

in wie weit mit der MPU das doch wieder machbar ist ... soweit bin ich 
noch nicht

[Dieter Graef (Gast)]

Ich leb mit DTCM Ram für die Puffer ganz gut. Mich würd aber 
interessieren obs nen Performancegewinn mit SRAM2 gibt.
Derzeit kämpf ich eher mit dem USB Host. Da scheint einiges noch nicht 
wirklich Threadfest zu sein. Zumindestens gibt's sporadische Aussetzer 
wenn nebenbei noch 12 andere Threads laufen.

m.f.G.
Dieter

[itzztitz (Gast)]

Performance kann ich jetzt nicht testen .. habe es aber auf SRAM2 gelegt

zumindest funktioniert das bisher ganz gut.
MEMORY
{
  ROM   (rx)    : ORIGIN = 0x08000000, LENGTH = 1024K /* AXIM*/
  RAM  (xrw)    : ORIGIN = 0x20010000, LENGTH = 240K  /* SRAM1 */
  RAM2  (xrw)    : ORIGIN = 0x2004C000, LENGTH = 16K   /* SRAM2 */
  RAM3   (xrw)    : ORIGIN = 0x20000000, LENGTH = 64K   /* DTCM */
  RAM4   (xrw)    : ORIGIN = 0x00000000, LENGTH = 16K   /* ITCM */
}

  .eth :
  {
    *(.eth)
    *(.eth*)
    . = ALIGN(4);
  } >RAM2




.eth            0x2004c000     0x30a0
 *(.eth)
 .eth           0x2004c000     0x30a0 src/ethernetif.o
                0x2004c000                Tx_Buff
                0x2004d7d0                DMATxDscrTab
                0x2004d850                Rx_Buff
                0x2004f020                DMARxDscrTab