Troubleshooting tasks silently failing.

[ironsean]

Hello, I am using MQX 4.0.2, and CodeWarrior 10.5, and have been experiencing an unusual, and somewhat annoying problem while attempting to run or debug my code:

Tasks which install and use MFS sometimes inexplicably fail during runtime, or during debugging. They will even fail when stepping through code line by line, where once a write() call is reached the code is bumped to dispatch.S and that task no longer operates. There are no returns from the function, printf statements on the next line do not execute in debugging or normal operation, and no errors that I can see anywhere. I haven't yet checked kernal logs though.

What is weird about this is the code itself appears to work properly, but only fails if enough other things are happening:

Ex.

First, it only happened when I was attempting to install MFS, write, and read a test file. If the disk was not formatted, It would format the drive then fail unexpectedly on the write call. But if I reset the device, and the drive was now properly formatted, then it would write and read properly.

Ex2.

The MFS device and formatting is now handled in a separate task, and a new task is created to do the actual file reading and writing. If I run a pared down test version, which runs only the filesystem task and the main task, it can write the file properly. But if I run the full system with other tasks (relating to telnet, serial data processing, etc). the file writing will silently fail.

I have looked at the memory pools during execution, and they don't appear to overfill before or after failure. Any idea where else I should look to track down the source of this?

[soledad]

hi,

Please try using some of the MFS examples that you can find at the path: C:\Freescale\Freescale_MQX_4_0\mfs\examples.

Are you using a Freescale board?

Have a great day,
Regards
Sol
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[ironsean]

Hi Sol,

That you for the suggestion.

I used the examples as a basis for building the code I am using now. They seem to work totally and completely; except when too many components are in use in the same execution of the code. If the formatting is called, the write function will crash, but if the MFS_NOT_A_DOS_DISK error isn't thrown, and the if block doesn't need to execute to format then writes will work.

Same with the task that is only supposed to write data, If I don't have the telnet server running it works fine, but start the telnet task (which is totally independent as far as I can tell) and it stops executing for no reason.

We are using a K60DN512 chip on a custom board. There is also a K60 based tower board I can try and port the code to, but as I said all the code works in isolation so the hardware seems to all do what it's supposed to.

I'm just thinking there's a stack overflow or memory limitations, or a processor deadlock status that I don't know how to identify. Tracking lightweight memory pools shows no problems there.

Thanks,

Sean

[FM_tele]

Sean;

I'd like to know if you are using any Processor Expert Drivers, or LDDs, in your project.  I'm having a similar issue with the RTCS and want to determine any commonality.

Thanks,

FM

[ironsean]

Hello Felipe,

That is something I hadn't considered, but we do in fact have 3 LDDs included in the project's BSP: GPIO_LDD, TimerUnit_LDD, and SPIMaster_LDD.

I am not actually sure if or what they are being used for as they were set up by a previous developer, and they could be related previous iteration of the hardware. I opted for the MQX driver solutions when I could myself. I'll look into this a bit more and see if I can disable them from the BSP and test without them.

Sean

[FM_tele]

Sean;

I've been attempting to isolate my problem.  I've found that my system runs fine as long as I have not started the webserver task (and it has not started the script handler task).

We use the GPIO_LDD, DAC_LDD, ADC_LDD, and SPIMaster_LDD.  The ADC and SPIMaster use the interrupt interface while the other two use the poll method.

As a test I'm bypassing the task using the ADC_LDD and I'm converting my SPIMaster usage to polling.  I'm suspicious of a possible interrupt interleaving between the network stack and the SPIMaster LDD.

Do some investigation and see if this theory might be supported by your system setup.

FM--

[ironsean]

Hello Felipe,

After doing some testing today, I found out that in our system as well the HTTP Server task appears to be at fault. I'm not exactly sure why or how it is stopping regular functionality, but raising the priority of our file writing task above that of the HTTP server task eliminated the problem as far as I can tell. I still need to test and ensure the server functions properly with the lower task priority.

Sean

EDIT: For clarification, I raised the priority value, which lowered the priority of the file writing task.

[FM_tele]

Sean;

I've gone through and eliminated the use of interrupts by the LDD's and the problem persisted.  Now, I've reduced the WebTask and its script spawn to the lowest priority.  I have problems with the web pages timing out; but, the stack issue looks promising.

This isn't a solution, so hopefully someone from freescale can chime in, and let us know, if there is a task semaphore in the web server that can insure it doesn't corrupt the stack frames.  Even that's a work around -- so I'd like some input on what else might be possible.

Let me know your progress,

FM--

[ironsean]

Hi Felipe, I started a new discussion here which has some other ideas in in:File writing tasks silently failing on K60 and K64F | Freescale Community