Hi Dimiter, ----- Original Message ----- From: "Dimiter Popoff" <dp@xxxxxxxxxxx> > I can say I have narrowed things down - yet I could > not catch the access which fails. Putting a breakpoint within a section of > say 20 opcodes prior to a certain location makes the return > address on the stack correct (a breakpoint does an illegal opcode > exception, tons of processing/memory i/o, possibly cache > flushes etc.). Put it below a certain opcode - no opcode doing > anything of interest - and the stacked return address is bad... Seems like you are willing to spend time and are knowledgeable. And it seems like the CPU is still functional after the bad address event, right? If that's the case, how about dumping the stack to see it was correct on the stack? bad in the cache? how about force cache flush/fetch, etc. Can you stop several hundred opcode before and then run? Will it fail with bad address too? If so, may be set a data breakpoint on write the to stack address and see if the write was successful when reading back? How does the bad return address differs from expected? bit error? Completely bad? Is the stack pointer valid? Just some random thoughts:) Best Regards, Alfred Lee Momentum Data Systems Inc. www.mds.com ------------------------------------------------------------------ To unsubscribe from si-list: si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field or to administer your membership from a web page, go to: //www.freelists.org/webpage/si-list For help: si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field List technical documents are available at: http://www.si-list.net List archives are viewable at: //www.freelists.org/archives/si-list Old (prior to June 6, 2001) list archives are viewable at: http://www.qsl.net/wb6tpu