The tests with the CW1200 were first conducted with the ones included in the CW1200 package, so 12 inches.
The ones I had with the CWLite are shorter, like 3-4 inches. The CWLite tests were ran with this smaller one.
Hi, Whilibarj!
I have experience in success Vcc glitch for CW1200 with STM32F3. For success result you must to know next:
- use no long coax cable (it must be 15 cm or less);
- in glitch_infinte() setup scope.glitch.repeat near 15-20 numbers;
- the value scope.glitch.ext_offset not really matter it is enough 2180 for glitch_infinte()
For more effective pulse parameters searching do next:
- Connect oscilloscope to the UART_TX pin and seek the crashing of STM. It will seems like voltage falling.
- Set the pulse scope.glitch.width very high. If you see crashing, it mean that the scope.glitch.width is very high. Its right way.
- Fix the scope.glitch.offset parameter (value is not matter on this step) and start reducing the scope.glitch.width by stepping (step of scope.glitch.width and scope.glitch.offset in CW is multiple to 0.4) while the STM is not stopping crash.
- When you finding the boarder of crashing and normal working, fix the scope.glitch.width and start sweeping by the scope.glitch.offset in range (-49, 49).
- If you steel not find the glitch keep try to sweep in small range by scope.glitch.width and repeate 4th step.
The all of this you must to do because all of glitch-attacks is working by the boarder of crashing/normalworking of core the STM.
Remember that the success of glitch is random and it near to 1 - 5%. It means that the you have repeat attack for each parameter (width and offset) not less than 100 times.
You can find more information in previous branch Help needed with Tutorial A3 VCC Glitching XMEGA Target
Have luck.
Regards,
Nik.
1 Like
The two significant differences I see here are the length of the cable, and the repeat value (15-20 vs 9) when comparing with what @aross suggested before.
I know success rates should be low, but after more than 250k times, I had hopes for at least 1 reset! 
I will try to run these values over the weekend. Thanks for your input!
Ok. I’ve been running this for quite a while now. The good news is that I finally managed to get some resets. Still no success, but that’s progress. Right?
However, the results are bugging me again. Below is a chart of the results I got so far. You’ll notice that I stopped the sweeping around offset -25 because I wanted to finish within the current century… What bugs me? The resets I have seem to be totally dependent on the Offset rather than the Width of the glitch.
Somehow, I expected that, for example, the widest voltage drops would cause the chip to reset at pretty much anytime over its operation. Pretty much like if I simply unplugged the power supply. Instead, I got resets over a very narrow offset range, but all over the place in terms of width.
So yeah. Progress, but no success and still confusion.
Wondering if @aross managed to get something on his end. Guess we’ll find out after the holidays.
Hi, Whilibarj
Seem’s strange. What length of coax cable you use? I found that the length near 60 cm is very wourse (in complecte of CW1200). The deal start great when I changed this to 15 cm.
Did you try to find in positive range of width values?
Regards,
Nik.
I found a 15cm cable that I used to produce my last results. I did get some resets in the positive range of width values (check my graph above. horizontal axis is width, vertical is offset). I stopped because my sweep took way too long (this graph is 3 days of results!) and was confused by the apparent lack of impact of the width, and the apparent important impact of offset! I might have expected it for successful results, but for resets? I’m confused.
Also hoped @aross would have some results to share on his end.
Just in case someone has the same issue and ends up reading this thread. I revisited this topic after a few months, hoping that I might find something new, or that something might have changed a bit with the new release and new tutorial version.
Nothing. I just can’t find a way to glitch this damn loop on the stm32f3 target. I don’t even dare to try the password check or bootloader tutorials on this target!
Anyway, if someone with the same setup has been successful and would like to share details… Dead end so far.
In the new tutorials, we run the STM at a higher clock frequency, which seems to help things. Have you tried that?
Aex
True. I’ll rerun tests over the entire parameter space again. Should come back with an update within a few days 
Finally.
I was able to glitch the damn loop of tutorial fault 1_1. I needed an offset of -44.8 to get there.
I was also able to glitch the 1_2 one, but with totally different settings.
Unable to get anything out of 1_3.
Somehow surprised about 1_2 and 1_3 as the way the text is written, I assumed that just using the parameters from 1_1 should work as is, or close to it.