STM32F429/LWIP totally stumped - it seems connected but isn't - Page 1
Forum section: electronics / general

author: alank2
author_rank: Super Contributor
timestamp: November 26, 2017, 10:17:23 pm
content: I've got a prototype board from a customer and they want me to develop a protocol over ethernet on it. The problem is that I can't get the ethernet working no matter what I try.They sent me code that they say they used to test the ethernet hardware functionality on their prototype, so they say that it worked. It is some stm32cubemx generated code that they created. I couldn't compile the code until I defined the _POSIX_C_SOURCE define to get past a timeval redefinition error. Once I did that, it would compile. I've put it on the device, run it, stepped it, and I don't see any place where errors are being returned. I have no link lights on the port on their PCB or at my switch, but yet it is attempting DHCP negotiation like the connection is up. In ethernetif.c if I put a breakpoint on the low_level_output function, I can see it is getting called to put out a DHCP request over and over again and it seems to call HAL_ETH_TransmitFrame(&heth, framelength); at the end and I've stepped through that with no errors. Why would it attempt this if the ethernet is not negotiated?I've also tried generating my own stm32cubemx code and other than changing the default ETH_TXD0 and ETH_TXD1 to PG13 and PG14, their configuration matches what it comes up with as default. Same results.I had another prototype board from them and it did the same thing. No link lights, but yet none of the functions I've traced show any type of failure.Anyone with LWIP/ethernet/stm32 knowledge have some ideas of what I can try?

author: Kjelt
author_rank: Super Contributor
timestamp: November 26, 2017, 10:59:59 pm
content: Check what external PHY chip they have used and the software for the initialization and handling of that phy chip. I don't think cubemx handles that because it is unaware which phy chip is used but perhaps you can choose that?The DHCP proces can take awhile , a minute easy.

author: alank2
author_rank: Super Contributor
timestamp: November 26, 2017, 11:05:12 pm
content: I think the PHY IC says on it:SMSC878742A6291QDABTWDHCP can't do anything until a physical ethernet link is established though, right? Until there is a link light and the speed/duplex is negotiated, I am assuming no packets can be sent/received.

author: Kjelt
author_rank: Super Contributor
timestamp: November 26, 2017, 11:08:35 pm
content: Oh yeah did you set the MAC address in the stm32 and check with wireshark in the requests if that is correct?Yes the physical link has to be done first than the data is sent to the stm32 where you handle the rest.Still this is not easy peasy , we had a team of 4 sw engineers working for weeks on it, unfortunately i was not part of that team so my help is limited.

author: Kjelt
author_rank: Super Contributor
timestamp: November 26, 2017, 11:12:06 pm
content: That is the 8742a phy chip , is it from Microchip?Read the datasheet carefully and check if all needed initialisation has been taken care of, we had a different chip that needed tweaking, perhaps this newer chip is better.

author: alank2
author_rank: Super Contributor
timestamp: November 26, 2017, 11:25:21 pm
content: Thanks - I will check into the datasheet and see what init it needs.

author: Kjelt
author_rank: Super Contributor
timestamp: November 26, 2017, 11:32:26 pm
content: Just had a quick view, the SMI data I/O, you can read/write some registers, for instance set auto negotiation and check if the link is up etc.

author: alank2
author_rank: Super Contributor
timestamp: November 26, 2017, 11:36:12 pm
content: I see that there is a MDIO (PA2) and MDC (PC1). I'll start searching the code to see what I can find.

author: alank2
author_rank: Super Contributor
timestamp: November 27, 2017, 12:12:15 am
content: Status Register is coming back 65535 - all 1's. It is moving to 10mbit/s which isn't working. What might cause it to get a bad SR back?

author: Janus
author_rank: Newbie
timestamp: November 27, 2017, 12:16:58 am
content: May find some useful info in the stm app note (for a slightly diff processor but same family).http://www.st.com/content/ccc/resource/technical/document/application_note/fd/5d/64/cf/7c/38/4c/30/DM00036052.pdf/files/DM00036052.pdf/jcr:content/translations/en.DM00036052.pdf

author: alank2
author_rank: Super Contributor
timestamp: November 27, 2017, 12:26:28 am
content: I found this PDF on the web (attached). Page 16 shows the values I find in the default code, it says for a DP83848.Page 15 shows the status register for the 8742A is 31 ? Is this the issue? I need to find a stm32f4xx_hal_conf.h with the correct values for the 8742A?

