Help with Zilog ZDS II: need debugging tips

Hi to everybody and thanks for your time and effort.

I already posted to the Zilog support, but they are not answering me.
And I think that if anybody would ever post a reply to this thread it
could possibly be useful to somebody else too.

I'm developing a software with RZK and ZTP (both version 2.1.0) with
ZDS II version 4.11 for a Zilog eZ80 processor. I'm facing failures
during code execution (reboot/cpu hang).

I would like to know If you could give me some hints on how to debug
this kind of errors.
I wasn't able to use the call stack debug window (it always shows
"Call stack data unavailable") and I'm not even sure where to put the
breakpoints, anyway.
Another issue I'm facing is the incapacity to know the state of each
thread currently running (ex. the function where a thread stopped
waiting for an event) - maybe a fault of mine.

I'm trying to manually insert canaries to investigate buffer overflows
and putting serial prints at the entry and exit points of every
function.

I would be glad if you could suggest me any useful tecnique to debug
my problem.

Any help is greatly appreciated.

Giulio Mazzoleni

Since nobody is answering (I know is a too vague question) I'll do by
myself, just to make clear what kind of help I would need.

1. SERIAL PRINTS
The most basic thing I've done is put a serial print of the function
I'm in just to realize what is happening. This is particularly useful
when I'm debugging threads that would overlap execution. One is done
at the beginning of each function and one at the end.

2. CANARIES
At the entry point of every function I've put a CANARY_BEGIN and at
the exit point a CANARY_END
They are defined as follows:

#define		CANARY_VALUE	{ 0x73, 0x55, 0x69 }

#define		CANARY_BEGIN	char canary[3] = CANARY_VALUE;
#define		CANARY_END		canary_check (canary);

The function canary_check is:

void canary_check(char *canary)
{
	char canary_tmp[3] = CANARY_VALUE;

	if (strncmp(canary, canary_tmp, sizeof(canary_tmp)))
		debug_print("Buffer overflow");
}

In this way I can realize if I've made any mistake in my coding and
suffering from buffer overflow.

3. STACK
Since in RZK stack size should be known in advance I've allocated N
consecutive memory areas to be used as thread stack space for each of
the N threads to be monitored (I had to use the RZKCreateThread
function).
This space should be enough to contain the variables and return values
of the longest function call path a thread could do, otherwise stack
boundaries can easily be crossed.
Since each function was already calling the CANARY_END function I've
adeed another check to detect boundary cross.
For each thread I've saved the start address of it own stack space. In
the canary_check function I compare the canary_temp address with the
thread stack start address. If the former is smaller than the latter
it means we have crossed boundaries and are writing onto another
thread stack space.
The modified function follows:

void canary_check(char *canary)
{
	char canary_tmp[3] = CANARY_VALUE;
	RZK_THREADHANDLE_t tp = RZKGetCurrentThread();
	int i, overflow = 0;

	if (strncmp(canary, canary_tmp, sizeof(canary_tmp)))
		overflow = 1; // crossed buffer boundaries

	for (i=0; i<NUM_THREADS && !overflow; ++i)
		if (tp == g_threadStackHandle[i] && canary_tmp < g_threadStack[i])
			overflow = 1; // crossed thread stack boundaries

	if (overflow)
		debug_print("Buffer overflow");
}

I would need other tips to debug my problem.

If I place a breakpoint at the beginning of main I can detect a
reboot, but I'm not able to see what really happened because memory
has already been cleared.
I'm only left with a bunch of serial prints that I don't know how much
I can trust.

Or could you please give me some hints on the most common causes of
reboots?

I heard rumors about printf not being thread safe, but I think it has
already been fixed.

I'm not considering a RESET pin problem, because other software is
running well, or at least is not exhibiting the problem.

What is driving me crazy is the unpredictability of the reboots.
Sometimes they happen after a few minutes, some others after many
hours (> 24).
I'm letting a browser issuing web request in an infinite loop.

It seems to me that the problem is getting less frequent since I made
the thread stack size bigger (from 4096 to 8192 bytes). But I'm not
even sure about that.

Many thanks for your time and patience.

Giulio Mazzoleni