#define LAN_CHIP_STATUS_10MBITS_HALFDUPLEX ((int32_t) 5) #define LAN_CHIP_STATUS_10MBITS_FULLDUPLEX ((int32_t) 4) #define LAN_CHIP_STATUS_100MBITS_HALFDUPLEX ((int32_t) 3) #define LAN_CHIP_STATUS_100MBITS_FULLDUPLEX ((int32_t) 2) #define LAN_CHIP_STATUS_LINK_DOWN ((int32_t) 1) #define LAN_CHIP_STATUS_RESET_TIMEOUT ((int32_t)-2) #define LAN_CHIP_STATUS_ADDRESS_ERROR ((int32_t)-3) #define LAN_CHIP_STATUS_WRITE_ERROR ((int32_t)-4) #define LAN_CHIP_STATUS_READ_ERROR ((int32_t)-5) They defined the result from GetLinkState using the following defines: I am not sure about other STMCube examples, but in the STM32H7 ST engineers finally came up with elegant Ethernet PHY handling and LwIP synchronisation. In even simpler configuration you can use single thread blocking for some time on a semaphore and ETH IRQ to wake it up for data processing. On the ETH IRQ, when data present you can signal semaphore to wake-up another task, ETH incoming data thread, that will empty quickly the ETH DMA descriptors.īecause the the ETH controlling thread mostly sleeps, it does not disturb the ETH incoming data thread. I used low priority ETH controlling thread with state machine switching processing between NO_ETHERNET / STATIC IP / DHCP + PHY link status check - configurable e.g from BLE etc. You can use another thread probing the Basic Status Register in PHY to see the link status and trigger correct action. The IRQ handler in stm32fxxx_hal_eth.c only checks DMA flags, so if there is no code using the MII bus - if the IRQ user callbacks do not use it. If you look into the HAL_ETH_IRQHandler (I used as example F4 series) you will see that there is not use of MII bus. That means that this task should be executed with the lowest priority, am I right ? This is a blocking execution when running at startup it's not really a problem, but if running from a thread (when app needs to reinit MAC after link switching from down to up), that does not give the hand to lower priority task until operations are finished. In stm32f2xx_hal_eth.c, each step is limited by a timeout, for example 5 seconds to get the link (ETH_TIMEOUT_LINKED_STATE), and this is defined inside the file itself, not a configurable feature without modifying the driver. Moreover, I'm surprised that the init function is so long for initializing. Would it be more reliable if I get the functions related to link state change management from an EVAL demo, and I just modify the trigger of the call to be not an interrupt, but a periodic delay (ie every second) ? Would that be reliable ? Does someone has some tips to give to me, or have better implementations of low level ethernet management with freertos/lwip ? What happens if I'm accessing the PHY with my test task, and an IT triggers with received data to handle ? But I'm afraid of interfering with ETH interrupt. If link down, call the function that disables the MAC, and stop the high level ethernet tasks. if link is up, check if the heth->State is equal to HAL_ETH_STATE_READY, and if ready, check the PHY register to see if link is still up. if link is down, check the PHY status register, and if link is now up, restart the init sequence and create all the threads required by my application using ethernet However, my idea is to create a task with priority higher than ethernet task, executed periodically : The only solution I see would be to check periodically the PHY internal STATUS register to check link status, but I'm not confident enough to modify the driver and perform checks without inferering with existing running driver task. So I'm not able to use that kind of warning to handle link status changes. But on the NUCLEO144 boards, using a low cost PHY (LAN8742) the INT signal is not connected and used a clock signal to synchronise PHY and MAC. I looked at code examples for EVAL boards and in this case this is handled by an additionnal task because the PHY has an INT signal connected to the STM32, that triggers the link check routines. If link is up at start and application runs correctly, I'm not informed by low level driver of link loss. If link is down at startup and becomes up later, the driver does not get the updated information and the system remains down. My application works fine, but the ethernet low level management is pretty basic (generated by CubeMX) : wait for 5 seconds to get a link up, then run app. This is my first projet with STM32, FreeRTOS and LwIP. Base project is generated from CubeMX and I work under Atollic True Studio. My application uses ethernet link (TCP, UDP client and server) and FreeRTOS. I'm developping a demonstrator with a shield I made to fit a Nucleo 144 - F207ZG board.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |