ETH_SetMACConfig and ETH_SetDMAConfig function query

[######]

Hello,

Just wondering if anyone knows the reason for the duplicate writes to the following registers in the HAL Ethernet code please?

ETH->MACCR

ETH->MACFCR

ETH->DMAOMR

ETH->DMABMR

In the example shown below (from HAL code) the DMA0MR register is written to, then read back, 1 msec delay and then written to.

I've taken note of the need for the 4 clock cycle delay, however is it necessary to perform the duplicate writes?

Thanks in advance.

Edit: I'm using Cube FW F4 v1.28. 

 

 

/*----------------------- ETHERNET DMAOMR Configuration --------------------*/
 /* Get the ETHERNET DMAOMR value */
 tmpreg1 = (heth->Instance)->DMAOMR;
 /* Clear xx bits */
 tmpreg1 &= ETH_DMAOMR_CLEAR_MASK;

 tmpreg1 |= (uint32_t)(((uint32_t)((dmaconf->DropTCPIPChecksumErrorFrame == DISABLE) ? 1U : 0U) << 26U) |
 ((uint32_t)dmaconf->ReceiveStoreForward << 25U) |
 ((uint32_t)((dmaconf->FlushRxPacket == DISABLE) ? 1U : 0U) << 20U) |
 ((uint32_t)dmaconf->TransmitStoreForward << 21U) |
 dmaconf->TransmitThresholdControl |
 ((uint32_t)dmaconf->ForwardErrorFrames << 7U) |
 ((uint32_t)dmaconf->ForwardUndersizedGoodFrames << 6U) |
 dmaconf->ReceiveThresholdControl |
 ((uint32_t)dmaconf->SecondFrameOperate << 2U));

 /* Write to ETHERNET DMAOMR */
 (heth->Instance)->DMAOMR = (uint32_t)tmpreg1;

 /* Wait until the write operation will be taken into account:
 at least four TX_CLK/RX_CLK clock cycles */
 tmpreg1 = (heth->Instance)->DMAOMR;
 HAL_Delay(ETH_REG_WRITE_DELAY);
 (heth->Instance)->DMAOMR = tmpreg1;

 

 

 

 

[STea]

Hello @###### ,

Can you please specify the version of the driver and the product you are working on as it seems like you are looking to an older implementation of the ETH driver.

BR

[mƎALLEm]

Hi @STea ,

I think he's talking about F7 ETH driver (from here). See for example ETH_SetDMAConfig() implementation (line 2813)

[STea]

Hello @###### ,

After checking this implementation in the HAL driver is an implementation of the workaround 2 of a known limitation related to the 2.16.6 Successive write operations to the same register might not be fully taken into account

which can be found in the following Errata STM32F427/437 and STM32F429/439 device errata - Errata sheet.

in fact, a write to a register might not be fully taken into account if a previous write to the same register is performed
within a time period of four TX_CLK/RX_CLK clock cycles. When this error occurs, reading the register returns
the most recently written value, but the Ethernet MAC continues to operate as if the latest write operation never
occurred.

the solution implemented in the driver is to make several writes without delay then a read when all write operations are complete and then wait for a delay of four TX_CLK/RX_CLK clock cycles and we perform another write which is the case of the second workaround.

Workarounds
Applty on of the following measures:
• Ensure a delay of four TX_CLK/RX_CLK clock cycles between the successive write operations to the same
register.
• Make several successive write operations without delay, then read the register when all the operations are
complete, and finally reprogram it after a delay of four TX_CLK/RX_CLK clock cycles.

BR

 

[LCE]

@STea so this applies only to the F4, not the F7?

[STea]

Hello @LCE ,

This limitation is found in the F4 and not in F7 series hence this workaround is not implemented in the F7 driver.

BR