Unhandled interrupt in idle task with PTP trafic (UDP) and TCP/IP connection

[aroste]

Hi,

I come to you since I'm lost to figure out what the issue.

I have a board based on bsp K60F120M.

I had until now CW10.5 and MQX 4.0.1.

I created a new worskspace with CW10.6 and MQX 4.1.1.

With both I have the problem, but seems less with the new installation and only happening in the idle task.  (with MQX 4.0.1 I got it in the TCP/IP task)

So let's go with the most recent installation: (in debug mode now)

I have a communication task to communicate with a TCP connection, and I have some UPD connections for some PTP trafic.

I have a serial line I use for a local printf function @ 115200. (happened also with 9600)

I my software run without the TCP connection established it works,

OR if no PTP trafic and only the TCP connection it is ok.

With both I get un MQX_UNHANDLED_INTERRUPT 0x41 exception in the idle task now.  It happens after a moment, not directly after startup.  Can be 30-50min.  I checked that all tasks have enough stack usage, also the stack for interrupts.

Any idea or any proposals for how to test and find the source of the problem?

Thanks

BR

Stephan

[aroste]

Hi,

It seems I still have the problem.  Any idea about that ?

Any known issue?   I tried to put the new tcp files from MQX4.0.2.2 and it doens't help.

(I tried to put MQX 4.0.2 completely... it doesn't work at all after that..   )

BR

Stephan

[aroste · Accepted solution]

Thanks for all these replies. 

I can see the effience of the community. 

Anyway I fixed the problem.

Merry Christmas

[muthugounder]

Stephan,

How did you fix this problem? I have similar problem with Flex Timer application in MQX.

Regards

Muthukumar

[aroste]

Hi,

I had two problems, unhandled interrupt (1) and connection lost (2).

1. It was TCP and UDP buffer size.

2. It was some conflicts between task and OS, I guess, that interrupt the PHY access.  So If in my task I access to the PHY and the OS with higher priority want also to access to PHY then after that the response is not correct.  I added interrupt disable/enable for the sequence of read/write of the PHY in my tasks.

BR

-Stephan-

[aroste]

It seems working now.

I incremented the size of the TCP and UDP buffers and it seems to go better now.  I also succeeded to run the code in release mode, the RTC library doesn't like the optimization level 4 in release mode.  I changed it to '1'. 

I still have the issue that after a moment the TCPIP connection get a timeout, even if a running time at 1/10s is sending, so I have to reconnect.  If no UDP trafic then the connection is not lost. I have to find out that.

Stephan

[Martin_]

Hi Stephan, you have to find out, which exception is this, by looking into xPSR core register. It might be hard fault.

Once you know the exception number, you can hook your exception handler into the vector table. You will find vector table in the vector.c source file in the BSP library. By default, isr is configured to DEFAULT_VECTOR, which is the _int_kernel_isr() function of the MQX dispatcher. So I usually put my own function, like void HardFault_Handler(void), to vector table offset 0x0c.

Inside my_kernel_isr(), you would typically want to see the interrupt stack frame, CPU register content at the time of exception. As you are in CodeWarrior GCC, you can look on the link below:

http://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html

and use directly the HardFault_Handler - just remove the static keyword, as you need the HardFault_Handler to be global, as it is referenced from vectors.c and it will be implemented in your application, main.c, for example.

Now, put breakpoint to this HardFault_Handler() and see the registers read by prvGetRegistersFromStack(). Typically at most interest would by "lr" and "pc". For example, "lr" would have an address of an instruction that a return from a function call would return to.

By looking into the .map file or using you debugger, you now know, which function has been executed by the CPU when exception occured.

By this you only find, which function causes the problem. Next, you will have to think why this occurs, and give more application specific debugging effort to find the root cause.

[aroste]

hi,

I tried few tricks but all this seems quite complicated. In the meantime I tried to move and get somethings with CW10.6 and MQX4.1.1.  I succeeded in porting and get a debug version working, but with still the same behavior.  And I finally succeeded by creating a hex-file.. that I cannot download using tftp... 

Now on this topic, I wanted to try a Release version to check the behavior..  And ho surprise, it's worst.  I can event not get some UDP packet. 

I have the following bounded socket on UDP for PTP:

- port 319 (SYNC messages, delay request)

- port 320 (delay response)

In release mode it seems it doesn't get the port 320. I checked with CW by attaching the debugger and my sockets are correctly installed.    Why now in release it doesn't work ?

More detailed  issue:

I have a TCPIP connection and the PTP UDP and 1 UDP output to send a running time. So I cannot get the 320 but it seems I get the 319.

Now if from a command coming from the TCPIP I activate only once an output running time on an another  UDP it stops also the 320 that was receiving until now.

Any idea? 

My TCPIP connections, running time on output are working the same in debug or release.  But not the PTP UDP.

Thanks

BR

Stephan