Ethernet send complete interrupt not triggered in stm32f7

[PGovi]

Hello,

I am using stm32f7 ethernet interface. Send and Receive functionality is working as expected, whereas send complete interrupt is not triggered.

I came across this post https://community.st.com/s/question/0D50X00009XkgfISAR/stm32f767-nucleo-ethernet-not-working, wherein it is said that HAL_ETH_TxCpltCallback() is not triggered due to limitation.

Is HAL_ETH_TxCpltCallback() implemented in stm, or the limitation still persist ?

[Piranha]

In that topic it isn't said that interrupt isn't happening because of limitation. The post is only formal "The Ethernet limitations are described in" but in reality is not related to the topic and doesn't answer the topic. None of the errata issues interferes with Tx complete interrupt and I can assure that it works, as I use it in my Ethernet demonstration firmware, which works perfectly fine on NUCLEO-F767ZI:

https://community.st.com/s/question/0D50X0000AhNBoWSQW/actually-working-stm32-ethernet-and-lwip-demonstration-firmware

The problem is a documentation error in RM0410 (Rev 4).

• Section 42.6.7 page 1811: 8. Transmit Interrupt (ETH_DMASR register [0]) is set after completing the transmission of a frame that has Interrupt on Completion (TDES1[31]) set in its last descriptor. The DMA engine then returns to Step 3.
• Section 42.8.4 ETH_DMASR description page 1874: Bit 0 TS: Transmit status - This bit indicates that frame transmission is finished and TDES1[31] is set in the first descriptor.

In both places in reality it is the bit TDES0[30], which is defined as ETH_DMATXDESC_IC in HAL drivers. Also the words "last" and "first" contradict one another. I guess the "last" is the correct one.

The bit itself in section 42.6.7 page 1816 also has strange description:

• Bit 30 IC: Interrupt on completion - When set, this bit sets the Transmit Interrupt (Register 5[0]) after the present frame has been transmitted.

What(TF) is "Register 5" ??? I guess it's DMA subperipheral register number, but that is not correct/clear documentation in this context. It should be ETH_DMASR[0].

Actually all of these errors are exactly the same in all F7, F4, F2 and F1 series reference manuals dating back more than a decade! And also most of the newer ones don't have proper bookmarks for ETH peripheral register descriptions.

@Amel NASRI​, @Imen DAHMEN​ this is a documentation error report.

[Imen.D]

Hello @Piranha​ ,

I will check, then raise these typos internally for correction.

Thanks for your contribution and all comments and suggestions are welcome.

Best Regards,

Imen

[Imen.D]

Hello @Piranha​ ,

Regarding your report documentation error : the “last�? descriptor is correct because we will start from a different descriptor and transmit until we reach the last one.

Also, the first descriptor is right, because as soon as the DMA has finished (transferred the last descriptor) the last descriptor will become the “first�? for next transfer (in case of transfer complete (last equivalent to first)).

Moreover, it is bit 31 (TDES0[31]) and not bit 30.

Regarding "Register 5" : Yes, you are right. Register 5 is the DMA ETH_DMASR (Register 5[0] --> ETH_DMASR[0]).

So, we will change this in the RM0410.

I hope it answers your question.

Best Regards,

Imen

[Piranha]

I'm sorry, but You've got it wrong! The text "Interrupt on Completion (TDES1[31])" pretty clearly says which bit it means by the erroneous TDES1[31] and that is IC bit (TDES0[30]) not OWN bit (TDES0[31]).

> Also, the first descriptor is right, because as soon as the DMA has finished (transferred the last descriptor) the last descriptor will become the “first�? for next transfer (in case of transfer complete (last equivalent to first)).

This is nonsense. Are You talking about hardware internals or software, which is irrelevant here? Are You Yourself even able to understand this text at all? Anyway, all of this confusion comes from non-precise ST documentation. In this case:

"This bit indicates that frame transmission is finished and TDES1[31] is set in the first descriptor."

What does "is set" mean - user/CPU has set this bit before transfer or DMA has set it during/after the transfer? The ambiguous "is set" lead You to understood it as the former case and therefore think that it means OWN bit (which, by the way, is reset not set by DMA), but actually that text means the latter case and is talking about IC bit.

I'll show You from where does these errors come. Let's look at this:

http://pdf.datasheetcatalog.com/datasheet_pdf/asix-electronics-corporation/AX88141.pdf

Apparently that chip has another revision of the same peripheral design and for that revision these errors are actually true.

4.2.8 Status Register (REG5)

0 R/W/C TI - Transmit Interrupt

Indicates that a frame transmission was completed, while TDES1<31> is asserted in the first descriptor of the frame.

5.3.2 Transmit Descriptor 1 (TDES1)

31 IC - Interrupt on Completion

When set, the AX88141 sets transmit interrupt (REG5<0>) after the present frames has been transmitted. It is valid only when first segment (TDES1<30>) is set.

And here we have another implementation of the same peripheral:

https://www.espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdf

Table 41: Transmit Descriptor 0 (TDES0)

[30] IC: Interrupt on Completion

When set, this bit sets the Transmit Interrupt (Register 5[0]) after the present frame has been transmitted. This bit is valid only when the last segment bit (TDES0[29]) is set.

Now that's a clear technical description! Clear "is asserted", "is valid" bit states and no first/last contradiction - in that peripheral revision IC bit is valid only in a first descriptor. You should find out weather it's first or last descriptor in ST's related MCUs. I can add that my superficial testing of this on STM32F7 hardware seems to indicate that it's the last descriptor on which IC bit is valid.

> So, we will change this in the RM0410.

No that's not enough. I'll repeat once more - Actually all of these errors are exactly the same in all F7, F4, F2 and F1 series reference manuals dating back more than a decade!

[Piranha]

@Imen DAHMEN​, do you see now why ST needs to provide real bug reporting and tracking solution?

[LCE]

Wow, good to have @Piranha​ and this thread (and his other ethernet threads) here.

I just ran into this interrupt problem, caused by plainly WRONG documentation.

Just checked if there's a new reference manual out there, but no, my version's the current one, from 2018.

:sad_but_relieved_face:

[Piranha]

I can confirm now that the IC bit indeed is only valid for the last segment.

In addition to all of this, now even the rewritten HAL driver uses the IC bit, and, of course, it sets it in the TDES0[30] on the last segment. Therefore now even their own HAL code confirms these documentation errors.

What's even worse, is the fact that in the beginning of the 2021 ST released new revisions for F4 (RM0090), F2 (RM0033), F1 (RM0008) reference manuals and for the ETH section they only renamed the "Register 5" to "ETH_DMASR", but ignored everything else reported in this topic three years ago. Also the description in revision history is seriously incomplete in RM0008 and partially incomplete in RM0033.

[BarryWhit]

@Amel NASRI , similar situation to here.