Nucleo-F767ZI and Ethernet with lwIP

matteo23 · ‎2016-11-03

Posted on November 03, 2016 at 16:58

hi everybody, i was trying to set up an udp echo client by looking at the examples for the other boards provided in the F7 firmware package, after using CubeMX to initialize my board for Ethernet (in RMII mode) and lwIP.

I've basically ported what i've seen in the other examples to my System Workbench project, everything compiles fine and run smooth (it never gets stuck into some initializations).

But for some reason i can't send anything to the udp server i've set up with echotool and also i can't even ping my board.

I was also searching for clues on the forum too, and i've seen there may be some issues with the RMII on this board (i have Revision B).

So i wanted to ask: is it actually this board malfunction that makes me unable to communicate with my pc? or is it something more code related?

Let me know if attaching the whole project can be useful to receive some more detailed help.

Thanks in advance.

slimen · ‎2016-11-03

Posted on November 03, 2016 at 18:45

Hello,

Have a look to this

http://www.st.com/content/ccc/resource/technical/document/errata_sheet/group0/23/a6/11/0b/30/24/46/a5/DM00257543/files/DM00257543.pdf/jcr:content/translations/en.DM00257543.pdf

related to the STM32F767 devices, in the section ''Ethernet peripheral limitations'' ([DEAD LINK /public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Stm32F767%20Nucleo%20Ethernet%20does%20not%20always%20start&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&TopicsView=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/AllItems.aspx&currentviews=27]thread with Ethernet limitation) to check if you have the same conditions as described in the errata sheet.

Else, if the issue is not related to the know limitations, I suggest you to debug, localize where the code hangs/stop, identify what is the problem that you see and when it occurs.

Then, you can share your code if this issue is not resolved.

Regards

matteo23 · ‎2016-11-04

Posted on November 04, 2016 at 08:58

Hi, i've really spent some time trying to see if something goes wrong during the configuration phase, and it looks like everything works fine (i've set up the red led to notify that netif got working and blue led to notify that it created an udp connection). Also looking at the errata sheet i could be in the RMII rx malfunction condition, but still i think i should be supposed to seewith Wiresharkthe packets i send from the board every second, but that doesn't happen too.

Here i attached the Src folder of my project.

Regards.

________________

Attachments :

ether2.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HzwV&d=%2Fa%2F0X0000000bRM%2F3eDlJCIThDjEehrc7ijq1Wt8di.yW87VRwh97i9HSGY&asPdf=false

matteo23 · ‎2016-11-04

Posted on November 04, 2016 at 14:07

I Just checked with an oscilloscope and on TXD0 i can actually see some data going out, but wireshark can't recognize any activity from that.

Also TXD0 seems to be the only pin that has something going on.

kenny · ‎2016-11-05

Posted on November 06, 2016 at 00:35

I'm in the same boat--I can see activity on the TX lines with a clock but nothing on the packet sniffer. I also stepped through the initialization code though it is complex enough that it is difficult to know if the error handling is robust. The RMII issues has to do with RX so one would think you could at least see an ethernet frame associated with an outgoing UDP packet. I'm just trying to get DHCP to work which uses UDP. I'm wondering if used with a reliable protocol like TCP/IP if it would detect the corrupt packets and resend. I have a board leaving layout that assumed the Nucleo was known to work (and before I read the October 2016 errata). I had imagined that the IP related to EMAC was the same or derived from that used on the STM32F4 which was commonly used.

I asked on the software tools forum: Is the Nucleo 767 known to work with Cube/LWIP generated code and got no answer in a week. Maybe ST is focusing on their H7 parts and can't be bothered.

matteo23 · ‎2016-11-07

Posted on November 08, 2016 at 08:45

yeah it's kind of frustrating, to be honest. The worst part of all this is that, knowing CubeMX is supposed to do the job right and that the lwIP management i've seen in the other examples works, i can't really spot what could be wrong. Looking at the results (aka seeing activity in between the MCU, except on the RX pins, and the PHY) the only possibilities are that the PHY is not behaving right or CubeMX is having some default parameters that aren't correct.

Either way some more support on this would be so much appreciated.