2019-01-20 07:50 AM
DMABR->SR should be auto-cleared when set 1.
I haven't modified code - auto generated by hal.
It always timeouts - any ideas why? I tried to extend timeout time - bit 0 is always 1.
Here is code from HAL:
/* Ethernet Software reset */
/* Set the SWR bit: resets all MAC subsystem internal registers and logic */
/* After reset all the registers holds their respective reset values */
(heth->Instance)->DMABMR |= ETH_DMABMR_SR;
/* Get tick */
tickstart = HAL_GetTick();
/* Wait for software reset */
while (((heth->Instance)->DMABMR & ETH_DMABMR_SR) != (uint32_t)RESET)
{
/* Check for the Timeout */
if((HAL_GetTick() - tickstart ) > ETH_TIMEOUT_SWRESET)
{
heth->State= HAL_ETH_STATE_TIMEOUT;
/* Process Unlocked */
__HAL_UNLOCK(heth);
/* Note: The SWR is not performed if the ETH_RX_CLK or the ETH_TX_CLK are
not available, please check your external PHY or the IO configuration */
return HAL_TIMEOUT;
}
}
Bit 0 SR: Software reset When this bit is set, the MAC DMA controller resets all MAC Subsystem internal registers and logic. It is cleared automatically after the reset operation has completed in all of the core clock domains. Read a 0 value in this bit before re-programming any register of the core.
Solved! Go to Solution.
2019-01-20 10:21 AM
Problem solved. I was writing other data to the wrong register.
2019-01-20 09:44 AM
Look for MII/RMII, MAC clocks and pin configuration issues. ETH MAC has 3 main clocks which normally must be enabled and one optional for PTP.
2019-01-20 09:49 AM
That's really strange. I've been working all day on this mcu and now I'm getting dma error. Didn't make any changes on rmii/mac clocks etc.
2019-01-20 10:21 AM
Problem solved. I was writing other data to the wrong register.