[SI-LIST] Re: OT: Overvoltage breakdown on 120 nm silicon?

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:
http://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:     
                http://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: