cancel
Showing results for 
Search instead for 
Did you mean: 

Unwanted interrupts for EthernetMAC (MMC)

michael2399
Associate II

We use a STM32F746 with Ethernet (ETH). We found a possible problem of the using the Ethernet (ETH) with actived interrupt. The Ethernet (ETH) has one interrupt vector for all interrupts of the Ethernet (ETH) (e. g. Receive, or Early Receive, ...) A lot of the interrupt must enable for using. But 3 interrupts are normal on and must be disable. This 3 interrupts are MMCI, PMTI, TSTI. Please see Figure 507 in RM0385 (Rev 6). Especially the MMC-Interrupt(s) are very critical, because if the microcontroller sends more then 2^31 frames, automaticly an interrupt is triggered.

We have this problem in our project (we use language Ada and an own envoirment - so it was my mistake to don't deactived this interrupts). But I looked in your STM32CubeMX and found no notice to the MMC-Interrupt or freezing the MM-Counters. If I did not overlook it, then is this problem in our drivers, too.

Please check if your interrupt handler do correctly acknowdledge the MMC-Interrupts. Otherwise, after 2 ^ 31 frames sent, the interrupt handler is constantly called. Alternatively, the interrupt must be actively switched off.

Please refered to the following chapters of the RM0384:

  • 38.5.7 MAC management counters MMC
  • 38.7. (Figure 507)
  • 38.8.2. ETH_MMCTIR and ETHMMCRIR, ETHMMCCR (for freeze)

Please give me a short feedback, if I'm right with my guess.

Best regards

Michael

4 REPLIES 4
Piranha
Chief II

To me it's not clear why hardware designers enabled these interrupts by default. MMC counter interrupts are triggered at 2^31 counted frames on each counter (which is not real to reach with ST's non-working bloatware), but it can be tested and verified easily by setting MCP bit in ETH_MMCCR register and waiting for 16 more frames. As none of the these interrupts are masked or cleared in HAL code, the ISR will be repeatedly called forever. Unless one really needs these interrupts, all of them should be masked in ETH initialization code:

ETH->MACIMR = ETH_MACIMR_TSTIM | ETH_MACIMR_PMTIM;
ETH->MMCRIMR = ETH_MMCRIMR_RGUFM | ETH_MMCRIMR_RFAEM | ETH_MMCRIMR_RFCEM;
ETH->MMCTIMR = ETH_MMCTIMR_TGFM | ETH_MMCTIMR_TGFMSCM | ETH_MMCTIMR_TGFSCM;

This is true for all STM32 MCUs with Ethernet. That includes H7 series, which also have the same problem, but the registers are different.

Thank you for your work. However, I have not found these or equivalent interrupts in H746 docs. Could you please reorder your summary post so that this issue isn't marked as concerning "all including H7s" accordingly to the interrupts' availability?

Piranha
Chief II

For H7 series the registers and bits are similar but not the same. Timestamp and PMT interrupt bits have been moved to ETH_MACIER register and are now disabled by default, but MMC interrupts are still enabled by default. This code should disable all of the MMC interrupts:

ETH->MMCRIMR = ETH_MMCRIMR_RXLPITRCIM | ETH_MMCRIMR_RXLPIUSCIM | ETH_MMCRIMR_RXUCGPIM | ETH_MMCRIMR_RXALGNERPIM | ETH_MMCRIMR_RXCRCERPIM;
ETH->MMCTIMR = ETH_MMCTIMR_TXLPITRCIM | ETH_MMCTIMR_TXLPIUSCIM | ETH_MMCTIMR_TXGPKTIM | ETH_MMCTIMR_TXMCOLGPIM | ETH_MMCTIMR_TXSCOLGPIM;

For some strange reason in reference manuals these registers are called ETH_MMC_RX_INTERRUPT_MASK and ETH_MMC_TX_INTERRUPT_MASK, which makes them hard to find in code and vice versa. The same is true for other MMC registers. And not having proper PDF bookmarks for ETH registers makes it even worse.

Also the bit RXLPITRCIM in register MMCRIMR and bit TXLPITRCIM in register MMCTIMR are documented as "r", when they should be "rw".

Piranha
Chief II

In the newer rewritten drivers ST have tried to fix this issue, but still managed to partially fail even in such a simple issue. The problem is that they disable these interrupts in a function HAL_ETH_Start_IT(). If someone uses their HAL_ETH_Start() function for data transfers but enables ETH NVIC interrupt because of some other ETH interrupt usage, then again these unwanted interrupts will happen. The safest, most universal and simplest solution is to just disable these unwanted interrupts in HAL_ETH_Init().