How to gain insight into the Scheduler

[jchan]

Hi,

I am using Salvo for ARM 4.2.2 and a new user.

My question is how to get to know where the code is in each task. Instead of sticking bunch of printf statements, may be I can get some clue from the scheduler.

For example, let say I have 2 tasks.

TaskA()
Waiting for signal A1
do something
Waiting for signal A2
do something
Waiting for signal A3
do something.

TaskB()
Waiting for signal B1
do something
Waiting for signal B2
do something

If I have a bug after received signal A2, and stuck after that. Signal A1 will not be handled. How do I know the code stuck after the signal A2?

Thanks.

Joseph

[aek]

We do not currently offer an IDE plugin for Salvo ... so, one has to dig a liitle deeper to see where execution has been suspended within a task.

The place to look is in Salvo's global objects, specifically, in the task control block (OStcbArea[]). In each element of that array, you will see a tFP (task function pointer) record, and that is the actual PC that the task will resume execution at. Note that it may be hard to correlate said tFP against an actual line of C -- it's easier to find the assembly-language instruction that it maps to.

So, by keeping a watch window open that displays the task control blocks and tFPs of interest, you can see the address where a task was suspended / will resume.

[jchan]

I got into this situation that when the code signal a SEM, the SEM counter is going up, and no error is returned. However, the task which is waiting for the signal is not executing. I run the OSRep() to look at the address when the task (Task 6 below) will go, it is sitting right after the WaitforSignal. The Sem (Signal 10 below) counter value is incrementing. Below is the capture of the report.

I tried to recover using OSTrySem() or OSCreateSem, hoping to clear the count, but it didn't make the task to respond to the new signal.

I can peek at OStcbArea{] using the IAR IDE. Can you give me some clue where to look, so that I can find out which area I trashed or find a way to recover?

Thanks.



Salvo 4.0.2 Ticks: 1311314
EligQ:
DelayQ: t11 Total delay: 5 ticks
task stat prio addr t-> e-> d-> delay
3 wait 10 00004b1b . . t11 2293
4 wait 7 00002887 . . . 9925
5 wait 8 000001cf . . . 1007
6 wait 8 0000657f . . . 9943
8* elig 7 00002037 n/a
9 wait 7 0000236b . . . 1001
10 wait 7 00004e07 . . . 9926
11 dlyd 8 0000616f . . 5
12 wait 8 0000018d . . t11 1051724
13 wait 7 000002a7 . . . 1012

evnt type t-> value
1 dstr
2 dstr
3 Sem t 3 0
4 BSem t 5 0
5 Sem . 100
6 BSem t 9 0
7 Msg . 00000000
8 Sem t10 0
9 BSem . 1
10 Sem . 7
11 BSem t 4 0
12 BSem t12 0
13 BSem t13 0
14 dstr
15 dstr
16 dstr
17 dstr
18 dstr
19 dstr
20 dstr

[jchan]

One more piece of info...

From the Watch, OStcbArea[6].status.value = 0. The other active tasks have non-zero value.

[jchan]

Correction: I should be looking at index 5 for task 6. Index 6 is not used.

[jchan]

Trace it in a little more, when it is in this situation, the OSSignalSem() calls in Salvosem.c, the following segment of code, ecbP->tcbP keeps getting 0, therefore, OSInsSigQ() is skipped. Don't know what causes that to be "nulled".

(ecbP->event.sem)++;

u.tcbP = ecbP->tcbP;

if (u.tcbP)
{
OSInsSigQ(u.tcbP, ecbP);
}

[aek]

1. If your waiting task has a priority lower than any eligible task, it will not run until the higher-priority task is no longer eligible. You have a task at prio 7 -- what does it do?

2. Make sure that you are not using local (auto) variables in your tasks -- they are generally not allowed, and it's easy to forget that, with attendant side effects.

3. Make sure your OSTASK and OSEVENTS etc. are set properly in salvocfg.h.

4. Salvo's internals are not for the faint-of-hgeart ... but if you have Pro, you can trace your way through e.g. the signaling of an event. Errors returned can lead to insight into a problem. No errors return indicates -- in my experience -- that the user has made a runtime error (e.g., having a constantly-running eligible task that prevents a lower-priority task from ever running), which must be addressed by changes to the program (e.g. by elevating a task's priority).

5. Event control blocks are in OSecbArea[] by themselves, they are simpler than task control blocks.

When I originally saw the title, I felt that I should repeat the scheduler's golden rule: "The scheduler runs the most eligible task." While it may be counterintuitive, the scheduler is _not_ responsible e.g. for signaling of events ... that's because (in part) event signaling is an event, and the scheduler operates more like a polled process because it analyzes the various (priority and delay) queues and acts accordingly, but does so on a polled basis (e.g., as fast as it is called).

[jchan]

Hi aek,

I figured out what my problem was. I was porting my code which is a state machine to receive a serial packet to a Salvo task. I had a condition to detect bad packet checksum and "return". I forgot to remove this "return" which had broken the while (1) loop in the task, and the rest seems randomy failing. It had been difficult to reproduce because the bad checksum doesn't happen very often.

Thanks for the tips.

Joseph

[aek]

That would certainly do it ...

The reason of course is that the RTOS has to manage the "return the scheduler" bit that is in every OS_Xyz() ... not the same as a simple return-from-function.

Anyway, I'm glad you're now up and running.