Interpreting taskScan

[vsabino]

Hi,

I have a question with TaskScan.
I'm trying to debug a code that is failing, so I'm trying to use taskscan. on two different machins it behaves differently. one one PC it shows "+" signs to display more info, on the other PC, I don't get those "+" signs. Why is this?

In the one the shows the "+", I see a list of function calls, like a tree. How do I interpret that?

I'm sending a jpeg of the TaskScan output. They are all from the same instance, the one to the right is with the "+" contracted. The ones to the left are expansions for two different tasks.

Once somebody helps me understand this, I'll post a question on my failing code.

Thanks,
Victor

[tod]

The + sign lets you see the call stack from your application. If you scroll to the right you'll see the line numbers from the source code. So for your main task #50 you have a classSCB3Msgs with a method ProcessROET() that called Service::HandleIncoming(). Everything else is pretty much explained in the NetBurnerTools.pdf manual in Chapter 13. TaskScan.

I'm not sure why on one computer you couldn't see the + symbols. Did it show little dots or a blank area. Maybe it just couldn't show the icon. You could always try clicking where the + should be.

[vsabino]

Hi Tod,

I read the NetBurnertools.pdf, and it shows how to use it, but does not even mention or show the + signs. what is shown in their manual is what I see in one of the PCs. I clicked on the colored task icon, and nothing. I clicked on where the + is on the other PC, and nothing.

Anyway, on the PC that does show the + signs, this morning I was monitoring a hangup, and the + signs for the tasks I'm interested in are not showing! any idea why? (attached) the other thing is that now I get numbers (program counter)instead of the text that showed the code section.

So, the correct way to interpret the output of the tool ( when it has one), is hierarchically from the bottom up.

Thanks,
Victor

[tod]

When you get a trap with hex values you use the WinAddr2Line program to find the source code. I'm really not that conversant with TaskScan but you might be able to take that hex value and get a line number but I doubt if it will be that helpful. Also, I generally avoid any directory path with a space. This has historically caused problems. Rename any spaces in the path to your .elf file with an underscore and see if the line numbers show up. The difference between your two posts seems to be the location of the .ELF file.

You really need to describe the problem you are having, it might be that TaskScan isn't the best tool for debugging your problem. In fact I've never used it for debugging. Mostly between Unit tests and some well-placed cout (or printf if you must) statements I get all the debugging info I need. If the processor traps, the info displayed with WinAddr2Line can be invaluable. I've historically had problems with getting the debugger to attach so I've gotten out of the habit of using it, but if you're problem isn't timing related and the debugger starts with no problem it could be the fastest way to solve the problem.

[vsabino]

Hi Tod,

I was able to fix my problem, thanks to TaskScan. I was able to see that the code was not "hung up" but rather cycling through the main task in a place I wasn't expecting. The program counter value pointed to what section of the code it was stuck in. It was stuck in a while loop, caused by a bug I now corrected.

Mainly, what I wanted with this post was help on using TaskScan, which you helped me with, thanks!
I'll try and see what happens if I avoid the spaces in the path.

Still, I would like to know why it behaves differenly on two different PCs. Perhaps that is a question for the NetBurner folks.

As far as debugging, I never used the debugger, since I was told it does not work well if my code has interrupts.
I use WinAddr2Line, print statements, and toggle I/O lines to observe with the scope. That usually helps me with all my needs. Now I found TaskScan can be useful too!

Thanks again!
Victor

[tod]

Great, glad you got it working. I guess I'll have to give TaskScan more of a chance to help me debug. I'm assuming WinAddr2Line worked on those hex values.

[v8dave]

I've historically had problems with getting the debugger to attach so I've gotten out of the habit of using it, but if you're problem isn't timing related and the debugger starts with no problem it could be the fastest way to solve the problem.

Hi Tod,

Not sure if this is related, but I too had issues with getting the debugger to work and I could not get breakpoints to fire. It turned out that the simple addition of an OSTimeDly directly after the initialising of the debug connection solved this and ever since, all code I have written debugs without issue. Here is the code. At first I had this delay at 1 second but I kept lowering it and finally found that 1 worked fine. Must admit, I have not tried 0 here as 1 is only approx 50ms anyway. Without this delay, it just doesn't work for me.

#ifdef _DEBUG
iprintf( "Starting debugger\r\n" );
InitializeNetworkGDB_and_Wait();
OSTimeDly(1);
#endif

Regards
Dave...

[pbreed]

The debugger should work with interrupts IF the interrupt is mask able (IE not IRQ7).
I've even seen the debugger used to debug interrupt code...

Paul

[tod]

Thanks Dave i'll try that next time. I just recently tested it with a sample program and it worked except it didn't break on the _and_wait version of the call so maybe that delay would fix that. I've also noticed it helps to not use DHCP as that sometimes can muck up the timing but I usually adjust the timeout settings to be pretty large. Historically, it got to be such a problem that I just decided to stop putting bugs in my code.