Skip to main content
teijo
teijo
Associate II
October 11, 2016
Question

stm32f4CubeMx IAR ethernet + lwip project, eth receive problem

  • October 11, 2016
  • 2 replies
  • 781 views
Posted on October 11, 2016 at 13:52

Hi,

I'm creating new project for CubeMx and using freeRtos and lwip. i was able to get eth tx workin(verified in tcpdump) dhcp request with correct mac. I was unable to get ethernet to react on receive -> there is no ethernet RX IRQ.

Thing that i've done:

- Changed PHY ADDR to 0 (default is 1)

- added 1s delay before mac and phy init

In these changes we managed to get TX working

When i enable eth dma error irq flags i i get  TBUIE: transmit buffer unavailable interrupt

and and ethernet is not working any more in neither direction.

Using stm32f407 and micrel ksz8081 phy

All ideas are welcome!  

#smt32f4-cubemx
This topic has been closed for replies.

2 replies

Walid FTITI_O
Walid FTITI_O
Visitor II
October 11, 2016
Posted on October 11, 2016 at 19:50

Hi ,

Frist which version of STM32CubeMx you are using ? Check of you are not at the same conditions described in this

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/STM32F107%20ethernet%20interrupt%20problem&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=963

.

Otherwise, I submit your feedback tou our CubeMx team for check.

-Hannibal-

teijo
teijoAuthor
Associate II
October 12, 2016
Posted on October 12, 2016 at 16:45

Yes! i get ethernet working! i update cube and that do the trick. I found one thing. Ethernet interrupt priority is generated 0 and it must be configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY or higher in value.

FYI:

I have other board with stm32f427and ksz8794cnx phy(4 port switch). default generated code didn't work(complete silent) but i tinker with eth settings. i get it work by force -> DuplexMode = ETH_MODE_HALFDUPLEX and Speed = ETH_SPEED_100M. I'm not sure why autonegotation went wrong but now it works! Thanks!

br

Teijo

matthewgkerr
matthewgkerr
Associate III
May 23, 2017
Posted on May 23, 2017 at 01:42

Teijo,

I'm having a similar problem. The HAL Ether driver assumes a single PHY. My designs use a MICREL 3-port and 5-port switch. So i've modified the code to configure all PHY.

Also, some of the steps during the initialisation don't make sense for my switch. For example, soft reset is not supported, so this step blows away my default settings; i.e. it disables Auto-negotiation. Also, the last step of auto-negotiation is to read back the speed and duplex. I'm using MIIM to configure the PHY, which means I don't have access to the extended registers. The register value which is read back is nonsense (0xFF), which results in further unexpected behavior.

I think what you have done is the best way forwards, but it's unfortunate having to use a fixed speed and duplex.

On my chip I have access to all registers using the MICREL propitiatory SMI protocol. However, I really was trying to avoid doing this. 

If you have learnt anything further, please let me know.

Regards, Matt.

Terms & ConditionsAccessibility statement