[SI-LIST] Re: OT: Overvoltage breakdown on 120 nm silicon?
- From: Dimiter Popoff <dp@xxxxxxxxxxx>
- To: <si-list@xxxxxxxxxxxxx>
- Date: Thu, 17 Feb 2011 21:05:13 +0200
Hi Alfred,
>And it seems like the CPU is still functional after the bad address
>event, right?
Yes, it is - often it just lands on a bad opcode because of using
that return address but I also verified it before it used it.
>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.
It is on the stack allright, bad. No coherency issues, it stays
there and gets flushed bad...
>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?
I did that - and depending on where I stop it the failure goes.
I have no practical way to set a data write breakpoint at the
moment, though.
>How does the bad return address differs from expected? bit error?
>Completely bad? Is the stack pointer valid?
It is totally off the mark, nothing to do with the original
value. But it does show some repeatability - and some correlation
to what I prefill the entire memory with prior to starting
the exercise... Not what I filled it with, though, no such
nice gifts :-).
Dimiter
>From: "alfred1520list" <alfred1520list@xxxxxxxxx>
>To: <si-list@xxxxxxxxxxxxx>,
> "Dimiter Popoff" <dp@xxxxxxxxxxx>
>Subject: Re: [SI-LIST] Re: OT: Overvoltage breakdown on 120 nm silicon?
>Date: Thu, 17 Feb 2011 10:47:08 -0800
>
>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
Other related posts:
