Attachments are accessible only for community members.
Mar 09, 2016
03:58 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 09, 2016
03:58 AM
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.
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.
- Tags:
- IFX
31 Replies
Mar 11, 2016
12:17 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 11, 2016
12:17 AM
Hi,
Could you share your complete project? There might be a problem in the sys_now function.
Best regards,
Jesus
Could you share your complete project? There might be a problem in the sys_now function.
Best regards,
Jesus
Attachments are accessible only for community members.
Mar 11, 2016
12:28 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 11, 2016
12:28 AM
Attachments are accessible only for community members.
Mar 11, 2016
03:01 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 11, 2016
03:01 AM
#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:
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:
Apr 01, 2016
08:04 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 01, 2016
08:04 AM
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
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
Attachments are accessible only for community members.
Not applicable
Jun 08, 2016
04:15 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jun 08, 2016
04:15 AM
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.
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.
Not applicable
Jun 21, 2016
08:50 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jun 21, 2016
08:50 AM
push to top 🙂
Not applicable
Jun 30, 2016
10:44 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jun 30, 2016
10:44 PM
next push...
Jul 12, 2016
05:34 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 12, 2016
05:34 AM
next push . . . .
Not applicable
Aug 02, 2016
11:25 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 02, 2016
11:25 PM
Not solved yet..
Not applicable
Aug 17, 2016
01:53 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 17, 2016
01:53 AM
still waiting for a response..
Not applicable
Aug 17, 2016
11:14 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 17, 2016
11:14 PM
What happens when transmission stops? Do you get stuck in the Ethernet interrupt handler?
Not applicable
Aug 18, 2016
12:09 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 18, 2016
12:09 AM
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.
In debug mode, it goes done to the low level send routine, exits without an error, but no packet is send anymore.
Not applicable
Aug 18, 2016
12:35 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 18, 2016
12:35 AM
Is it still the case that transmission works if the Ethernet interrupt is permanently disabled, but stops after 1.4 million packets if enabled?
Not applicable
Aug 18, 2016
01:51 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 18, 2016
01:51 AM
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
- 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
Not applicable
Aug 18, 2016
02:54 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 18, 2016
02:54 AM
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.
Not applicable
Aug 18, 2016
03:36 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 18, 2016
03:36 AM
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
Could you tell me, what you cleared exactly? There are a lot of ethernet-specific counters.
Best regards,
Stfan
Aug 18, 2016
04:09 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 18, 2016
04:09 AM
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
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
Not applicable
Aug 18, 2016
04:13 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 18, 2016
04:13 AM
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.
Sep 15, 2016
11:46 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 15, 2016
11:46 PM
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
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
Not applicable
Feb 11, 2017
01:07 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 11, 2017
01:07 PM
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?
Feb 12, 2017
01:59 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 12, 2017
01:59 PM
Hi,
Could you share your program or a portion of it showing the issue?
Regards,
Jesus
Could you share your program or a portion of it showing the issue?
Regards,
Jesus
Not applicable
Feb 15, 2017
12:34 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 15, 2017
12:34 AM
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(ð_mac, (ETH_MAC_EVENT_NORMAL|ETH_MAC_EVENT_ABNORMAL) ); in the Interrupt handler of Ethernet?
#red, could you please comment on this? many thanks.
Not applicable
Feb 20, 2017
04:18 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 20, 2017
04:18 AM
push to top.
please refer to #6 post in this thread for the problem.
please refer to #6 post in this thread for the problem.
Feb 28, 2017
03:40 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 28, 2017
03:40 AM
Help to push to top. I am interested in the progress.
Not applicable
Mar 06, 2017
08:42 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 06, 2017
08:42 AM
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.
ST is able to provide a working software stack with a running lwip, which is even faster.
Mar 06, 2017
11:05 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 06, 2017
11:05 PM
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:
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
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
Not applicable
Mar 07, 2017
06:36 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 07, 2017
06:36 AM
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.
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.
Attachments are accessible only for community members.
Mar 07, 2017
09:43 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 07, 2017
09:43 AM
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
Regards,
Jesus
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
Not applicable
Mar 23, 2017
03:03 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 23, 2017
03:03 AM
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
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
Apr 04, 2017
01:51 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 04, 2017
01:51 AM
Hi shenj,
Please try in the XMC_ETH_MAC_Init() function to add the following line at the end of the function:
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
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
Not applicable
Apr 27, 2017
12:55 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 27, 2017
12:55 AM
In spite of the aforementioned improvements, it seemed that without a previous mentioned workaround of MAC, the ethernet interface can still stop.