author: Janus
author_rank: Newbie
timestamp: November 27, 2017, 12:32:34 am
content: May be worth registering at mbed.org and setting the environment up for one of the stm demo boards for your specific processor.

author: alank2
author_rank: Super Contributor
timestamp: November 27, 2017, 12:42:04 am
content: I read something about the latest stm32cube having the PHY for the 8742a - going to try that.

author: Janus
author_rank: Newbie
timestamp: November 27, 2017, 12:49:00 am
content: Similar issue with someone on the related Nucleo Board:https://community.st.com/thread/44255-nucelo-stm32f429zi-with-8742a-phy

author: Janus
author_rank: Newbie
timestamp: November 27, 2017, 12:54:07 am
content: Take a peek at the low_level_init routine in here:https://github.com/ronen-yacobi/LwIp_TcpUdp_EchoServer/blob/master/src/ethernetif.c

author: alank2
author_rank: Super Contributor
timestamp: November 27, 2017, 01:11:35 am
content: Thanks Janus - I think this is the issue. I will dig in and see if I can get it working.I'm surprised the stm32cube doesn't let you pick which PHY. It even says "LAN8742A_PHY_ADDRESS" under the ETH advanced PHY, but doesn't generate the right code for it.

author: westfw
author_rank: Super Contributor
timestamp: November 27, 2017, 10:50:46 pm
content: QuoteIP protocols are generally pretty agnostic about checking out-of-band information about the status of interfaces. It wouldn't surprise me at all if the normal DHCP application does "send a request on every interface" without checking whether the interfaces are actually "up" at the time. Obviously you get no response from the interfaces that aren't up, but that's OK. ("it's a feature.")It's more surprising to get as deep into the ethernet driver without noticing, but it's still not inconceivable. "link status" is a physical layer thing; you wouldn't even have such info on an old 10base5 network... (Hmm. Even on modern MII and RMII interfaces between MAC and PHY, "up" is not an actaul signal; it's a status that you have to query over the management interface. (heh. Or use an extra user-defined pin to monitor on the the LED signals that PHY chips seem to provide. But: *user defined*))

author: alank2
author_rank: Super Contributor
timestamp: November 28, 2017, 01:51:00 am
content: I appreciate everyone's help. I've been looking at some examples sent to me, but they seem to be a different version of LWIP than the one I'm trying to adapt and get working.The Nucleo-144 STM32F429 _has_ the 8742A PHY on it, so I would think I could go into stm32cubemx and generate a project for it and have it produce working code, but while it talks about the 8742A, it still has 0x10 for the status register instead of 0x1F. Am I missing something or should the stm32cubemx produce working code?This example: STM32Cube_FW_F4_V1.17.0\Projects\STM32F429ZI-Nucleo\Applications\LwIP\LwIP_HTTP_Server_Netconn_RTOS has a ethernetif.c file which strips most of the PHY stuff out of it - The define PHY_SR in stm32f4xx_hal_conf.h points to 0x1F, but PHY_SR is not used anywhere that ultrafilesearch can find in the rest of the source.Part of the problem is that the other PHY uses an interrupt to call a function which updates the link state - I don't see code that does something similar for the 8742A.Maybe I should just try to reset it and manually read some registers and debug that to see if I get something that makes sense back.

author: alank2
author_rank: Super Contributor
timestamp: November 28, 2017, 02:41:19 am
content: I'm talking to the PHY now - no delays as I'm stepping through this code://resetHAL_ETH_WritePHYRegister(&heth, 0x00, _BV(15));//set reg4 and reg0 to autonegotiateHAL_ETH_WritePHYRegister(&heth, 0x04, _BV(| _BV(7) | _BV(6) | _BV(5));HAL_ETH_WritePHYRegister(&heth, 0x00, _BV(12));//set reg0 to 100 halfHAL_ETH_WritePHYRegister(&heth, 0x00, _BV(13));//read regsHAL_ETH_ReadPHYRegister(&heth, 0x00, &regvalue); //result 0x2000HAL_ETH_ReadPHYRegister(&heth, 0x04, &regvalue); //result 0x01e0HAL_ETH_ReadPHYRegister(&heth, 0x01, &regvalue); //result 0x7809 - able to negotiate, link is downHAL_ETH_ReadPHYRegister(&heth, 0x1F, &regvalue); //result 0x0048I have a network cable plugged into the jack, no lights, no link on the switch...

