XMC 4500 Ethernet failure

[User11214]

Hello everybody,

I'm using the XMC4500 Relax Kit and I have the following problem:

I send UDP packets to a client in a while loop. Now my problem: If i disable the IRQ for ETH0_0_IRQn, the xmc is sending infinetly. But if i don't disable it, the xmc end sending the packets after about 1427000. Also it happen, if i disable the IRQ before sending and enable the IRQ after sending packets.
i use the library -> lwip. i also use in the while loop the housekeeping function -> sys_check_timeouts().
i'm using DAVE4 in the latest version.

perhaps anybody can help me.

[jferreira]

Hi,

Could you share your complete project? There might be a problem in the sys_now function.

Best regards,
Jesus

[User11214]

hi,

here is the hole project...
i have seen, that i use the old xmclib... now i try to use the latest version.

[EDIT]
the hole udp packet has a lenght of 1500 bytes -> Data 1458 Bytes
[EDIT]

[User11214]

#newExperiences

i have updatet my project with the new xmclib. But now i have a bigger problem than before...

problem:
with the first incoming packet (ARP, PING, ...) , the xmc is hang up at the function ethernetif_input in ethernetif.c ...
then I thought, install a receivehandler for incomming packets... but again the same problem.

best regards
Christopher


without receivehandler:

[User11214]

until today, i have found no solution for the problem or the actual error in the program...

maybe someone can tell me if the fault lies with me or at infineon?
i agree with jesus, that the problem is at the sys_now function, but how i can fix it?

best regards Christopher

[#6]

Hi,
i have done some tests with the code and i got it running by inserting a re-initialization of the mac-core every 1.4 million packets.

This means, the problem is not within the lwip-stack but somewhere at the mac or the dma-controller.

Nevertheless, this is just an ugly workaround, but perhaps there is just somewhere a counter which has to be reset at regular intervals?

Please have a look at the attached project. Without the ethernet_reinit() line, the transmission stuck at about 1.4 million packets.

Best regards,
red

PS: The project is based on the latest lwip 2.0 beta version, but the problem is the same using the regular lwip from XMC-lib.

[#7]

push to top 🙂

[#8]

next push...

[User11214]

next push . . . .

[#10]

Not solved yet..

[#11]

still waiting for a response..

[#12]

What happens when transmission stops? Do you get stuck in the Ethernet interrupt handler?

[#13]

No, the execution does not stop and is running fine.
In debug mode, it goes done to the low level send routine, exits without an error, but no packet is send anymore.

[#14]

Is it still the case that transmission works if the Ethernet interrupt is permanently disabled, but stops after 1.4 million packets if enabled?

[#15]

Ok i think we have to investigate three cases:
- Interrupts enabled all the time: Transmission stucks after a while(last test: ~40000 packets) at the default handler, i think the problem here is a memory allocation problem between sending/receiving due to a inproper locking of the pbufs
- Interrupts disabled while sending: Transmission stucks at nearly 1.4million packages plus a few 1000, could be solved with a re-init of mac+dma
- Interrupts disabled all the time: In this case it seems to work flawlessly, but only in the case of broadcast transfers, otherwise the arp-packages are not handled correctly and there is no transmission at all.

Do you have similar problems?

Best regards,
Stefan

[#16]

No, I don't have similar problems. I once got stuck in the Ethernet ISR after sending similar amounts of data (2GB). That was caused by not clearing the counter interrupt. But that does not seems to be the problem here.

[#17]

This sounds very interesting, because the problem disappers with disabling the irqs. And as you said, it is the same amount of data.
Could you tell me, what you cleared exactly? There are a lot of ethernet-specific counters.

Best regards,
Stfan

[User10215]

Hi everybody,

indeed, as an ETH-MAC user this sounds interesting. Just read a little bit in the XMC4700 reference Manual v1.1. On page 15-105 there is this sentence:
"Before exiting the service request routine the application software must ensure all status bits are de asserted or spurious service requests will be generated".

Good to know!

Regards,
Niclas

[#19]

I disabled all MMC counter interrupts. This prevented the TX_OCTET_COUNT_GOOD_BAD counter from triggering the interrupt once reaching 2GB. But this doesn't seem to be what is happening to you.

[jferreira]

Hi,

Have a look to the new version of the ETH_MAC driver and lwIP implementation in DAVE 4.3.2.
Several fixes and improvements have been done.

Jesus

[#21]

jferreira wrote:
Hi,

Have a look to the new version of the ETH_MAC driver and lwIP implementation in DAVE 4.3.2.
Several fixes and improvements have been done.

Jesus

I got the same phenomenum. The program runs fine. After certain point. It stops to send out the packets.
Is there a solutation now?

[jferreira]

Hi,

Could you share your program or a portion of it showing the issue?

Regards,
Jesus

[#23]

jferreira wrote:
Hi,

Could you share your program or a portion of it showing the issue?

Regards,
Jesus

Hi Jesus, sorry but I canot share the code. But I donot think the code will that important. Bascially, I use socket to send out data packets. I have a counter in the HMI ( I can also see if packets are arriving at destination server). When a certain number is reached, my program (other part) runs continuously without problem.
At that moment, these is no connection anymore. I cannot ping the ip anymore. Apparently, It seems that there is no "error" happens. However, MAC is not sending out, nor receiving data.
red has a workaround.

Note that my phy is alive, if I plug in or pull out the network cable. I can see that Phy is working in establishing the link with router.

But I wish to detect this so that I can handle the problem at the time of occurrence.

should I try this? // XMC_ETH_MAC_ClearEventStatus(&eth_mac, (ETH_MAC_EVENT_NORMAL|ETH_MAC_EVENT_ABNORMAL) ); in the Interrupt handler of Ethernet?

#red, could you please comment on this? many thanks.

[#24]

push to top.
please refer to #6 post in this thread for the problem.

[User12775]

Help to push to top. I am interested in the progress.

[#26]

I think there is no progress.... I would suggest everybody to use a STM32F407 or similar.
ST is able to provide a working software stack with a running lwip, which is even faster.

[jferreira]

Hi shenj,

Sorry for the delayed answer being busy with many topics. I was able to reproduce your issue.
In my case the solution has been to increase the stack size of the Ethernet task.
In your main add the following code:

#define OS_ERROR_STACK_OVF      1
#define OS_ERROR_FIFO_OVF       2
#define OS_ERROR_MBX_OVF        3
#define OS_ERROR_TIMER_OVF      4

extern osThreadId svcThreadGetId(void);
volatile osThreadId err_task;

void os_error (uint32_t error_code)
{
  err_task = svcThreadGetId();

  __BKPT(0);
}

In my case after sometime it would hit the break point. The err_task will point to the task with stack overflow.

BTW: We are releasing a new version beginning next week that will increase the bandwidth, iPerf shows 92Mbits/s

Regards,
Jesus

[#28]

Hi Jesus, thanks a lot for your effort. Likewise, in my case a callback function is called if the task stack over flows, which would cause the firmware to stop. This is not my case, where the other part of firmware runs just ok. I happened to be in the debug mode, where I could see that the ethernet part run fine.
As red said, after certain number of packets are sent, the ethernet (service) stops. On one side, my suspect is that the Ethernet Interrupt is somehow disabled. On the other side, I have only activated the receive interrupt and clear its flag in the interrupt handler. Therefore, it is unlikely that the ethernet interrupt is deactivated because a flag from another service request is not cleared.

[jferreira]

Hi shenj,

Find attached my project, it runs for several days without issues.
Could you check if it matches your use case. In my case a UDP packet is sent every 10ms.

In the lwipopts.h I added

#define TCPIP_MBOX_SIZE             8
#define DEFAULT_TCP_RECVMBOX_SIZE   8
#define DEFAULT_UDP_RECVMBOX_SIZE   8
#define DEFAULT_RAW_RECVMBOX_SIZE   8
#define DEFAULT_ACCEPTMBOX_SIZE     8

Regards,
Jesus

[#30]

Hi Jesus,
thanks again for your effort. I checked again and my ISR has a priority higher than that of system tick as heart beat of FreeRTOS.
As said the task stack overflow is not my case. But I will check if Lwip heap is the issue or not.
Best,
shenj

[jferreira]

Hi shenj,

Please try in the XMC_ETH_MAC_Init() function to add the following line at the end of the function:

...
  /* Disable MMC interrupt events */
  eth_mac->regs->MMC_TRANSMIT_INTERRUPT_MASK = 0x03ffffffU;
  eth_mac->regs->MMC_RECEIVE_INTERRUPT_MASK = 0x03ffffffU;
  eth_mac->regs->MMC_IPC_RECEIVE_INTERRUPT_MASK = 0x3fff3fffU;
...

The MMC IPC Receive interrupts were all enable and we did not clear them in the interrupt handler. Therefore after sometime with the occurrence of any of the MMC IPC Receive events the IRQ will fire continuously.

regards,
Jesus

[#32]

In spite of the aforementioned improvements, it seemed that without a previous mentioned workaround of MAC, the ethernet interface can still stop.