Zilog whinge

I need a whinge. Bloody Zilog's so-called ez80 software has been running 
me ragged for over a week. The code executes perfectly on the 
development kit, crashes on the target. Running off with the fairies, 
Program counter pointing anywhere.

MUST be a hardware fault. Spent ages writing evermore sophisticated 
tests to fault the RAM. No failures at all.

OK, spurious interrupts- had every input line attached to capacitor -on 
-a- string, board looks like a hedgehog. No change.

Glitches? 4 layer board with decouplers splattered everywhere, unlikely, 
in any case everything executes perfectly in MY test programs...

Start to suspect something in their code. Closed source, so not much to 
go on.. but did find that the devkit never gets beyond a certain point, 
the target does... after the first thread has been created. So the 
roaming PC was partly due to execution falling off the end of the 
routine, presumably with nowhere to go. Fixed that with an infinite wait 
loop.

Now reaches the loop, but doesn't start the thread. Where's the timer 
interrupt, can we break there... the timer interrupt is in the middle of 
an unallocated memory area. Hang on, I TOLD them that the RAM was 
0xC00000 to 0xC7FFFF, why is the interrupt table being plonked at 0xBF8000?

Stepped through the startup code, they load it in there. Why??? The 
devkit has RAM there, I don't, but why doesn't the linker sort all that 
out? They must have left an absolute address in there from when they 
bodged the thing in the first place.

Where do they tell you about this in the docs? You some kind of crazy 
optimist? Half the documentation refers to other documents that don't 
exist, either on the disk or on the Zilog website. the other half is 
just mykin' it ap.

OK whinge over, I'm off for a few days on the boat... if anyone doesn't 
know what narrowboating on English canals is like, just come and try it, 
it's like Tai Chi combined with Zen meditation interspersed with short 
burst of purposeful activity at locks or swing bridges, the day ends 
with liver busting pub blowouts..

Paul Burke

Paul Burke wrote:

> OK whinge over, I'm off for a few days on the boat... if anyone doesn't 
> know what narrowboating on English canals is like, just come and try it, 
> it's like Tai Chi combined with Zen meditation interspersed with short 
> burst of purposeful activity at locks or swing bridges, the day ends 
> with liver busting pub blowouts..

Damn, I'm glad there's some good news.  Hoist
a Courage Director's for all us bastards that
can't join you..

Paul Burke wrote:

> OK whinge over,

Great stuff, it was a fun read!  Take care of that liver!

"Paul Burke" <paul@scazon.com> wrote in message
news:3jq565Fr953iU1@individual.net...
> I need a whinge. Bloody Zilog's so-called ez80 software has been running
> me ragged for over a week. The code executes perfectly on the
> development kit, crashes on the target. Running off with the fairies,
> Program counter pointing anywhere.

> Snip

> Paul Burke

If it's any consolation it can be just as grim with the expensive toolsets
as well.

I've been using the IAR C toolset for AVR and selected the large (ie
standard) printf and scanf libraries.
I then had to waste an hour of trial and error to work out how much stack
they need (more than 128 bytes but less than 256, no heap).
It doesn't say in the documentation (printed or on line) and they never
phoned back when I rang them.

So cheer up, you're off on your hols and the Zilog tools cost about 5% of
what I paid IAR.

Michael Kellett

> I've been using the IAR C toolset for AVR and selected the large (ie
> standard) printf and scanf libraries.

Well, your mistake was evident within the first five words - IAR.
Expensive, dongled, casually supported and far from bug-free products.

"Paul Burke" <paul@scazon.com> wrote in message
news:3jq565Fr953iU1@individual.net...
> I need a whinge. Bloody Zilog's so-called ez80 software has been running
> me ragged for over a week. The code executes perfectly on the
> development kit, crashes on the target. Running off with the fairies,
> Program counter pointing anywhere.
>
> MUST be a hardware fault. Spent ages writing evermore sophisticated
> tests to fault the RAM. No failures at all.
>
> OK, spurious interrupts- had every input line attached to capacitor -on
> -a- string, board looks like a hedgehog. No change.
>
> Glitches? 4 layer board with decouplers splattered everywhere, unlikely,
> in any case everything executes perfectly in MY test programs...
>
> Start to suspect something in their code. Closed source, so not much to
> go on.. but did find that the devkit never gets beyond a certain point,
> the target does... after the first thread has been created. So the
> roaming PC was partly due to execution falling off the end of the
> routine, presumably with nowhere to go. Fixed that with an infinite wait
> loop.
>
> Now reaches the loop, but doesn't start the thread. Where's the timer
> interrupt, can we break there... the timer interrupt is in the middle of
> an unallocated memory area. Hang on, I TOLD them that the RAM was
> 0xC00000 to 0xC7FFFF, why is the interrupt table being plonked at
0xBF8000?
>
> Stepped through the startup code, they load it in there. Why??? The
> devkit has RAM there, I don't, but why doesn't the linker sort all that
> out? They must have left an absolute address in there from when they
> bodged the thing in the first place.
>
> Where do they tell you about this in the docs? You some kind of crazy
> optimist? Half the documentation refers to other documents that don't
> exist, either on the disk or on the Zilog website. the other half is
> just mykin' it ap.
>
> OK whinge over, I'm off for a few days on the boat... if anyone doesn't
> know what narrowboating on English canals is like, just come and try it,
> it's like Tai Chi combined with Zen meditation interspersed with short
> burst of purposeful activity at locks or swing bridges, the day ends
> with liver busting pub blowouts..
>
> Paul Burke

You might try asking in the yahoo group for the EZ80.  ZiLog has some
of their tech support staff answer questions in there.

Where is the internal RAM being mapped?  Are you putting it somewhere,
or is the initialization code handling it?  There may be some assumptions
made
by the initialization code.  I seem to recall that usually the internal RAM
is
located just below the external RAM.

I'll admit that some of the things that ZiLog does is a bit odd, and that it
does take a long time to adapt to it, and many library functions do not
quite
work as documented.

Hope this helps,

Mike Anton

Mike Anton wrote:

> Where is the internal RAM being mapped?  Are you putting it somewhere,
> or is the initialization code handling it?  There may be some assumptions
> made
> by the initialization code.  I seem to recall that usually the internal RAM
> is
> located just below the external RAM.

Back on the job now, thanks for the input. I've found that various 
structures are located at absolute addresses, all except the interrupt 
vector table that I've found so far are in the RAM as specified to the 
compiler. I make the chip selects match the compiler settings of course.

I expect I'll get it all working, then find that some other location is 
allocated outside my RAM area. This will be used only under certain 
circumstances, which are never encountered in testing, only when the 
first units are shipped (late) to irate customers...

Paul Burke