Re: STM32F756 strange effect
Uwe Bonnes <bon-1JbLm1bU5j5ZIx36JBfelj3+ndqKAYMe9FMPySWZwLkb1SvskN2V4Q@public.gmane.org> Tue, 12 Apr 2016 17:08:18 +0200
| Newsgroups | gmane.comp.hardware.microcontrollers.ethernut |
|---|---|
| Message-ID | <[email protected]> |
>>>>> "Holger" == Holger Mai <[email protected]> writes: ... Holger> Linkerscript is modified to use RAM from 0x20010000, same value Holger> used in configurator, "Memory Start" entry in Kernel section, Holger> because the first 64kb RAM is not accesible from DMA (Data RAM, Holger> core access only) That seems wrong. Heap, Stack annd Data should be in DTCM by default to allow fast and eventually 64-bit access. DTCM is also accessible via AHBS bus for DMA. Defaults DTCM DMA however has priority over CPU DTCM access and may in some places slow down CPU. But priority may be changed when needed. I have carefully read DM00169764 "STM32F7 Series system architecture overview" and have following conlusions: 1. Enable ICACHE/DCACHE only just before main to lower risk of inconststancies, see Tips in the document above 2. As long as no external data memory is involved, I see no reason to enable DCACHE at all. Access to DTCM/SRAM1 and SRAM2 is without wait states. If no objections arise, I will disable DCACHE in the default setup as configurable option. 3. If there is a need for DCACHE enable, http://www.nuttx.org/doku.php?id=wiki:howtos:port-drivers_stm32f7 should be considered. 4. RAMFUNC should be loaded to ITCM and not RAM, to use the additional internal buses to minimize bus contention. This needs an additional copy function in system setup and some variables in the linker. Any comments? -- 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