STM32F746 discovery Ethernet don't work if the LwIP MEM_SIZE value is increased.

[Asantos]

Posted on December 06, 2016 at 15:37

Hi,

I used the CubeMX 4.18 to do a simple LwIP UDP server project for the STM32F746-Discovery board. It works well for the default configuration. But If the LwIP MEM_SIZE is increased for 64K bytes or more, or if a buffer with 64K bytes or more is created. The Ethernet don't work anymore, neither for reception or for transmittion. 

Anyone have any idea about the cause of this issue?

Ari.

[Imen.D]

Posted on December 06, 2016 at 17:47

Dear

Mendes.Ari

,

You should check your configuration parameters andsize of Ethernet packet.

I suggest that you take a look to the following resources which can help you to go further in your

LwIP

application: -

http://www.st.com/content/ccc/resource/technical/document/application_note/fd/5d/64/cf/7c/38/4c/30/DM00036pdf/files/DM00036pdf/jcr:content/translations/en.DM00036pdf

: “LwIP TCP/IP stack demonstration for STM32F4x7 microcontrollers�?, -

http://www.st.com/content/ccc/resource/technical/document/user_manual/65/e8/20/db/16/36/45/f7/DM001036pdf/files/DM001036pdf/jcr:content/translations/en.DM001036pdf

: “Developing applications on STM32Cube with LwIP TCP/IP stack�?

Hope this helps you.

Best Regards

-Imen-

If the response is useful, please mark it as helpful or correct.

Thank you for the contribution

[aaron239955_stm1_st]

Posted on December 06, 2016 at 20:59

I haven't looked at the LWIP implementation on this board, but I would guess that LWIP is allocating its memory from the on-chip SRAM.  If this is the case, 64k is a big chunk on the SRAM and you may not be able to fit it with other needs of the system.

If you can relocate the LWIP memory into the off-chip DRAM, it is slower but you have 8Mbytes to play with so you should be able to find some space for 64k-512k without a problem. 

Of course you'll have to initialize the DRAM before you use it.

[Asantos]

Posted on December 06, 2016 at 22:52

The cubemx generate a file ethernetif.c with the ethernet descriptors as

below:

/* Private variables

[aaron239955_stm1_st]

Posted on December 06, 2016 at 23:02

I don't see any information in this post.  Can you attach a file using the 'Use advanced editor' link at the top right of the editor window?

[Asantos]

Posted on December 07, 2016 at 00:49

The cubemx generate a file ethernetif.c with the ethernet descriptors as below:

/* Private variables ---------------------------------------------------------*/
#if defined ( __ICCARM__ ) /*!< IAR Compiler */
 #pragma data_alignment=4 
#endif
__ALIGN_BEGIN ETH_DMADescTypeDef DMARxDscrTab[ETH_RXBUFNB] __ALIGN_END;/* Ethernet Rx MA Descriptor */
#if defined ( __ICCARM__ ) /*!< IAR Compiler */
 #pragma data_alignment=4 
#endif
__ALIGN_BEGIN ETH_DMADescTypeDef DMATxDscrTab[ETH_TXBUFNB] __ALIGN_END;/* Ethernet Tx DMA Descriptor */
#if defined ( __ICCARM__ ) /*!< IAR Compiler */
 #pragma data_alignment=4 
#endif
__ALIGN_BEGIN uint8_t Rx_Buff[ETH_RXBUFNB][ETH_RX_BUF_SIZE] __ALIGN_END; /* Ethernet Receive Buffer */
#if defined ( __ICCARM__ ) /*!< IAR Compiler */
 #pragma data_alignment=4 
#endif
__ALIGN_BEGIN uint8_t Tx_Buff[ETH_TXBUFNB][ETH_TX_BUF_SIZE] __ALIGN_END; /* Ethernet Transmit Buffer */�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

The ethernetif.c file on the cubef7 examples initialize the ethernet descriptors as below:

