2019-09-28 04:10 PM - edited 2023-11-26 11:14 AM
This is an umbrella topic where I will collect the key problems and solutions to finally get networking on STM32 working. The issues formatted as bold are the most critical ones.
HAL ETH drivers have been significantly reworked since the following firmware packages: CubeF4 v1.27.0, CubeF7 v1.17.0, CubeH5 v1.0.0, CubeH7 v1.10.0
Series: F1, F2, F4, F7, H5, H7 (all STM32 with Ethernet)
Series: F1, F2, F4, F7 (older Synopsys basic peripheral)
Series: H5, H7 (newer Synopsys QoS peripheral)
Series: F7, H7 (Cortex-M7 CPU)
lwIP API related:
Other related information:
Another detailed topic by @alister: "[bug fixes] STM32H7 Ethernet". While mostly dedicated to H7 series, it also has a good amount of information relevant to all Ethernet/lwIP related development.
Open source zero-copy Ethernet/lwIP driver example. The hardware driver is for F2 series, which means that it's almost the same for all Fx series. The lwIP related code and general ideas are still valid for all series.
My other closely related topic: "Actually working STM32 Ethernet and lwIP demonstration firmware". As that topic is currently unavailable, because ST still has not moved it to the new forum, I am attaching a PDF copy of that topic and the related firmware files to this topic.
Solved! Go to Solution.
2023-05-07 11:32 PM
Thank you Piranha,
I appreciate your response. I got the link now.
Just a small feedback about the link provided in main topic No DMA access to a data in FLASH memory, it talks about DMA access to flash memory, which is an ultimate root cause of the issue. Its definitely helpful for those who know the root cause of the issue (like due to DMA access to flash memory). But people like me normally search for specific issues like HTTP is not working, deadlock, dma error etc.. for a quick solution. I was instead focusing more on "lwIP driver Tx deadlock" which is also a related issue.
Anyway, you have given lot of comments and remarks on various issues related to ethernetif.c driver for STM32F4. that's why I thought to comment here. Thank you again for help. Waiting for proper solution from STM32 in June.
Regrads,
Parvez Akhtar
2023-07-28 01:06 AM
Hello @Piranha ,
Ethernet not working with cube Mx 6.8.1 but same configuration of cube Mx working with 5.4 version. for STM32F746 board firmware used STM32Cube FW_F7 V1.17.0
help me out to fine any solution on this.
thanks
regards Lavanya.
2023-08-22 10:18 AM
I'm trying to make it work with RTEMS and the new STM32H7 HALs (v1.11.1). I've set up a project based upon the sample present on the GitHub page, for the Nucleo-H743ZI.
My lwipops.h options are the ones suggested from ST (I've tried also with a bigger MEM_SIZE):
#define MEM_SIZE (14 * 1024)
/* Relocate the LwIP RAM heap pointer. Place in SRAM3 */
#define LWIP_RAM_HEAP_POINTER (0x30004000)
/* ---------- Pbuf options ---------- */
/* PBUF_POOL_SIZE: the number of buffers in the pbuf pool.
@ note: used to allocate Tx pbufs only */
#define PBUF_POOL_SIZE 8
/* PBUF_POOL_BUFSIZE: the size of each pbuf in the pbuf pool. */
#define PBUF_POOL_BUFSIZE 1536
/* LWIP_SUPPORT_CUSTOM_PBUF == 1: to pass directly MAC Rx buffers to the stack
no copy is needed */
#define LWIP_SUPPORT_CUSTOM_PBUF 1
The variables are also where needed in memory:
ETH_DMADescTypeDef DMARxDscrTab[ETH_RX_DESC_CNT] __attribute__((section(".RxDecripSection"))); /* Ethernet Rx DMA Descriptors */
ETH_DMADescTypeDef DMATxDscrTab[ETH_TX_DESC_CNT] __attribute__((section(".TxDecripSection"))); /* Ethernet Tx DMA Descriptors */
LWIP_MEMPOOL_DECLARE(RX_POOL, ETH_RX_BUFFER_CNT, sizeof(RxBuff_t), "Zero-copy RX PBUF pool");
__attribute__((section(".RxArraySection"))) extern u8_t memp_memory_RX_POOL_base[];
.lwip_sec (NOLOAD) : {
. = ABSOLUTE(0x30040000);
*(.RxDecripSection)
. = ABSOLUTE(0x30040200);
*(.TxDecripSection)
. = ABSOLUTE(0x30040400);
*(.RxArraySection)
} >SRAM_3
/* Modification end */
/DISCARD/ :
{
libc.a ( * )
libm.a ( * )
libgcc.a ( * )
}
The problem is that the program goes into an exception inside the mem_alloc function. The following is a backtrace taken from GDB:
#0 0x08000ff4 in mem_malloc ()
#1 0x08002ab4 in pbuf_alloc ()
#2 0x08009b8e in etharp_raw ()
#3 0x08009c84 in etharp_request_dst ()
#4 0x08009ca8 in etharp_request ()
#5 0x0800625a in netif_issue_reports ()
#6 0x080062e8 in netif_set_link_up ()
#7 0x0800f148 in low_level_init ()
#8 0x0800ef4e in ethernetif_init ()
#9 0x08005e3a in netif_add ()
_ARM_Exception_default (frame=0x2400b958 <_ISR_Stack_area_begin+3992>)
Can anyone help me understand what's wrong with this?
2023-09-21 12:06 AM
In STM32F7 (Cortex-M7) my solution is:
And that's all, the lwip working reliable, and finally replying the ICMP (ping, echo) packets succesfully.
(In my case is: Nucleo-F756ZG, MCU: STM32F756ZGT6)
Any other config not needed, I mean enable the MPU, enable ICache, DCache, modify the ethernetif.c or lwip library files. So my conclusion is, I think the lwip middlewares not compatible yet the CMSIS v2 FREERTOS.
2023-09-27 09:57 PM
Thank You @Blinti For Your Replay,
Can I know Which version of cube Mx you are using, For me Cube Mx 5.4 version ethernet stack is working but same configuration I tried for cube Mx version 6.8 it's not Working.
2024-05-13 11:35 PM
can u send your ioc file
2024-08-08 03:45 AM
I think new users do not have time and expertise to read all these to use a ethernet port.
it is better to classify it by use cases and related issues seen by customers/users.
for example in your list of topic:
if you face XXX problem, read topic 1,2,3 and 4
if you dont want RTOS, read 5,6,7
if your ping lost, check out 8,9,10
2024-10-03 08:05 AM - edited 2024-10-18 07:28 AM
Dear community members,
Thank you for your continuous support and feedback to identify potential issues related to Ethernet. The input provided in this conversation thread has helped us to improve the solution from HAL drivers examples and documentation perspectives.
As many of the mentioned issues have been fixed, we wanted to give you a status update (see below). We are aware that some issues persist, and we will continue the analysis to provide solutions. In the meantime, if you have further feedback, please let us know, and don’t hesitate to start a thread if you encounter an issue that has not yet been mentioned here.
Thanks,
Post |
Status |
Implemented in the new HAL_ETH_Driver. Refer to the thread Ethernet HAL Driver reworked by ST and available in 22Q1 (preview now available on GitHub) for more details about some of the applied fixes. (1) |
|
RMII mode not enabled because of lacking SYSCFG synchronization. |
|
Many flaws as a result from *** porting of the reworked H7 series HAL ETH driver. |
|
Unnecessary delay in LAN8742_Init() and link state management in low_level_init(). |
Questions answered |
Unnecessary delays and peripheral reset in HAL_ETH_Init() function. |
|
Fixed in STM32CubeMX-6.9.0 |
|
FIXED IN STM32CubeF7 v1.17.2 |
|
Fixed mismatch in linker section names between linker file and source file. |
|
resolved in the STM32CubeH7 V1.10 |
|
Main reported issues fixed- Some enhancements are required |
|
Poorly chosen MDC (MDIO) frequency limits and scarce documentation. |
Documentation internally updated. 133712 (used for internal reference only) |
Move bufffers of fsdata_custom.c file from Flash to RAM. In v1.28 of Stm32cubeF4 |
|
Documentation internally updated. 140321 (used for internal reference only) |
|
Documentation internally updated. 141623 (used for internal reference only) |
|
Documentation internally updated. 118901 (used for internal reference only) |
|
Documentation internally updated. 121000 (used for internal reference only) |
|
Flawed MPU configuration and D-cache maintenance in lwIP driver. |
Fixes applied on Lwip projects in STM32CubeH7 v1.11.2 |
Investigation ongoing. We will update you case by case in this post. |
|
ETH_DMACSR_RBU error occurs and stalls the Ethernet receive on STM32H7. |
|
(1) the reworked Ethernet driver is available for:
STM32CubeF1 and STM32CubeF2 don’t get a reworked Ethernet driver.
These updates are available From CubeMX version 6.4.0 and higher and we recommend using the latest tools and software versions to make sure latest fixes and patches are applied.
To enhance our support related to Ethernet topics, feel free to review the following material that hopefully help you in some use-cases:
For issues related to documentation that were identified but not yet solved, feel free to keep an eye on the following knowledgebase articles: