UCOS_ENTER_CRITICAL()

[chan_24]

Did you change the default Ticks per second?

Do you have any user written interrupts that are watching timers?

Some thing in your code overflowing at 2560000 seconds?

The default value of Ticks per second is not altered. #define TICKS_PER_SECOND (20)
I will check and let you know if we have any task written to watch the timers.

Paul,
I when I had set the value to 39 days and ran it for 14 hours the hardware rebooted. But initializing the TimeTick to 39 days and 14 hours has not rebooted the system even after 3 days. Would it be an overflow issue?

[tod]

What version of the NNDK are you using? The odds are good that memory got corrupted sometime earlier than the trap and the fact that the system is trapping on an OS call is a red herring. (It's possible there's a bug in the ucOS just not very likely or you wouldn't be the only one seeing it - unless you are on an unusual NNDK release. )

My experience says do a diff on the source code between the last two releases. Concentrate on the differences that affect memory including printf, sprintf, array access, pointer math etc. If you are writing derived classes, check your destructors and make sure all base destructors are marked virtual. If you're using dynamic memory make sure there are no leaks. If you're using new/delete and new[]/delete[] make sure the forms match. If the changes aren't massive you could consider posting a diff report on http://gist.github.com/ and put a link here.

Lint can help you find a lot of errors but it takes quite a bit of work to get it set up. If it's never been used on the code base you'll spend a lot of time filtering out messages. However, I've found that investing several days linting a code base often pays off in the long run.

[chan_24]

Tod,
Thanks for your reply. I think you are right that, the memory has got corrupted before the crash.
Do you know any command to check free space on RAM ?

[rnixon]

Seems like a thorough comparison of the changes for the new release vs. prior release would be a good place to start looking to narrow things down.

[tod]

Chandan,

First just in case you don't know, at the end of the build process the tools tell you how much RAM and FLASH you are using. I assume you want something to tell you dynamically what is going on with RAM. The only thing I have used is the spaceleft() function. Below is an example of a unit test I wrote that uses spaceleft() when I was experimenting with task deletion. As I recall you have to be careful when drawing conclusions from the results of spaceleft(). Memory might not get freed when you expect. Someone from NetBurner or someone with more experience on spaceleft() should feel free to chime in here. However, I think if you see the value constantly going down over a long period of time you can be pretty sure you have a memory leak.

Code: Select all

	TEST( VerifyNoMemoryLeaksForTaskStacksWhenTaskIsNotRunning)
	{
		OSTimeDly(2);
		DWORD ram_at_start = spaceleft();
		SomeConcreteTask* local_task = new SomeConcreteTask();
		DWORD ram_at_middle = spaceleft();
		local_task->SetTaskPriority(HTTP_PRIO - 1);
		local_task->Startup();
		OSTimeDly(2);
		local_task->_stayAlive = false;
		OSTimeDly(2);
		delete local_task; //destructor will run and since task is done it will clean up stack memory
		OSTimeDly(2);
		DWORD ram_at_end = spaceleft();
		cout << "start:" << ram_at_start << "  middle:" << ram_at_middle << "    end:" << ram_at_end << endl;
		CHECK(ram_at_start == ram_at_end);
	}

[pbreed]

85% of the time a crash in OSTime tick is a stack overflow problem.

PAul

[tod]

Paul's post reminded me of a copy/paste error I made once when modifying code. I reused the same stack between two tasks. NOT a good idea. Paul's post also makes me wonder about the other 15%

[chan_24]

Hi,

Thanks for your input. The problem was with the printf() function. Just not to reproduce the issue we commented out some of the prints we suspected on and it turned out to be correct. Also we checked that the stack was corrupted for the running task.

Thanks,
Chandan