> 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
Reply by Mike Anton●July 15, 20052005-07-15
"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
Reply by ●July 15, 20052005-07-15
> 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.
Reply by MK●July 15, 20052005-07-15
"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
Reply by JohnH●July 15, 20052005-07-15
Paul Burke wrote:
> OK whinge over,
Great stuff, it was a fun read! Take care of that liver!
Reply by Jim Stewart●July 15, 20052005-07-15
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..
Reply by Paul Burke●July 15, 20052005-07-15
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