cancel
Showing results for 
Search instead for 
Did you mean: 

ETH_SetMACConfig and ETH_SetDMAConfig function query

######
Senior

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;

 

 

 

 

1 ACCEPTED SOLUTION

Accepted Solutions
STea
ST Employee

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

 

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post

7 REPLIES 7
STea
ST Employee

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

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Hi @STea ,

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

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

And also the F4 ETH driver here line 2813 onwards. 

Hello @###### ,

I reported the issue internally for further investigation.

Internal ticket number: 179563 (This is an internal tracking number and is not accessible or usable by customers).

Thank you.

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
STea
ST Employee

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

 

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
LCE
Principal

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

STea
ST Employee

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

 

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.