cancel
Showing results for 
Search instead for 
Did you mean: 

I would like to use the TCP/IP protocol (with LwIP, HAL library, without freeRTOS) in a project but I face some portability issues.

DLUCA.1
Associate II

Hello,

I would like to use the TCP/IP protocol (with LwIP, HAL library, without freeRTOS) in a project but I face some portability issues.

I'm starting with TCP echo client example as in chapter 6.1.1 of UM1713 document.

I used the 1.26.2 version of STM32 HAL firmware and was able to transmit data to my server. I could test transmission of data, ping and DHCP work fine. Hardware is a Nucleo-F429ZI.

But now with the 1.27.0 version it no longer works. No ping, no DHCP, no data transmission.

I did a lot of tests and readings on this forum but nothing seems to be working as expected.

I found that no packet could be sent.

For example, In debug mode I put a breakpoint in HAL_ETH_Transmit just after WRITE_REG function. With a fixed address (no DHCP), I try to ping the board from my PC. The breakpoint is reached as soon as the ping is sent, so, packet seem to be received, driver builds response as expected, but there is a DMA error or timeout, and packet is never sent.

The DMA status register shows that there is a FBES error (bit 13 and bit 23 & 24 are set)

DMA status register as also bits 17 & 18 set : Receive process state FSM seems to work normally.

I'm really close to the default CubeMx configuration.

I'm missing something in this configuration but I don't know what.

Has anyone faced this issue?

Or have any idea where I should look?

Pending an answer, I'm changing the firmware to 1.26.2 but this is not a durable solution as I would like to keep the project up to date.

4 REPLIES 4
Pavel A.
Evangelist III

This is likely because in 1.27.2 the ETH driver has undergone major changes (aka "reworked"); this change requires also change in the user code.

The previous ETH driver version is STM32F4xx_HAL_Driver/Src/Legacy/

Try to build with that. If it works, consider updating your code to the new driver.

DLUCA.1
Associate II

Hello Pavel,

I'm trying to get legacy but in only have header files which are legacy. Do you have an advice to get the legacy Firmware in cubeIDE.

By the way It look like I have a CCM problem: I have an existing address for the data to be sent but for transmission the address is not at the same place in the code morevover when I found code about the CCM transmition ethernet it refers to pointers that I can not follow in the files so I don"t see where they are initialised.

Piranha
Chief II

> I'm trying to get legacy but in only have header files which are legacy.

Pavel gave you an almost direct link to code files. How can it NOT be seen?

https://github.com/STMicroelectronics/STM32CubeF4/blob/3d6be4bd406f275728e0a321cc371c62a3100533/Drivers/STM32F4xx_HAL_Driver/Src/Legacy/stm32f4xx_hal_eth.c

DLUCA.1
Associate II

Hello Piranha,

Hello Pavel,

My problem standed in the fact that my "tx buffer" were placed in a non existing area of memory.

In the MX configuration the memory point: LWIP_RAM_HEAP_POINTER (RAM Heap Pointer) was badly set. I split memory

there: STM32F429ZITX_FLASH.ld and STM32F429ZITX_RAM.ld

MEMORY

{

 CCMRAM  (xrw)  : ORIGIN = 0x10000000,  LENGTH = 64K

 RAM  (xrw)  : ORIGIN = 0x20000000,  LENGTH = 192K-XK

RAM2  (xrw)  : ORIGIN = 0x2XXXXXX,  LENGTH = XK

 FLASH  (rx)  : ORIGIN = 0x8000000,  LENGTH = 2048K

} with I shortened RAM of 16 KB and added RAM2 where "buffer" is.

Then in lwiopts.h

#define LWIP_RAM_HEAP_POINTER 0x30044000

is set to the RAM2 address.

I have some test to perform before confirming.

about Legacy as it looked like a computer path I used the one on my computer not the one on github. that explains why I didn't see the same think as Pavel.

The main problem on cubeMX perspective is that LWIP middleware is set by default for H7 microcontroller but on F4 the memory is shorter so that it doesn't work by default.

Best regards,