fjpanag opened a new issue, #8576: URL: https://github.com/apache/nuttx/issues/8576
While browsing the [STM32F4 reference manual](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwj9lIylrp_9AhWicPEDHRWTBKEQFnoECBYQAQ&url=https%3A%2F%2Fwww.st.com%2Fresource%2Fen%2Freference_manual%2Fdm00031020-stm32f405-415-stm32f407-417-stm32f427-437-and-stm32f429-439-advanced-arm-based-32-bit-mcus-stmicroelectronics.pdf&usg=AOvVaw2x8tbTRz8d9PfqXBk3qZ74), I noticed this note in page 1166: > **33.6.6 - Error response to DMA** > For any data transfer initiated by a DMA channel, if the slave replies with an error response, > that DMA stops all operations and updates the error bits and the fatal bus error bit in the > Status register (ETH_DMASR register). That DMA controller can resume operation only > after soft- or hard-resetting the peripheral and re-initializing the DMA. I checked the Ethernet driver, these errors are checked [here](https://github.com/apache/nuttx/blob/master/arch/arm/src/stm32/stm32_eth.c#L2036). However, there is no error handling at all! The check is enabled only when `CONFIG_DEBUG_NET` is enabled, and only does some logging. This is not very good, and it can be related to a bug that I experience occasionally (the MAC dies completely). I am thinking that the best course of action would be to cause an `ifdown`. Higher layers of the software will be able to detect this, and request a new `ifup`, effectively resetting the interface. Similar handling to simply disconnecting the cable, for example. How can the low-level driver cause such an event (without compromising the OS architecture)? Or is there any suggestion of better handling this? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
