Skip to main content
brianshankland9
brianshankland9
Associate III
August 28, 2017
Question

STM32F746G CubeF7 LwIP demo

  • August 28, 2017
  • 3 replies
  • 929 views
Posted on August 28, 2017 at 17:03

Hello,

I've been trying out the examples from the STM32 CubeF7 projects for the STM32F746G Discovery board, but when I build the LwIP application using the SW4STM32 tools the image is over 393MB and so too large for the target.

If build using Keil uVision the file size is tiny in comparison.

I'm able to build and deploy other apps such as the FatFS so confused as to why this should be?

    This topic has been closed for replies.

    3 replies

    brianshankland9
    brianshankland9Author
    Associate III
    August 29, 2017
    Posted on August 29, 2017 at 11:19

    I've done some more digging into this my examining the elf file that is also produced (attached).

    Headers 4 to 6 are using the SRAM as a Physical location instead of a virtual one, therefore the bin file produced has to include the entire range from 0x08000000 (Start of FLASH) to 0x20000000 (start of memory) which explains the 393 MB bin file size as the file is mostly empty.

    I think this will be initial variable settings, but headers 1 and 2 have similar but are correctly mapped from a virtual location in the FLASH to the physiical location in SRAM for initialisation.

    Can anyone point me to whythese sections would be treated differently or where I should be looking next in my investigation?

    ________________

    Attachments :

    STM32746G_DISCOVERY.elf.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyTN&d=%2Fa%2F0X0000000b8G%2FX5RSjF8OTHKV62CB3_Sm7hIceqoDyTxnJfnQuk_unmI&asPdf=false
    brianshankland9
    brianshankland9Author
    Associate III
    August 29, 2017
    Posted on August 29, 2017 at 11:26

    I see in the release notes that  V1.2.0 has a change for this demo:

    • Use ETH buffers in SRAM instead of DTCM RAM for LwIP applications

    and I see it is these buffers that are being 'incorrectly' mapped in the linkkerscript,ld file

    Memory_B1(xrw) : ORIGIN = 0x20010000, LENGTH = 0x80

    Memory_B2(xrw) : ORIGIN = 0x20010080, LENGTH = 0x80

    Memory_B3(xrw) : ORIGIN = 0x2004C000, LENGTH = 0x17d0

    Memory_B4(xrw) : ORIGIN = 0x2004D7D0, LENGTH = 0x17d0
    brianshankland9
    brianshankland9Author
    Associate III
    August 29, 2017
    Posted on August 29, 2017 at 11:44

    Solved it!

    The NoLoad directives were missing at the end of the linkerscript file, they should read as follows:

    .RxDecripSection (NOLOAD) : { *(.RxDescripSection) } >Memory_B1

    .TxDescripSection (NOLOAD) : { *(.TxDescripSection) } >Memory_B2

    .RxarraySection (NOLOAD) : { *(.RxBUF) } >Memory_B3

    .TxarraySection (NOLOAD) : { *(.TxBUF) } >Memory_B4 ♯

    BIN file is now created with the correct size and can be downloaded and run.

    Terms & ConditionsAccessibility statement