ChipShouter - characterising a target

1

I have a target that I’d like to zap with the CS, and have developed a small piece of code which gives me a trigger and then compares a variable to zero:


  for (;;) {
  	
	 asm
	 {
		li r5, 0x01;			 /* Load value in test variable */
	 }
       
  	SET_LED3();			/* Trigger */
  	
  	for (i = 0; i < 1; i++)		/* Insert a small delay to be able to adjust trigger in time */
	{
		  while(cnt < 250)
		  {
		  	cnt++;
		  }
		  cnt = 0;
	}
  	
  	asm					/* We want to glitch the cmpi instruction */
  	{
  		cmpi r5, 0x00;		 
  		bne NOT_EQUAL;	
  		bl success;
  		se_b END;		 
  		NOT_EQUAL:
  		bl failure;
  		END:
  		nop;
  	}
  		
  	delay_100ms(1);		/* Keep trigger on for some time */
  	RESET_LED3();		/* Reset trigger */
  	delay_100ms(1);
  }

Using this code, I have very accurate trigger and have also captured traces of the compare instruction in cases of r5 being 1 and 0. The yellow trace below is the case of r5 being 0x01, and the red is r5 being equal to 0x00. Given that preparation, and using CW as a trigger, I am able to accurately aim at what I believe is the cmpi instruction (the first excursion on the yellow trace).

image
image1714×1112 18.8 KB

The problem is that I’ve spent days with not a single successful pulse, and am running out of ideas what to try. Tried all probes and all kinds of voltages, can see the target being reset sometimes, and sometimes a NMI handler is called, but the compare instruction is never affected.

Thanks

2

If you haven’t yet, try varying the XYZ position (though I’m guessing you’ve already thought of that based on this post: (Chip Shouter XYZ table)

Also, are you just modifying your code here to adjust r5 and recompiling? If so, you might be getting messed up by compiler optimizations. The compiler should be able to tell that r5 is never modified after you first set it, so it might just remove that compare/branch entirely. You’ll probably want to mark your asm as volatile to avoid this.

Alex

3

Tried all these things, and finally arrived to the conclusion that glitching the cmpi r5, 0x00 is beyond my abilities. It could be the case that the EMFI pulse flips too many bits to one in r5. Tried thousands of times with no success and finally moved on to another target in the code.

Before doing that I run a characterizing loop with incrementing a variable, as per the CS examples in github. The target is susceptible to glitches, but the loops increment a variable and compare it to a value. My reasoning is that the eddy currents induced by the impulse cause the value being tested to increase due to zeroes being flipped to ones.

I’ve read that it’s also possible flipping ones to zeroes, but if my theory is correct, it did not happen in my case; only got 0 to 1 flips.

Of course all of that is not proven and the reason for failing to glitch my target could be who knows what.