[bug fixes] STM32H7 Ethernet

[alister]

@Amel NASRI​, @ranran​, @Piranha​, @Harrold​, @Pavel A.​ 

V2 of my fixes and improvements to H7_FW V1.5.0/V1.6.0 Ethernet...

Changes include

• Decoupling receive buffers from receive descriptors so buffers may be held any length time without choking receive.
• Optionally queuing transmit, so transmit doesn't need to block until complete.
• Many bug fixes.

Find full details and source in the attached zip. V1 was posted to another developer's question. Please post any questions about V2 here.

[AAnt.1]

Hi @alister​ 

I have stm32H7 Nucleo board and i want to send data from ADC to PC via Ethernet, because It is faster that transmision via Rs232.

For getting data from rs232 i use terminal program (Realterm) that give me occunity to save data to file and i could comunicate with MCU from PC.

What program you use for getting data from MCU via Ethernet UDP ?

Best regards.

[alister]

Analogous to a serial terminal. Use python to develop a client, fix the device's port number, fix the client's IP or multicast, and have the device send UDP and not care if a client is listening or not.

Please open a different thread as the question is broad and has nothing to do with this driver.

[AAnt.1]

Could you give me code for stm32h7, i will try to send packets from MCU to PC via UDP ?

I work with keil and project for keil will be better for me.

Best regards.

[SLuka.1]

Hello, I have successfully activated HAL modifications from the head post. LWIP works not bad, but I've met with the strange behaviour with STM32h745. My data exchange freertos thread works through netconn (TCP server) in "pseudo non blocking" mode. Netcon_read activates only after msg in callback RCV_PLUS. Data output is going through netcon_write with blocking.

So, strange situation occurs only on high data rates. I've no errors returning in netcon_read or netcon_write. I've phyton app which sequentially writes incremental data to variable (register), the next request - is reading this data, if two of them are equal - next increment, and so on. Packets are with small payload, about 11 bytes. After some hundreds iteration i see, that netcon_write exits with OK, but, there is no data on wire (wireshark). This data appears only after I receive something from PC side. For example test application waits for answer for 1s., identifies no_answer, and generates next register write request, cpu receives this data and makes that "untransmitted" transmission... So transmission can hang until packet is received moreover it should be addressed to current netcon.

Maybe any Ideas? Thank You!

[Pavel A.]

It is unclear is this LwIP or the ETH driver problem.

As you're using FreeRTOS, try to use also their TCP library with their ETH driver rework:

https://github.com/FreeRTOS/FreeRTOS-Plus-TCP/tree/main/portable/NetworkInterface/STM32Hxx

[alister]

Don't know about lwIP "pseudo non blocking" mode or callback RCV_PLUS and Google doesn't throw anything on those.

Per the wireshark capture, there are no "about" 11-byte payloads, you'll have to say where the incrementing data is, guessing your H7 is IP 172.16.227.29. Packets 2, 4, 5, 6 have same or close times, as do packets 79, 80, 81 and 83, 84, ... so those are a clue. The transmits are bursting, Perhaps your tx thread is not getting time.

Not sure why tcp_write would return ERR_OK and not send.

Suggest instrument your buffers and observe their levels as the traffic rate increases, and increase instrumenting until you isolate the problem.

[KB.2]

I would like to start communication between the server and the embedded system.

I am using Hercules as the server and STM32F746Disco as the client.

But my transmission is not working and I don't know why. In the attachment I am sending the program and the report from Wireshark.

I will just add that when I use STM32F746Disco as a server and Hercules as a client, communication works.

Can anyone have a similar problem and can share the solution?

Thank you!

[Piranha]

This code, which comes from there, breaks just about all the possible rules there are:

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
	char buf[100];
 
	/* Prepare the first message to send to the server */
	int len = sprintf (buf, "Sending TCPclient Message %d\n", counter);
 
	if (counter !=0)
	{
		/* allocate pbuf */
		esTx->p = pbuf_alloc(PBUF_TRANSPORT, len , PBUF_POOL);
 
 
		/* copy data to pbuf */
		pbuf_take(esTx->p, (char*)buf, len);
 
		tcp_client_send(pcbTx, esTx);
 
		pbuf_free(esTx->p);
	}
 
}

Absolutely ALL of those function calls are forbidden to make from an ISR! The pbuf_free() can be made callable from ISRs, but that's not the default configuration. And sprintf() depends on a platform implementation, but sanely designed software doesn't call printf functions from ISRs anyway. That ControllersTech.com site is just a ridiculously low quality junk from India. The guy just don't understand what he is doing at all. He is even less competent that the already tragic ST's HAL team...

And not only you have to fix the application, but also the broken ST's implementation of Ethernet and lwIP:

https://community.st.com/s/question/0D50X0000BOtfhnSQB/how-to-make-ethernet-and-lwip-working-on-stm32

[KB.2]

Thank you Sir for information.

[Amel NASRI]

Dear All,

Our Experts tried to answer almost all the limitations reported in this thread.

Please refer to this post for more details.

At this point, I suggest to close this discussion as it becomes difficult for us to follow it with the great number of comments.

Don't hesitate to submit your new posts asking new questions.

Thanks for all the ones involved to make ST solutions more efficient.

-Amel