2
\$\begingroup\$

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.

\$\endgroup\$
4
  • \$\begingroup\$ Check the RAM location of your Ethernet stack buffers. Depending on which STM32 you're using, it might have particular "CCM" RAM blocks which are not accessible by DMA or other peripheral modules like Ethernet. I've found that some compilers like to use these blocks as their default location for variables because the core can access them faster than other blocks, but putting stuff which needs to be accessed by DMA or peripherals in the CCM block(s) simply doesn't work and usually gives you an unhelpful DMA error flag. \$\endgroup\$
    – brhans
    Commented Mar 17, 2022 at 13:42
  • \$\begingroup\$ Hello brhans, thanks for you answer. there is an __ALIGN (32) on transmit buffer: ethernetif.c 'typedef struct { struct pbuf_custom pbuf_custom; uint8_t buff[(ETH_RX_BUFFER_SIZE + 31) & ~31] __ALIGNED(32); } RxBuff_t;' but I dont see the same thing on the transmit buffer. \$\endgroup\$
    – Damien LUCAS
    Commented Mar 18, 2022 at 17:32
  • 1
    \$\begingroup\$ Alignment is important, but there's more to it than that. You need to find the actual addresses of the buffers and then look in the reference manual for your STM32 to see if those addresses lie in memory which the Ethernet module can access. \$\endgroup\$
    – brhans
    Commented Mar 18, 2022 at 18:34
  • \$\begingroup\$ Hello, 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 { CCMRAM (xrw) : ORIGIN = 0x10000000, LENGTH = 64K RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 192K FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 2048K } with I shortened RAM of 16 KB and added RAM2 where TXBUFFER 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. \$\endgroup\$
    – Damien LUCAS
    Commented Mar 29, 2022 at 15:05

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.