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

Reply to
Paul Burke
Loading thread data ...

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

Reply to
Jim Stewart

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

Reply to
JohnH

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 to
MK

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

Reply to
larwe

0xBF8000?

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 to
Mike Anton

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 to
Paul Burke

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.