New Ethernet driver does not work properly (F4 series)

[user 143]

Guys, unfortunately I don't know what to do. A few days ago I updated to the latest HAL version for the F4 series (1.8.3). With 1.8.0 there was a big change in the Ethernet driver, so some adjustments were necessary. I already used the low_level_...() functions from ST, which are included in the examples and are also generated by CubeMX.

Since the upgrade I always get DMA errors in the function HAL_ETH_Transmit(). More precisely at the following point:

/* Wait for data to be transmitted or timeout occurred */
while ((dmatxdesc->DESC0 & ETH_DMATXDESC_OWN) != (uint32_t)RESET)
{
 if ((heth->Instance->DMASR & ETH_DMASR_FBES) ! = (uint32_t)RESET)
 {
 heth->ErrorCode |= HAL_ETH_ERROR_DMA;
 heth->DMAErrorCode = heth->Instance->DMASR;
 /* Return function status */
 return HAL_ERROR;
 }
[..]

heth->DMAErrorCode then contains the following value: 0x1886486

The strange thing is, simple pings, UDP and TCP echo servers work. However, as soon as the amount of data increases (http), the function exits with HAL_ERROR.
I also had a look at the parameters passed to the function low_level_output(struct netif *netif, struct pbuf *p), especially the *p variable and compared it with the old, working driver version. The content of *p is completely identical. There are 5 chained buffers. Both the content and the memory addresses are identical with the old and new driver versions. Ping and Co work because only one pbuf is allocated here.

I have now also created a new CubeMX project where only Ethernet is configured with LwIP. Here the same thing happens with the same error code in heth->DMAErrorCode.
Has anyone got the new Ethernet driver running on an F407? Any ideas?

 

 

[user 143]

Well, I was able to figure it out. Among other things, the FBES (Fatal Bus Error) and TBUS (Transmit Buffer Unavailable) bits are set in the DMASR register. As it turned out, however, this only happens when an attempt is made to access a buffer that is located in the flash. This occurs, for example, with the HTTP header (e.g. HTTP/1.0 200 OK or Server: lwIP/2.1.2 (http://savannah.nongnu.org/projects/lwip)). It makes sense that these are located in Flash, as they are constant anyway.

Apparently the Ethernet DMA cannot access the flash. Unfortunately, the Reference Manual (RM0090, Rev. 21) provides somewhat contradictory information on this. If you look at Figure 1, you can see that the Ethernet MAC cannot access the flash. However, Chapter 2.1.6 states "This bus connects the Ethernet DMA master interface to the BusMatrix. This bus is used by the Ethernet DMA to load/store data to a memory. The targets of this bus are data memories: internal SRAMs (SRAM1, SRAM2, SRAM3), internal flash memory, and external memories through the FSMC/FMC)". However, this statement probably only applies to the F42xxx and F43xxx series. Unfortunately, this is not entirely clear.

As I type these lines, I also notice that the example projects containing Ethernet are not for the F407.

As a solution, I have now adapted the low_level_output() function so that buffers that are localized in the flash are first copied to the RAM before they are transferred to the DMA:

/* check if the given payload address is in the RAM area */
if (((uint32_t)q->payload >= 0x20000000) && ((uint32_t)q->payload < 0x20020000))
{
 /* we can use the buffer directly */
 Txbuffer[i].buffer = (uint8_t *)q->payload;
 Txbuffer[i].len = q->len;
}
else
{
 /* the given payload is located in the FLASH => DMA can not handle FLASH addresses => copy into RAM */

 /* is enough space in our RAM buffer? */
 if (buffer_offset + q->len > ETH_RX_BUF_SIZE)
 {
	return ERR_MEM;
 }

 /* copy the data into our buffer */
 memcpy(tx_buffer + buffer_offset, q->payload, q->len);
 Txbuffer[i].buffer = tx_buffer + buffer_offset;
 Txbuffer[i].len = q->len;
 buffer_offset += q->len;
}

Can anyone confirm that the STM32F407 Ethernet DMA cannot access the flash? 

[mƎALLEm]

Hello,

---

@user 143 wrote:

Can anyone confirm that the STM32F407 Ethernet DMA cannot access the flash? 

---

For STM32F42x/STM32F43x (figure 2), they have access to the flash:

I need to check internally for STM32F407.

 

[FBL]

Hi @waclawek.jan I was wondering if you have a use case scenario as USB application to access the internal Flash memory by a host?

[waclawek.jan]

@FBL,

Not me personally, but for example the descriptors are quite naturally destined to be in FLASH as they are constant in many if not most of the applications.

The issue is not that it can't be avoided by any technique (as the simplest just copying them into RAM), but that one has to be aware of the potential problem.

JW

[mƎALLEm]

Hello all,

No connection of USB OTG nor Ethernet to the internal Flash is confirmed.

Proposed to update the two sections 2.1.6 and 2.1.7 to be more specific regarding that point.