STM32-F429: Ethernet driver possibly wasting RAM

[Arjun765]

Description

When i ran nm on my elf, i saw 2 variables Rx_buff and Tx_buff (from stm32xx_emac.cpp) which was using up 6096 bytes each, even though I'm not using ethernet at all. I could not find any way to disable them, best i could do is override stm32-emac.eth-txbufnb parameter from 4 to 1 bringing down memory to 1524 bytes.

Issue request type

[ ] Question
[x] Enhancement
[ ] Bug

[0xc0170]

@Arjun765 Can you share more? Is this in the final binary?

Looking at emac implementation, the buffers are on stack or I've missed something?

cc @ARMmbed/team-st-mcd Please review

[Arjun765]

Can you share more? Is this in the final binary?

Yes, its the final ELF file.

Looking at emac implementation, the buffers are on stack or I've missed something?

These are not (stm32xx_emac.cpp line 56 and 61)
__ALIGN_BEGIN uint8_t Tx_Buff[ETH_TXBUFNB][ETH_TX_BUF_SIZE] __ALIGN_END;
__ALIGN_BEGIN uint8_t Rx_Buff[ETH_RXBUFNB][ETH_RX_BUF_SIZE] __ALIGN_END;

[0xc0170]

Whats your toolchain (assuming gcc arm) and the compile command - mainly what profile you use?

[LMESTM]

NUCLEO_F429ZI has
"network-default-interface-type": "ETHERNET"
Maybe overriding this value from mbed_app.json could disable the Ethernet ?
"target.network-default-interface-type": null

[Arjun765]

I can reproduce this on a new empty project with mbed-os-5.13.4, GCC 8-2019-q3-update compiled with mbed compile --target NUCLEO_F429ZI --toolchain GCC_ARM --clean

[0xc0170]

Can you try --profile release as well?

[Arjun765]

Can you try --profile release as well?

Nope, still there. I don't think it will be removed without flto.

[0xc0170]

flto - that one is still due to be added. As I remember, we need to first update to GCC 8 , it should happen the following releases as we had some build issues prior the current one.

[0xc0170]

A workaround would be : "#11506 (comment)" - does that work for you?

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-1775

[kjbracey]

Personally, I don't see any reason those buffer arrays should be retained. A plain C-style array should vanish during linking if no-one uses it. Lots of the codebase relies on that.

Not sure what's happening here.

Maybe try literally deleting the definitions, leaving just extern uint8_t RxBuff[]; declarations. With GNU ld, if it thinks someone is referencing it, it will fail to link and tell you who.

(With GNU, it will only complain about a missing definition if the person referring to it is used itself - ie it's ultimately needed by "main". With ARM, it would actually always complain, so that wouldn't be a useful test.)