Hey there!
I've been playing around with the Ethernet HAL driver on the NUCLEO-H563ZI and I was able to make it work. I'm currently using the latest STM32CubeH5 package release.
Here's the issue: whenever I receive an ethernet packet, the interrupt at HAL_ETH_IRQHandler always triggers HAL_ETH_RxCpltCallback and then HAL_ETH_ErrorCallback with the error 0x4480 or 0x4080. In short, an Abnormal Interrupt of either "Receive Buffer Unavailable" or "Transmit Buffer Unavailable".
At first I thought it was due to the time the application was taken from the DMA, preventing it from getting the ownership of the descriptor. However, I can't really reason why or where this can happen. When the application owns the descriptor (HAL_ETH_RxLinkCallback) I only pass a pointer (minimal overhead) and right before the ownership of the descriptor is given to the DMA, the call of HAL_ETH_RxAllocateCallback is also fast enough.
My HAL_ETH_RxLinkCallback:
void HAL_ETH_RxLinkCallback(void** pStart, void** pEnd, uint8_t* buff, uint16_t Length)
{
// *pStart contains the start address of the received data (always available)
*pStart = buff;
// Note: the current HAL implementation only uses one descriptor buffer.
// Therefore, the use of pEnd is unnecessary.
}
My HAL_ETH_RxAllocateCallback:
void HAL_ETH_RxAllocateCallback(uint8_t** buff)
{
// The passed pointer is a reused pointer, it might be null the first time
// this function is called, but it will eventually come with an address later.
*buff = (uint8_t*)dma_rx_link_head->buffer;
// Move the rx_link head to the next buffer.
dma_rx_link_head = dma_rx_link_head->next;
}
The dma_rx_link is defined as:
struct dma_rx_link {
uint8_t buffer[ETH_RX_BUFFER_SIZE];
struct dma_rx_link* next;
};
Additionally, I have noticed the application, on HAL_ETH_ReadData, only checks the current descriptor and if one descriptor is busy by the DMA, it returns an error. Wouldn't be more correct to try the next one instead until the four descriptors were fully checked?
