2020-02-10 06:51 PM
@Amel NASRI, @ranran, @Piranha, @Harrold, @Pavel A.
V2 of my fixes and improvements to H7_FW V1.5.0/V1.6.0 Ethernet...
Changes include
Find full details and source in the attached zip. V1 was posted to another developer's question. Please post any questions about V2 here.
Solved! Go to Solution.
2020-04-06 01:02 AM
MEMP_NUM_TCPIP_MSG_INPKT is 8
There is additional task to handle PHY connection (from CubeH7 example)
void ethernet_link_thread( void const * argument )
{
ETH_MACConfigTypeDef MACConf;
int32_t PHYLinkState;
uint32_t linkchanged = 0, speed = 0, duplex =0;
struct netif *netif = (struct netif *) argument;
for(;;)
{
PHYLinkState = LAN8742_GetLinkState(&LAN8742);
if(netif_is_link_up(netif) && (PHYLinkState <= LAN8742_STATUS_LINK_DOWN))
{
HAL_ETH_Stop_IT(&heth);
netif_set_down(netif);
netif_set_link_down(netif);
}
else if(!netif_is_link_up(netif) && (PHYLinkState > LAN8742_STATUS_LINK_DOWN))
{
switch (PHYLinkState)
{
case LAN8742_STATUS_100MBITS_FULLDUPLEX:
duplex = ETH_FULLDUPLEX_MODE;
speed = ETH_SPEED_100M;
linkchanged = 1;
break;
case LAN8742_STATUS_100MBITS_HALFDUPLEX:
duplex = ETH_HALFDUPLEX_MODE;
speed = ETH_SPEED_100M;
linkchanged = 1;
break;
case LAN8742_STATUS_10MBITS_FULLDUPLEX:
duplex = ETH_FULLDUPLEX_MODE;
speed = ETH_SPEED_10M;
linkchanged = 1;
break;
case LAN8742_STATUS_10MBITS_HALFDUPLEX:
duplex = ETH_HALFDUPLEX_MODE;
speed = ETH_SPEED_10M;
linkchanged = 1;
break;
default:
break;
}
if(linkchanged)
{
/* Get MAC Config MAC */
HAL_ETH_GetMACConfig(&heth, &MACConf);
MACConf.DuplexMode = duplex;
MACConf.Speed = speed;
HAL_ETH_SetMACConfig(&heth, &MACConf);
HAL_ETH_Start_IT(&heth);
netif_set_up(netif);
netif_set_link_up(netif);
}
}
osDelay(100);
}
}
2020-04-06 01:24 AM
MEMP_NUM_TCPIP_MSG_INPKT = 8 isn't enough. This is possibly the only problem.
About HAL_ETH_Stop_IT... I did make some changes there. But still I'm unsure its stop/start is good as I'd only inspected it, didn't use HAL_ETH_Stop_IT and (sorry) only tested what I'd used. Are you sure you need to HAL_ETH_Stop_IT?
If you do, the first HAL_ETH_Start_IT is in low_level_init. Before your next HAL_ETH_Start_IT, make sure all the rx buffers (from the EthIfRxBuff pool) that had been previously held by the ETH driver were freed. Anyway, a problem with this isn't indicated and would surely manifest after a few 10s of link up/down.
2020-04-06 02:32 AM
How many MEMP_NUM_TCPIP_MSG_INPK do you suggest ?
I left HAL_ETH_Stop_IT from Cube example. If it is not necessery i will remove this.
Thanks for suggestion.
2020-04-06 02:39 AM
Please reply the reply so the conversations are delineated.
>How many MEMP_NUM_TCPIP_MSG_INPK
Double or triple.
>I left HAL_ETH_Stop_IT from Cube example.
You'll have to decide. My attitude is, everything ought have a reason and nothing ought have no reason. That's backed up by studies showing bugs are proportional to lines of code (doesn't mean remove comments).
2020-04-06 02:46 PM
Removing the HAL_ETH_Stop_IT resolved the problem.
But there is still messages "out of memory in pool TCP PCB"
2020-04-06 03:33 PM
>But there is still messages "out of memory in pool TCP PCB"
You needed to increase MEMP_NUM_TCPIP_MSG_INPK.
You need to increase MEMP_NUM_TCP_PCB too.
Review your pool dimensions per your circumstances.
For how-to, refer MEMP_NUM_TCPIP_MSG_INPK in my lwipopts.h.
>Removing the HAL_ETH_Stop_IT resolved the problem.
Please share how, why, a bug, where.
2020-04-07 01:27 PM
I use Nuleo-H743ZI2 evalboard and example LwIP_HTTP_Server_Netconn_RTOS from CubeH7 package.
All necessery files was replaced by your files from "Ethernet Driver Bug-Fixes" package, also all your settings from lwipopts.h and buffors size.
The original example from ST and your example work (main difference is in max speed - ST example achieve max 50mbps), but both have the same problems:
1) connect to netconn http server - ok, then connect to netconn tcp echo server - http server stop ack. Disconnect from echo server - http server start ack again.
2) connect to nectonn tcp echo server - ok, then connect to netconn udp echo server - haard fault on function netbuf_alloc (debug message memp_malloc: out of memory in pool NETBUF)
udpecho_thread(void *arg)
{
struct netconn *conn;
struct netbuf *buf, *tx_buf;
err_t err;
LWIP_UNUSED_ARG(arg);
conn = netconn_new(NETCONN_UDP);
netconn_bind(conn, IP_ADDR_ANY, 7);
LWIP_ERROR("udpecho: invalid conn", (conn != NULL), return;);
while (1) {
err = netconn_recv(conn, &buf);
if (err == ERR_OK) {
tx_buf = netbuf_new(); // <-- tx_buf is NULL
netbuf_alloc(tx_buf, buf->p->tot_len); // <----- crash here,
...
Also after only connect to http server, althoung it works, there are message :
memp_malloc: out of memory in pool TCP_PCB
memp_malloc: out of memory in pool NETCONN
Increasing MEMP_NUM_TCPIP_MSG_INPK and MEMP_NUM_TCP_PCB not helping.
I know there are many bugs possibilities, but all code is based on standard ST/lwip example without any modification except yours. I don't have much experience in lwip so i don't know where to start search problem.
2020-04-07 05:44 PM
> use Nuleo-H743ZI2 evalboard and example LwIP_HTTP_Server_Netconn_RTOS from CubeH7 package
> The original example from ST and your example work <snip> have the same problems
I'm guessing if ST's example fails the same without my changes, then the problems are with ST's example.
You've found its second problem: udpecho_thread doesn't check netbuf_new's error.
Does any other reader know about the first problem Adam's described?
Suggest search Community or start a new topic on it.
2020-04-08 03:19 AM
One problem resolved - default MEMP_NUM_NETBUF is 2. Increase to 8 resolve problem with system crash after using netbuf_new ().
But still Netconn http server stop working after TCP client connected.
Does Netconn thread safe ?
2020-04-08 06:04 AM
> default MEMP_NUM_NETBUF is 2. Increase to 8
You're on the right track.
>Does Netconn thread safe ?
It's off topic. I need to ask you to please find or create a new topic.
I'm not expert and I'd have read its code.