Tasks & Switching from Sim to Target

[jpa]

More problems switching from the simulator to the 52233DEMO target...

I figured out that while the Visual C environment adds new files to the build, the Makefile used for GCC is NOT updated, so my tasks weren't getting compiled in.  (Funny, no linker errors that I could see).  Fixed that, and can see my task functions in the map file. 

Still, I can't get a simple task that prints a debug message to the serial port to work.  The original demo's debugging messages make it there just fine.  My task starts up fine and also prints to the serial port when running under the simulator. 

I'm sure it's something stupid, but would appreciate any pointers, please.

Task just calls fnDebugMsg("Init is running.\r\n"); and returns.
config is "MEDIUM_QUE", (DELAY_LIMIT) ((5*SEC) + (PHY_POWERUP_DELAY)), 0, UTASKER_STOP

John

[mark]

Hi John

If the debug output works in the simulator I would expect it to also work the same on the target.

However, when you add new files you will indeed need to do the same project changes in the embedded project (GCC make file in your case) - therefore check that you really have exactly the same files in both cases.

The other difference between simulator and target is the memory. The simulator has practically infinite memory but the target doesn't. Check carefully the use of memory form HEAP since the simulator may just allow this to be allocated but on the target it may just fail. Since different compilers are involved there can be differences in memory use - see MEM_FACTOR. The VS C++ compiler tends to use a bit more so the factor is set to try to adjust them correctly but it is not necessarily that accurate.

Regards

Mark

[jpa]

Since the debug terminal is working, I can go to stats and show memory use.  It says
"Free heap = 0x0ba4 from 0x5400"
"Unused stack = 0x16df"

Isn't this saying that I'm probably okay on memory? 

John

[mark]

Hi John

I think that I thought that no debug output was working. In this case the problem seems to be restricted to your task since the command line is otherwise OK. And yes, the memory looks to be no problem.

Therefore I would rather suggest that your task is not being started on the target. Or, it is being started too early - that is before the serial interface has been opened. If this were the case fnDebugMsg() will do nothing, but this also doesn't seem to be possible since you are starting it with a delay of 5s.

Is it possible that the task is being scheduled by an interrupt which is arriving on the target immediately? Then it would run early.

I would also allow your task to toggle an LED or something obvious since I don't expect that it is a problem with the fnDebugMsg() but rather that the task is not running as expected.

Regards

Mark

[jpa]

OUCH! 

In the make file, the line
INC = -I../../uTaskerV1.4
causes the GCC build to find uTaskerV1.4\TaskConfig.h  not the one in the current application directory and therefore not the same one that Visual C finds during the simulator build.  This explains why the GNU build wasn't barking at me when I didn't include the source files for my task in the make file...it also wasn't building the TaskConfig.h file that referred to the task, so there were no undefined references during the GNU build.  And during the simulator build, Visual C was finding the proper copies, building my source files, and happy as a clam.  Changing the behavior of the demo C files in my application directory still changed the behavior of the program as expected, so there weren't many other clues that it was finding the wrong .h files.

Changing the line to
INC = -I../
seems to fix everything.

Using
#if defined(_GNU)
#error "build was here"
#endif
finally illuminated the problem.

John