author: newbrain
author_rank: Super Contributor
timestamp: November 28, 2017, 07:14:19 pm
content: Quote from: alank2 on November 28, 2017, 01:51:00 amCube MX need to be configured to customize the code for the specific PHY, even if one starts the project with the right board.If you did not change the default value for the PHY Addr and the Special Control register offset (see attachments), the generated code will just use the default values, which are wrong for the Nucleo and that specific PHY.The same goes with interrupts: they have to be enabled in the configuration, otherwise the relevant skeleton will not be generated.

author: dgtl
author_rank: Regular Contributor
timestamp: November 29, 2017, 05:34:59 pm
content: iEth PHYs are quite well interchangeable. If the hw has been done correctly, getting the phy working should be easy.* First, check that the RMII/MII interface is configured correctly. If you are wired for MII, switch to MII; if you are wired for RMII, switch to RMII. Also, check your pinmux of the RMII/MII pins, that all of them are muxed correctly. Also check for the reset pin of the phy; if its connected to mcu, deassert the reset. If there are some other pins wired up, check them too.* Then check the clocking of the PHY. If the phy has separate xtal, then its easy. If the phy gets clocked from mcu's MCO, check that the MCO is set up correctly and has correct frequency (some RMII phys have internal pll and require 25MHz input clock, that gets multiplied to 50). Now, the phy should get link up; usually the default config works well enough.* Now start working on MDIO interface. First, double check the address of phy; the phys are addressed so that there could be multiple phys on one mdio interface. The addresses may depend on some strap pins of the phy. Test reading and writing some registers to verify MDIO access.* Just to test the network connectivity, do a netif_set_link_up after lwip initialization. The phy status is needed for a couple of things: up/down status triggers dhcp client; existing connections or attempts are rejected immediately instead of timeout; also if the link speed is slower 10M or half duplex, you may have to reconfigure ethernet mac registers for a different interface. But for testing, things work with hardcoded values, set the link up and mac to 100M full duplex. Now, set the ip address and get ping going.* As everything else works, write a service, that handles the phy link change. Either poll it every once in a while or set up the interrupt. The link status registers are usually the same over all phys, interrupt setup registers are not.

author: alank2
author_rank: Super Contributor
timestamp: November 29, 2017, 06:26:13 pm
content: I am beginning to wonder if the HW is done properly. I've got a nucleo board with the same PHY on it and am going to try testing it to see if it has different results.

author: ajb
author_rank: Super Contributor
timestamp: December 02, 2017, 04:14:46 am
content: PHYs typically have a bunch of pin strapping options that are used to set all sorts of configuration options at POR, so if your customer designed the board it's worth going through the datasheet and making sure they haven't done anything funny with the pin strapping.You generally shouldn't have to do much prodding of the PHY at all to at least get the link to come up. The SMI portion of the STM32 MAC peripheral is dead simple to use, so it may be worth creating a bare project and seeing if you can at least get it to link. Below are basic SMI read/write functions from an STM32F7 project, I believe they will work as-is on an STM324. Of course you'll also need to make sure the PHY is clocked correctly, which may or may not involve configuring the MDI portion of the MAC.Code:uint16_t ETH_MDIO_read(uint8_t phy_addr, uint8_t reg){while(ETH->MACMIIAR & ETH_MACMIIAR_MB);ETH->MACMIIAR =( (phy_addr << 11) & ETH_MACMIIAR_PA ) |( (reg << 6) & ETH_MACMIIAR_MR ) |ETH_MACMIIAR_MB;while(ETH->MACMIIAR & ETH_MACMIIAR_MB);return ETH->MACMIIDR;}void ETH_MDIO_write(uint8_t phy_addr, uint8_t reg, uint16_t data){while(ETH->MACMIIAR & ETH_MACMIIAR_MB);ETH->MACMIIDR = data;ETH->MACMIIAR =( (phy_addr << 11) & ETH_MACMIIAR_PA ) |( (reg << 6) & ETH_MACMIIAR_MR ) |ETH_MACMIIAR_MW |ETH_MACMIIAR_MB;}