#if defined ( __ICCARM__ ) /*!< IAR Compiler */
#pragma location=0x2000E000
__no_init ETH_DMADescTypeDef DMARxDscrTab[ETH_RXBUFNB];/* Ethernet Rx MA Descriptor */
#pragma location=0x2000E100
__no_init ETH_DMADescTypeDef DMATxDscrTab[ETH_TXBUFNB];/* Ethernet Tx DMA Descriptor */
#elif defined ( __CC_ARM )
ETH_DMADescTypeDef DMARxDscrTab[ETH_RXBUFNB] __attribute__((at(0x2000E000)));/* Ethernet Rx MA Descriptor */
ETH_DMADescTypeDef DMATxDscrTab[ETH_TXBUFNB] __attribute__((at(0x2000E100)));/* Ethernet Tx DMA Descriptor */
#elif defined ( __GNUC__ )
ETH_DMADescTypeDef DMARxDscrTab[ETH_RXBUFNB] __attribute__((section('.RxDescripSection')));/* Ethernet Rx MA Descriptor */
ETH_DMADescTypeDef DMATxDscrTab[ETH_TXBUFNB] __attribute__((section('.TxDescripSection')));/* Ethernet Tx DMA Descriptor */
#endif
#if defined ( __ICCARM__ ) /*!< IAR Compiler */
#pragma location=0x2000E200
__no_init uint8_t Rx_Buff[ETH_RXBUFNB][ETH_RX_BUF_SIZE]; /* Ethernet Receive Buffer */
#pragma location=0x2000FFC4
__no_init uint8_t Tx_Buff[ETH_TXBUFNB][ETH_TX_BUF_SIZE]; /* Ethernet Transmit Buffer */
#elif defined ( __CC_ARM )
uint8_t Rx_Buff[ETH_RXBUFNB][ETH_RX_BUF_SIZE] __attribute__((at(0x2000E200))); /* Ethernet Receive Buffer */
uint8_t Tx_Buff[ETH_TXBUFNB][ETH_TX_BUF_SIZE] __attribute__((at(0x2000FFC4))); /* Ethernet Transmit Buffer */
#elif defined ( __GNUC__ )
uint8_t Rx_Buff[ETH_RXBUFNB][ETH_RX_BUF_SIZE] __attribute__((section('.RxBUF')));/* Ethernet Receive Buffer */
uint8_t Tx_Buff[ETH_TXBUFNB][ETH_TX_BUF_SIZE] __attribute__((section('.TxBUF')));/* Ethernet Transmit Buffer */
#endif�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

When I change the cubemx descriptors initializing method to the cubef7 examples. Increasing the SRAM allocation don't disable ethernet any more.

I would like to konw why?

ST should release more ethernet examples for the STM32F746 discovery and for the NUCLEO-F7 boards, and projects made using the STM32cubeMx.

Ari.

[aaron239955_stm1_st]

Posted on December 07, 2016 at 01:35

Hi Ari,

Looking at the files you listed above, it is pretty clear that the buffers are in the on-chip SRAM since the addresses are in the 0x2xxx xxxx range.  It looks like the main difference between the CubeMX generated code and the example code is the fact that the example code has many explicit addresses assigned within the declarations, while the CubeMX code just defines blocks that will be allocated as contiguous chunks by the compiler and linker.  It is possible that the reason that it still works with the 'example' code is that your changing the size of the buffers is actually being ignored since the declarations have absolute addresses embedded in them.  Not sure what parameters you are playing with to make the buffers bigger but if the parameters are not recognized by the example code, thebuffer sizes will just stay what they are in the example.  Of course, being defined explicitly may or may not cause a problem if other RAM features, like stack and heap, grow and the linker is not set up to resolve conflicts.  My guess is that CubeMX does it the way it does, is so that the linker is aware of everything that is requesting use of the available SRAM and can check if there is enough to satisfy all requirements.

You might want to look at the memory map log files that the EWARM linker generates to see where all of your buffers are getting located in memory and what the sizes are.