[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.

[ABlum.2]

Hi alister,

Thanks for the answer, The main.c is the standard main.c generated by STCube, nothing else, I call the MX_LWIP_Init() (and this function call everything else) in a threat right before the infinitive while in main.

Regards

Alan

[ABlum.2]

I already solved this issue, I just configure the system to make it work on timer 7 and 6 so RTOS can work with Systick. Thanks for the help.

Regards

[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

[SLuka.1]

Thanks for advise, but changing of stack is not very good idea for me.

Further investigations have shown, that stuck of netcon_send occurs, when incoming ARP packet is received by LWIP. If i send something to LWIP stack from remote machine LWIP transmission backs to life. Wireshark log is attached.

[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.