Re: STM32F756 strange effect

>>>>> "Holger" == Holger Mai <[email protected]> writes:

    Holger> Hi Uwe thanks for your hints, they are helpful.  indeed, the
    Holger> problem was caused by SRAM1. If let start Nut RAM on DTCM, all
    Holger> works fine. Sniffing the network packets of some Pings brings it
    Holger> up, that there is some packet data corruption on the Network
    Holger> interface, if the NIF Buffers are located in SRAM (>
    Holger> 0x20010000).

That means buffers are allocated in SRAM1.

    Holger> But this looks like only a problem of the ETH-DMA,
    Holger> even if DCache is enabled or disabled, the "normal" DMAs are not
    Holger> touched from this effect (SD-Card and other drivers with
    Holger> standard DMAs works well without any errors).

Did these devices really allocate buffers in SRAM1/2?

    Holger>  DCache is on
    Holger> startup always disabled (by default, must explicit be enabled).

D/I Cache are enabled as default since rev. 6359. The I/D Cache is now
settable since Rev. 6427. They are eventually enabled now much later since
Rev. 6426 to follow some hint in an ST app-note.

    Holger> There must be other reasons for the effect.  As first workaround
    Holger> to fix this effect: in the Driver stm32_emac.h make shure, that
    Holger> the tx- and rx-Buffers and the Buffer Descriptors are fully
    Holger> located in the DTCM Area. If they will be placed in normal SRAM,
    Holger> the ETH corrupts packet Data, even if DCache is disabled or not!

Interessting finding!

    Holger> Be aware, if youe place them manually with the section attribute
    Holger> to DTCM, and also put the BufIdx vars into DTCM, then the
    Holger> initialisation of these two fails, you must set them to 0 in the
    Holger> EmacInit function or create an own .data equivalent section for
    Holger> DTCM.  I dont can find out, if that is caused by the specialized
    Holger> ETH-DMA or other mechanisms. It is possible, that similarly
    Holger> effects come up from other peripherals with own DMAs (USB OTG
    Holger> HS,LCD-TFT, DMA2D) Next i will do is to send a support request
    Holger> to STM.

    Holger> P.S. Cache-functions are in core_cm7.h, check the cache status
    Holger> by reading the SCB-> CCR register
    Holger> (Startup value is 0x40200 = DCache disabled)

Cache handling needs to be fixed. ChibiOS had some interesting writeup about
that:
http://chibios.org/dokuwiki/doku.php?id=chibios:articles:cortexm7_dma_guide

However I will probably not find time to implement the needed changes
anytime soon. An testing these features is another subject.

So as a workaround I think about restricting SRAM on F7 to use
only 64 kiByte DTCM Ram, by setting RAM0_LENGTH to 64 kbyte in
conf/arch/arch.nut. If static allocation exceeds the limits, user would be
warned by linker. Allocation on the heap however may however fail at runtime.

NutOS would already set up SRAM2 and SRAM2 sections in a STM32F7 linker
script. If users need more memory, they would need tp partition the RAM by
themself with the section argument. It RAM from SRAM1/2 is used for DMA,
user would need to care for cahce coherenncy for themself.

Rev 6425 now places RAMFUNC in ITCM-RAM, freeing some DTCM Ram for other use.

Bye
-- 
Uwe Bonnes                bon-1JbLm1bU5j5ZIx36JBfelj3+ndqKAYMe9FMPySWZwLkb1SvskN2V4Q@public.gmane.org

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion