2024-05-11 03:32 AM
This reference is got from errata sheet of stm32h7. here they said some reason for related to my problem . and they given problem description and workaround . but in code(cubeMX generated code for ethernet udp socket programming) where i should apply these conditions i did not understand . so plz can anybody write (modify the hal functions) and share me the links or images of your modified code . thanks,,,,,,
*---> Subsequent packets are not transmitted when the transmit queue is flushed during packet
transmission
Description
===========:
When the transmit queue is flushed, the MTL layer completes the ongoing packet transmission and waits for a
status from the MAC layer. This status is provided to the application by updating the FF bit of the TDES0 transmit
descriptor word0. The MTL layer provides a dummy status with the FF bit set for every packet flushed in the
transmit queue. After the transmit queue flush operation is complete, the transmission restarts for packets
received from the application.
However, when the flush occurs during the second word of the packet being provided to the MAC layer, the
subsequent packets after the flush operation are not accepted for transmission by the MAC layer.
Workaround
===========:
Make sure the Tx path is inactive before issuing a Tx queue flush command. To do this, follow the following steps:
1. Make sure the Tx DMA engine is inactive (either in the Stop state or Suspend state), and not fetching any
descriptor. To do this, stop the Tx DMA engine (by clearing the ST bit of the channel transmit control register
(ETH_DMACTXCR)) or ensure that the Tx DMA engine has serviced all the available descriptors, and is in
Suspend state. The state of the DMA engine is reflected in the TPS0 bitfield of the ETH_DMADSR register.
2. Make sure the Tx MTL is inactive. To do this, check that all the bits of the Tx queue debug register
(ETH_MTLTXQDR ) return 0.
3. Make sure the Tx MAC is inactive. To do this, check that all the bits of the MAC debug register
(ETH_MACDR) return 0.
2024-05-11 04:00 AM
Why do you think this erratum is pertinent to your problem?
Do you flush the Tx queue in your program?
JW
2024-05-11 04:29 AM
Check what Jan said above.
I think even the HAL ETH drivers just don't flush the TX queue for fun.
Go through the code, line by line. Learn / understand what's going on.
What will you do with the next problem? Or when a new feature is needed?
ClickingCubeMX != HwDevelopment;
;)
2024-05-11 04:39 AM
---> that code is generated bu cubeMX ,, in that enabled the Tx queue flush
---> but if i dont flush the Tx queue , im getting ping problem (not pinging)
2024-05-11 06:20 AM
That flush is done before DMA is enabled, so that should be okay.
Anyway, who said that this flush is the problem?
Have you enabled some / all the lwIP debugging options? There's a lot of debug info available.