I had a similar looking issue last week bringing up lwip for the first time. In my case it was because I hadn't set both the interface and the link as being 'up'.
Will On 18 Jan 2018 5:46 pm, "Chris Seto" <chris1s...@gmail.com> wrote: > Hi Noam, Thanks for the reply. > > A few of the defs seemed to be wrong for my PHY. Specifically, the bits in > MISR and BMSR. Slight differences. The bits existed, but not in the order > the HAL config files indicated them to.I copied my config to the bottom of > this message. > > That said, I don't think that the PHY is the issue for this problem, since > it does seem like the PHY is RX'ing, but the bigger issue I'm seeing is > that I'm not even getting debug output from LwIP other than "etharp_timer" > once every second. I can confirm that I can talk to the PHY and that it's > up and running ok. When I mentioned that I can guarantee the link up after > low_level_init runs, what I meant is that I can actually watch the > registers change, and I don't let low_level_init run until the link is up, > as per the PHY SR. > > I'm guessing the issue here is some config value in LwIP. > > I've also tried allowing a full hanging ASSERT, the code never ASSERTs. > > I've played around with the debug message config, and I simply cannot > tease any other messages out of the stack, even though at least DHCP is > started. I do know that printf works called from LwIP, because I can at > least see the etharp_timer message. > > Thanks, > Chris > > *For the TLK110, here are my settings:* > > > // TLK110 datasheet, page 5 > #define PHY_ADDR 0x01 > > // TLK110 Registers > #define PHY_MISR1 0x0012 > #define PHY_BMSR 0x0001 > > #define PHY_BCR ((uint16_t)0x00) /*!< Transceiver > Basic Control Register */ > #define PHY_BSR ((uint16_t)0x01) /*!< Transceiver > Basic Status Register */ > #define PHY_RESET ((uint16_t)(1 << 15)) /*!< PHY > Reset */ > #define PHY_LOOPBACK ((uint16_t)(1 << 14)) /*!< Select > loop-back mode */ > #define PHY_AUTONEGOTIATION ((uint16_t)(1 << 12)) /*!< Enable > auto-negotiation function */ > #define PHY_RESTART_AUTONEGOTIATION ((uint16_t)(1 << 9)) /*!< Restart > auto-negotiation function */ > #define PHY_POWERDOWN ((uint16_t)(1 << 11)) /*!< Select > the power down mode */ > #define PHY_ISOLATE ((uint16_t)(1 << 10)) /*!< > Isolate PHY from MII */ > #define PHY_AUTONEGO_COMPLETE ((uint16_t)(1 << 5)) /*!< > Auto-Negotiation process completed */ > #define PHY_LINKED_STATUS ((uint16_t)(1 << 2)) /*!< Valid > link established */ > #define PHY_JABBER_DETECTION ((uint16_t)(1 << 1)) /*!< Jabber > condition detected */ > > #define PHY_SR ((uint16_t)0x10) /*!< PHY > special control/ status register Offset */ > #define PHY_SPEED_STATUS ((uint16_t)(1 << 1)) /*!< PHY > Speed mask */ > #define PHY_DUPLEX_STATUS ((uint16_t)(1 << 2)) /*!< PHY > Duplex mask */ > > > > On Thu, Jan 18, 2018 at 11:31 AM, Noam Weissman <n...@silrd.com> wrote: > >> Hi Chris, >> >> >> >> I am not working with ST HAL, rather with the older SPL (standard >> peripheral library). >> >> >> >> I do not know why you needed to change the PHY driver as all the standard >> PHY’s that are IEEE >> >> compatible will work the same. >> >> >> >> The ST driver has two portions: >> >> 1. MDIO/MDC connectivity (SMI) >> >> 2. RMII/MII data transfer etc… >> >> >> >> Via SMI you control the PHY and or make queries. Meaning you can check if >> you have a link, >> >> what is the speed etc… >> >> >> >> Regarding MII/RMII you need to make sure that you defined the driver to >> work in the same mode >> >> that the PHY is strapped. If the PHY is defined to work in RMII but your >> driver is defined to work in MII, >> >> it will not work ! >> >> >> >> I suggest going over ST examples first and then try to see why you code >> is not working for you. >> >> >> >> >> >> BT, >> >> Noam. >> >> >> >> >> >> *From:* lwip-users [mailto:lwip-users-bounces+noam=silrd....@nongnu.org] *On >> Behalf Of *Chris Seto >> *Sent:* Thursday, January 18, 2018 6:47 PM >> *To:* lwip-users@nongnu.org >> *Subject:* [lwip-users] LWIP never tries to send a packet? >> >> >> >> Hi, >> >> >> >> I'm using LwIP 2.0 running on an STM32F4 with a TI TLK110 ethernet PHY. >> I've written the driver for the PHY and corrected the definitions within >> the STM32 HAL such that the PHY is initialized correctly. When >> low_level_init() returns, the link is guaranteed physically up. >> >> >> >> I'm having an issue where it doesn't seem like LwIP is ever trying to >> send packets. I put printf("RX\r\n"); and printf("TX\r\n"); calls in my >> ethernetif.c handlers, and while RX periodically is called, TX is /never/ >> called. Even if I try to open a TCP socket, and even if I try dhcp_start(). >> >> >> >> I'm sure this is some kind of minor config issue. Any advice? >> >> >> >> Debugging is enabled, and I see a bunch of "etharp_timer" at about 2hz or >> so, but nothing else. Shouldn't I at least expect to see a DHCP discover >> packet sent? >> >> >> >> Code here: >> >> >> >> ethernetif.c >> >> https://pastebin.com/eXGyDWJX >> >> >> >> lwipopts.h >> >> https://pastebin.com/ZTmmG43P >> >> >> >> Networking.c >> >> https://pastebin.com/20DN07dy >> >> >> >> Main loop: >> >> while (1) >> >> { >> >> HAL_Delay(50); >> >> LedToggle(LED_1); >> >> LedToggle(LED_2); >> >> NetworkingUpdate(); >> >> } >> >> >> >> Thanks! >> >> _______________________________________________ >> lwip-users mailing list >> lwip-users@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/lwip-users >> > > > _______________________________________________ > lwip-users mailing list > lwip-users@nongnu.org > https://lists.nongnu.org/mailman/listinfo/lwip-users >
_______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
