STM32H753 Ethernet using FreeRTOS and lwIP - continued...

[Archie]

Greetings,

trying to get a setup with stm32h753 running FreeRTOS and LwIP. One attempt in this journey was to take the example: How to create project for STM32H7 with Ethernet an... - STMicroelectronics Community

Using the example code, I see one issue with the core lock - if the breakpoint in ethernetif.c line 987 is enabled I see the code suspends in places one would not expect it to suspend such as:

If I disable the breakpoint, ping works ok.

However even with this example the code quite often (if not always) gets stuck to Ethernet output, it seems that a packet comes down to ethernet low_level_output function, but never gets out to the cable. Suspecting it is a DMA issue, but had no luck locating the issue yet. Any ideas?

Thanks!

[Pavel A.]

When the BKPT hits, what is the thread id?

> Suspecting it is a DMA issue

Is DCACHE enabled? Are you using a concrete example project from the CubeH7 package or the "hotspot" repo, or rolling your own by following the how-to article?

[Archie]

Greetings,

for the thread ID, see below.

The code is based on a copy from the "hotspot" repo(version 1.2). But on top of that is the httpd server from CubeMX amongst others.

DCACHE is enabled.

[Pavel A.]

> for the thread ID, see below

Hmm, the call stack shows that netif_set_link_down()  expects to be called under the LwIP "core lock". ... I'm not sure whether this function actually requires the lock, but lets assume it does. So acquire the lock in your low_level_init() and other places around calls to netif_set_link_down, netif_set_link_up.

>DCACHE is enabled.

Don't enable DCACHE for debugging. This won't completely remove the cache related issues but should make debugging easier on bring-up stage.

[Archie]

Greetings,

thank you for the hints! In the meantime I have found out that, if the http headers for the http server are static then the files with static headers go through the stack and thus are received correctly. However for files that use dynamic http headers never leave the device. The code and the file set work on STM32F4, but something is different in H7. The file content and headers for the problematic files look ok when they are in tcp_write in tcp_out.c, but figuring out what happens next to them seems a bit tricky. Again all ideas are more than welcome!

[Pavel A.]

>However for files that use dynamic http headers never leave the device

Does this mean, the data is in internal SRAM? Note that the ETH DMA cannot access certain memory areas (see the bus matrix picture in the Ref.Manual). Data located in these memory areas must be copied to accessible memory for transmit. The examples don't show this explicitly. IIRC the TCP examples do not struggle to achieve "zero copy", all TX data is copied to intermediate buffers, so it works, as long as the LwIP pool is allocated in accessible RAM.

[Archie]

Greetings,

thank you for the quick reply!

Yes, for the dynamic files the data is in internal SRAM. LwIP heap is currently allocated to SRAM2 (RAM_D2), in lwipopts.h:#define LWIP_RAM_HEAP_POINTER 0x30020000. It looks like the dynamic http file contents are allocated from this memory.

The other memory allocations in the linker script are in SRAM3:

.lwip_sec (NOLOAD) : {
. = ABSOLUTE(0x30040000);
*(.RxDecripSection)

. = ABSOLUTE(0x30040060);
*(.TxDecripSection)

. = ABSOLUTE(0x30040200);
*(.Rx_PoolSection)
} >RAM_D2 AT> FLASH

However the http header is a mix-and-match of data in RAM and constant strings from Flash.

I'll double check these first thing on Monday.

[Piranha]

https://community.st.com/t5/stm32-mcus-embedded-software/how-to-make-ethernet-and-lwip-working-on-stm32/m-p/261456

[Archie]

Greetings,

the issue seems to be in the way the dynamic headers are allocated / transferred for DMA. For now I disabled dynamic header generation and generate the needed headers along with the custom file creation. Having said that it may well be that I need to dig into the advice Piranha linked below as it seems that on F4 the Ethernet traffic goes way smoother than it does on H7.

Thank you for the help so far!

[Piranha]

The core lock test fails because some code does not respect the lwIP multi-threading requirements. The "Hello UDP" example form the "hotspot" even demonstrates how to write a broken code. And the lwIP driver has a deadlock in Tx code. All of it is reported in the link I gave previously. There is no point in poking random features and doing other voodoo magic before the lower layers of code are fixed.