2022-07-13 12:40 PM
Hello,
The linker script in the demo example specifies:
/* Specify the memory areas */
MEMORY
{
FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 2048K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 499K
Memory_B1(xrw) : ORIGIN = 0x2007C000, LENGTH = 0xA0
Memory_B2(xrw) : ORIGIN = 0x2007C0A0, LENGTH = 0xA0
}
/*..*/
{
.ARM.attributes 0 : { *(.ARM.attributes) }
.RxDecripSection (NOLOAD) : { *(.RxDescripSection) } >Memory_B1
.TxDescripSection (NOLOAD) : { *(.DMATxDscrTab_section) } >Memory_B2
}
However, after compile:
So the .RxDescripSection is correctly located in Memory_B1
But it seems that .TxDescripSection does not end up in Memory_B2
I have no clue why the linker seems to discard the spec to relocated TxDescripSection to Memory_B2 (According to RM0410 page 76, locations do exist as SRAM2 in the processor)
Thanks for any advice,
Johi.
2022-07-19 09:42 AM
I would offer that line 13 should read:
.TxDescripSection (NOLOAD) : { *(. TxDescripSection) } >Memory_B2
I fought with this same linker file with a different version of the gcc linker and it took me a couple of days to get the syntax just right. There are other problems, where the MPU is set up to turn off caching of these two sections, but also the top top of the stack, and other issues. They've been reported to ST but haven't made it into the examples yet.
2022-07-19 11:37 AM
In addition to what @Andrei Chichak said...
In that example the size of RAM memory must not exceed 0x7C000 B, which is 496 KB, not a 499 KB.
Note the difference of TxDecripSection vs TxDescripSection. Long time ago someone, who probably didn't understand what a DMA descriptor is, but had heard something about decryption, wrote it like that and so it goes on for years. And generally there is no need for Rx and Tx descriptors to be split in a separate sections at all.
Also merging DTCM with SRAM is absurd, because then the developer cannot even control in which memory the variables are placed! Split them normally and place the stacks and some intensively used variables in DTCM.
@Imen DAHMEN, just another insanity created by the incompetent "developers"...
2022-07-19 01:14 PM
It would be really nice if the rewritten example used STM32CubeIDE and .ioc files as well.
2022-07-20 08:39 AM
An earlier report for the same by Andrei...
2022-11-28 07:27 AM
Hello,
Common answer with https://community.st.com/s/question/0D53W00000VjTwcSAF :
There's confirmed issues related to LwIP_HTTP_Server_Netconn_RTOS application on STM32F7.
And here's the delta between F7 version 1.17.0 and the correction to be made on STM32F767ZITx_FLASH.ld :
.TxDescripSection (NOLOAD) : { *(.DMATxDscrTab_section) } >Memory_B2
will be replaced by :
.TxDecripSection (NOLOAD) : { *(.TxDescripSection) } >Memory_B2
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 497K
497K = 128K(DTCM) + 368K(SRAM1) + 1K(For Descriptors Section starting from 0x2007C000)
Sorry for the late answer and thank you again for your cooperation.
Regards
Mahdy
2022-11-28 03:44 PM
Since the SRAM2 region is only 16K long, it's pretty silly to just use the bottom 1K for the descriptors, but have the receive buffer in DTCM or SRAM1. If you were to relocate memp_memory_RX_POOL_base to 0x2007C000 + 512 bytes, reduce the size of the RX POOL to 8 buffers as specified in note 2.a., increase the size of the MPU section to cover the descriptors by making it 512 bytes, move the start of the stack to 0x2007C000, and get rid of the unexplained MPU section that covers 4GB starting at 0x0, you'll be closer.
BTW, if you start a new project for F7, select ETH and LwIP, you'll get the Decrip sections, continuing the spelling mistake again.