Hi,
Probably there are more differences in schematic, you need to create new board files for your revision C and make sure that all pins are programmed according to the schematic.
Start with duplicating the board directory and add a _REVC suffix to the name, then edit board.* files. When the board files are done modify the Makefile to point to them
Giovanni
STM32 Ethernet Demo
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: STM32 Ethernet Demo
Hi,
The ethernet pins remain the same from RevA, except a new pin called PHY_SOFT_RST (PD4) which, as is, is configured as an input with pull up. I noticed that STM32 E407 RevD, which uses the same PHY chip, also has that pin configured as an input with PU so that should not be the problem.
I didn't confirm the values of GPIO*CRL, GPIO*CRH and GPIO*ODR but I assume that since they are working with RevA, which has the same pin usage, they sould be correct.
I need to get some sleep but I'll keep debuging it Meanwhile, if you have additional ideas please let me know. Any help is greatly appreciated.
The ethernet pins remain the same from RevA, except a new pin called PHY_SOFT_RST (PD4) which, as is, is configured as an input with pull up. I noticed that STM32 E407 RevD, which uses the same PHY chip, also has that pin configured as an input with PU so that should not be the problem.
I didn't confirm the values of GPIO*CRL, GPIO*CRH and GPIO*ODR but I assume that since they are working with RevA, which has the same pin usage, they sould be correct.
I need to get some sleep but I'll keep debuging it Meanwhile, if you have additional ideas please let me know. Any help is greatly appreciated.
Re: STM32 Ethernet Demo
Hi,
Can you provide me some guidelines on how to debug the LWIP stack?
I noticed that the LWIP debug macros (_ASSERT and _DIAG) don't print any message. I was thinking of using some prints to check where the stack is hanging due to some wrong parameter.
Since the lwip_thread parameter is used to pass the stack's parameters how should I pass the serial driver being used in the demo? (Im looking to "test" thread as a reference).
Another question, what is the default IP and how can I change it? Are there additional parameters that are dependent on my local ethernet connection and that should be changed accordingly?
Thanks
Can you provide me some guidelines on how to debug the LWIP stack?
I noticed that the LWIP debug macros (_ASSERT and _DIAG) don't print any message. I was thinking of using some prints to check where the stack is hanging due to some wrong parameter.
Since the lwip_thread parameter is used to pass the stack's parameters how should I pass the serial driver being used in the demo? (Im looking to "test" thread as a reference).
Another question, what is the default IP and how can I change it? Are there additional parameters that are dependent on my local ethernet connection and that should be changed accordingly?
Thanks
Re: STM32 Ethernet Demo
Ok, I made some progress but still no idea of whats the cause of the problem.
Enabling all debug options in the lwipopts.h and using the following code to get prints:
[cc.h]
I get the following output:
First both LEDs blink (slowly), then when the board receives some packets ("packet not for us"), the green led is turned off and the orange is kept on.
For this to work I had also to place a print in the netconn_new_with_proto_and_callback() [api_lib.c] just at the begining of the function (you can see the name of the function being printed in the log above), otherwise I'll get a:
Any suggestion?
Enabling all debug options in the lwipopts.h and using the following code to get prints:
[cc.h]
Code: Select all
#ifndef __CC_H__
#define __CC_H__
#include <ch.h>
#include <hal.h>
#include <inttypes.h>
#include <chprintf.h>
typedef uint8_t u8_t;
typedef int8_t s8_t;
typedef uint16_t u16_t;
typedef int16_t s16_t;
typedef uint32_t u32_t;
typedef int32_t s32_t;
typedef uint32_t mem_ptr_t;
/* Define (sn)printf formatters for these lwIP types */
#define U16_F PRIu16
#define S16_F PRIu16
#define X16_F PRIx16
#define U32_F PRIu32
#define S32_F PRId32
#define X32_F PRIx32
#define LWIP_ENABLE_PRINTS
extern Mutex SD3mtx;
#ifdef LWIP_ENABLE_PRINTS
#define LWIP_PRINT(...) {while(!chMtxTryLock(&SD3mtx));chprintf((BaseSequentialStream*) &SD3, __VA_ARGS__);chMtxUnlock();}
#define LWIP_PLATFORM_DIAG(x) {LWIP_PRINT x;}
#define LWIP_PLATFORM_ASSERT(x) {\
LWIP_PRINT("\n\n\rAssertion \"%s\" failed at line %d in %s\n", x, __LINE__, __FILE__);\
LWIP_PRINT(x); chSysHalt(); }
#else
#define LWIP_PLATFORM_DIAG(x)
#define LWIP_PLATFORM_ASSERT(x) { \
chSysHalt(); \
}
#endif
#define BYTE_ORDER LITTLE_ENDIAN
#define LWIP_PROVIDE_ERRNO
#endif /* __CC_H__ */
I get the following output:
Code: Select all
lwip_thread
sys_timeout: p msecs=536890160 handler= arg=p
sys_timeout: p msecs=536890140 handler= arg=p
netif_set_ipaddr: netif address being changed
netif: IP address of interface set to 192.168.1.67
netif: netmask of interface set to 255.255.255.0
netif: GW address of interface set to 192.168.1.255
netif: added interface ms IP addr 192.168.1.67 netmask 255.255.255.0 gw 192.168.1.255
netif: setting default interface ms
etharp_request: sending ARP request.
pbuf_alloc(length=42)
pbuf_alloc(length=42) == p
etharp_raw: sending raw ARP packet.
netconn_new_with_proto_and_callback
tcpip_thread: API message p
tcpip_thread: API message p
tcp_bind: bind to port 80
tcpip_thread: API message p
pbuf_free(p)
pbuf_free: deallocating p
tcpip_thread: CALLBACK p
stmf calling h=ip_reass_timer arg=p
tcpip: ip_reass_tmr()
sys_timeout: p msecs=536890160 handler= arg=p
stmf calling h=ip_reass_timer arg=p
tcpip: ip_reass_tmr()
sys_timeout: p msecs=536890160 handler= arg=p
stmf calling h=ip_reass_timer arg=p
tcpip: ip_reass_tmr()
sys_timeout: p msecs=536890160 handler= arg=p
stmf calling h=ip_reass_timer arg=p
tcpip: ip_reass_tmr()
sys_timeout: p msecs=536890160 handler= arg=p
stmf calling h=arp_timer arg=p
tcpip: etharp_tmr()
etharp_timer
sys_timeout: p msecs=536890140 handler= arg=p
stmf calling h=ip_reass_timer arg=p
tcpip: ip_reass_tmr()
sys_timeout: p msecs=536890160 handler= arg=p
stmf calling h=ip_reass_timer arg=p
tcpip: ip_reass_tmr()
sys_timeout: p msecs=536890160 handler= arg=p
stmf calling h=ip_reass_timer arg=p
tcpip: ip_reass_tmr()
sys_timeout: p msecs=536890160 handler= arg=p
stmf calling h=ip_reass_timer arg=p
tcpip: ip_reass_tmr()
sys_timeout: p msecs=536890160 handler= arg=p
stmf calling h=ip_reass_timer arg=p
tcpip: ip_reass_tmr()
sys_timeout: p msecs=536890160 handler= arg=p
stmf calling h=arp_timer arg=p
tcpip: etharp_tmr()
etharp_timer
sys_timeout: p msecs=536890140 handler= arg=p
stmf calling h=ip_reass_timer arg=p
tcpip: ip_reass_tmr()
sys_timeout: p msecs=536890160 handler= arg=p
stmf calling h=ip_reass_timer arg=p
tcpip: ip_reass_tmr()
sys_timeout: p msecs=536890160 handler= arg=p
stmf calling h=ip_reass_timer arg=p
tcpip: ip_reass_tmr()
sys_timeout: p msecs=536890160 handler= arg=p
stmf calling h=ip_reass_timer arg=p
tcpip: ip_reass_tmr()
sys_timeout: p msecs=536890160 handler= arg=p
pbuf_alloc(length=92)
pbuf_alloc: allocated pbuf p
pbuf_alloc(length=92) == p
tcpip_thread: PACKET p
ethernet_input: dest:FF:FF:FF:FF:FF:FF, src:90:FB:A6:85:92:11, type:800
pbuf_header: old p new p (536899572)
ip_input: iphdr->dest 0xFFFFFEA9 netif->ip_addr 0x4301A8C0 (0xFFFEA9, 0x1A8C0, 0xFF000000)
ip_input: packet not for us.
pbuf_free(p)
pbuf_free: deallocating p
stmf calling h=ip_reass_timer arg=p
tcpip: ip_reass_tmr()
sys_timeout: p msecs=536890160 handler= arg=p
pbuf_alloc(length=92)
pbuf_alloc: allocated pbuf p
pbuf_alloc(length=92) == p
tcpip_thread: PACKET p
ethernet_input: dest:FF:FF:FF:FF:FF:FF, src:90:FB:A6:85:92:11, type:800
pbuf_header: old p new p (536899572)
ip_input: iphdr->dest 0xFFFFFEA9 netif->ip_addr 0x4301A8C0 (0xFFFEA9, 0x1A8C0, 0xFF000000)
ip_input: packet not for us.
pbuf_free(p)
pbuf_free: deallocating p
tcpip_thread: CALLBACK p
etharp_request: sending ARP request.
pbuf_alloc(length=42)
pbuf_alloc(length=42) == p
etharp_raw: sending raw ARP packet.
pbuf_free(p)
pbuf_free: deallocating p
stmf calling h=arp_timer arg=p
tcpip: etharp_tmr()
etharp_timer
sys_timeout: p msecs=536890140 handler= arg=p
stmf calling h=ip_reass_timer arg=p
tcpip: ip_reass_tmr()
sys_timeout: p msecs=536890160 handler= arg=p
pbuf_alloc(length=92)
pbuf_alloc: allocated pbuf p
pbuf_alloc(length=92) == p
tcpip_thread: PACKET p
ethernet_input: dest:FF:FF:FF:FF:FF:FF, src:90:FB:A6:85:92:11, type:800
pbuf_header: old p new p (536899572)
ip_input: iphdr->dest 0xFFFFFEA9 netif->ip_addr 0x4301A8C0 (0xFFFEA9, 0x1A8C0, 0xFF000000)
ip_input: packet not for us.
pbuf_free(p)
pbuf_free: deallocating p
pbuf_alloc(length=92)
pbuf_alloc: allocated pbuf p
pbuf_alloc(length=92) == p
tcpip_thread: PACKET p
ethernet_input: dest:FF:FF:FF:FF:FF:FF, src:90:FB:A6:85:92:11, type:800
pbuf_header: old p new p (536899572)
ip_input: iphdr->dest 0xFFFFFEA9 netif->ip_addr 0x4301A8C0 (0xFFFEA9, 0x1A8C0, 0xFF000000)
ip_input: packet not for us.
pbuf_free(p)
pbuf_free: deallocating p
stmf calling h=ip_reass_timer arg=p
tcpip: ip_reass_tmr()
sys_timeout: p msecs=536890160 handler= arg=p
pbuf_alloc(length=92)
pbuf_alloc: allocated pbuf p
pbuf_alloc(length=92) == p
tcpip_thread: PACKET p
ethernet_input: dest:FF:FF:FF:FF:FF:FF, src:90:FB:A6:85:92:11, type:800
pbuf_header: old p new p (536899572)
ip_input: iphdr->dest 0xFFFFFEA9 netif->ip_addr 0x4301A8C0 (0xFFFEA9, 0x1A8C0, 0xFF000000)
ip_input: packet not for us.
pbuf_free(p)
pbuf_free: deallocating p
stmf calling h=ip_reass_timer arg=p
tcpip: ip_reass_tmr()
sys_timeout: p msecs=536890160 handler= arg=p
stmf calling h=ip_reass_timer arg=p
tcpip: ip_reass_tmr()
sys_timeout: p msecs=536890160 handler= arg=p
stmf calling h=ip_reass_timer arg=p
tcpip: ip_reass_tmr()
sys_timeout: p msecs=536890160 handler= arg=p
stmf calling h=arp_timer arg=p
tcpip: etharp_tmr()
etharp_timer
sys_timeout: p msecs=536890140 handler= arg=p
stmf calling h=ip_reass_timer arg=p
tcpip: ip_reass_tmr()
sys_timeout: p msecs=536890160 handler= arg=p
stmf calling h=ip_reass_timer arg=p
tcpip: ip_reass_tmr()
sys_timeout: p msecs=536890160 handler= arg=p
First both LEDs blink (slowly), then when the board receives some packets ("packet not for us"), the green led is turned off and the orange is kept on.
For this to work I had also to place a print in the netconn_new_with_proto_and_callback() [api_lib.c] just at the begining of the function (you can see the name of the function being printed in the log above), otherwise I'll get a:
Code: Select all
Assertion "http_server: invalid conn" failed at line 98 in web/web.c
Any suggestion?
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: STM32 Ethernet Demo
I cannot help much with lwIP, it would be a good idea to try asking on their mailing list.
Giovanni
Giovanni
Re: STM32 Ethernet Demo
Some progress.
I was using wrong IP and netmask. Now, I can see the "Welcome to our lwIP HTTP server!" webpage. However, this is only possible after refreshing the webpage a few times. After the connection is established it's refreshed fast but if I keep it idle for some (tens of) senconds and then try to refresh again I will have the same behaviour.
Another "gotcha": the external crystal that feeds the ETH_RMII_REF_CLK is NOT assembled in the STM32 P107 revC board (unlike the STM32 E407 which uses the same PHY chip and crystal). So I'm wondering in the first place why I was able to load the webpage on my browser and then if the issue described above is related with the crystal not being present.
Any idea?
I already asked in the Olimex foruns why the crystal was not assembled and will keep this topic updated about any progress.
I was using wrong IP and netmask. Now, I can see the "Welcome to our lwIP HTTP server!" webpage. However, this is only possible after refreshing the webpage a few times. After the connection is established it's refreshed fast but if I keep it idle for some (tens of) senconds and then try to refresh again I will have the same behaviour.
Another "gotcha": the external crystal that feeds the ETH_RMII_REF_CLK is NOT assembled in the STM32 P107 revC board (unlike the STM32 E407 which uses the same PHY chip and crystal). So I'm wondering in the first place why I was able to load the webpage on my browser and then if the issue described above is related with the crystal not being present.
Any idea?
I already asked in the Olimex foruns why the crystal was not assembled and will keep this topic updated about any progress.
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: STM32 Ethernet Demo
Hi,
If I remember well the PHI clock is driven by the MCO pin of the MCU.
Giovanni
If I remember well the PHI clock is driven by the MCO pin of the MCU.
Giovanni
Re: STM32 Ethernet Demo
Hi,
That's right. PHY clock is being driven by MCO and there's actually a 50MHz signal on that line.
I'm using a Rigol DS1052E oscilloscope which has 50MHz bandwidth (without hacks ) but it can measure the 50MHz frequency. One thing I noticed is that there's significant jitter, don't know if that's due a limitation of the oscilloscpe and/or if it affects the PHY.
Some additional details:
My knowledge about networks is very limited (IPs, netmasks, dhcp, arp, etc)
A screenshot of "ipconfig": http://s27.postimg.org/w1qrbwo6b/ethernet.png (it's in portuguese but I think it's easy to identify/read the most important fields)
On my previous post I was using:
IP Adress: 169.254.232.150
Netmask: 255.255.0.0
Gateway: 192.168.1.255
But connection fails frequently (please see the description on my last post).
Google tells me 169.254.x.x IPs are "not good". However, if I change the addresses to:
IP Address: 192.168.1.82
Netmask: 255.255.255.0
I can't reach the HTTP server from my web browser.
I'm connecting the board to my desktop's ethernet port. My internet access comes from WiFi, not from Ethernet (I don't know if that's important) and Im using a Sitecom wireless adapter on my desktop which connects to the router/switch.
Any suggestions?
That's right. PHY clock is being driven by MCO and there's actually a 50MHz signal on that line.
I'm using a Rigol DS1052E oscilloscope which has 50MHz bandwidth (without hacks ) but it can measure the 50MHz frequency. One thing I noticed is that there's significant jitter, don't know if that's due a limitation of the oscilloscpe and/or if it affects the PHY.
Some additional details:
My knowledge about networks is very limited (IPs, netmasks, dhcp, arp, etc)
A screenshot of "ipconfig": http://s27.postimg.org/w1qrbwo6b/ethernet.png (it's in portuguese but I think it's easy to identify/read the most important fields)
On my previous post I was using:
IP Adress: 169.254.232.150
Netmask: 255.255.0.0
Gateway: 192.168.1.255
But connection fails frequently (please see the description on my last post).
Google tells me 169.254.x.x IPs are "not good". However, if I change the addresses to:
IP Address: 192.168.1.82
Netmask: 255.255.255.0
I can't reach the HTTP server from my web browser.
I'm connecting the board to my desktop's ethernet port. My internet access comes from WiFi, not from Ethernet (I don't know if that's important) and Im using a Sitecom wireless adapter on my desktop which connects to the router/switch.
Any suggestions?
Re: STM32 Ethernet Demo
Finally, its working without connection problems. In fact, it is unrelated with ChibiOS and lwIP.
After manually defining a static IP for my ethernet adapter so it uses a 192.168.1.x address (instead of 169.254.x.x), as described here: http://portforward.com/networking/static-win7.htm
Im also using IP of that type on the board and everything works as expected.
Now, another "issue", probably unrelated with ChibiOS or lwIP again but any help would be very appreciated.
When I connect the board directly to my router (instead of my desktop + Windows) the RJ45 leds keep blinking, meaning the LINK is DOWN.
Any idea why this happens? Is is supposed to work directly connected to the router?
After manually defining a static IP for my ethernet adapter so it uses a 192.168.1.x address (instead of 169.254.x.x), as described here: http://portforward.com/networking/static-win7.htm
Im also using IP of that type on the board and everything works as expected.
Now, another "issue", probably unrelated with ChibiOS or lwIP again but any help would be very appreciated.
When I connect the board directly to my router (instead of my desktop + Windows) the RJ45 leds keep blinking, meaning the LINK is DOWN.
Any idea why this happens? Is is supposed to work directly connected to the router?
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: STM32 Ethernet Demo
It should work (it is how I attach it when I test).
Are all IPs in the same netmask range? it could also be a cable problem if you router isn't capable of auto-switch.
Giovanni
Are all IPs in the same netmask range? it could also be a cable problem if you router isn't capable of auto-switch.
Giovanni
Return to “Development and Feedback”
Who is online
Users browsing this forum: No registered users and 47 guests