Hi,
I have been trying to get chipshouter and ballistic gel to work with my 3d printer (positioning device). I managed to get some fault injections in with 4mm probe while manually using chipshouter on random memory chip locations (both simple target and ballistic gel).
However, I cant get 1mm diode to work at all and when I mount chipshouter on my 3d printer and set the positioning system to some coordinates above the memory chip I cant induce fault injection no matter what i do even with 4mm probe.
I am using “raw_test_setup()” to fill the board with random data. I have tried various chipshouter configurations but none seem to work (I have used only basic pulse with different voltage, pulse width, pulse repeat and pulse deadtime). I have also tried various Z axis distances, including the probe almost touching the memory chip (1mm space between the board and the probe).
Am I doing something wrong?
It sounds like you have been able to manually glitch ballistic gel, but you’re not able to get successful glitches with your 3D printer? What was different when you did have successful glitches?
Nothing. the only thing that has changed is device trigger method. If I point it at the ballistic gel and manually press the button I can see faults being inserted after running raw_test_compare(). However if I use the same device setting and the same position but the trigger is done via cs.pulse = 1 I get no faults inserted.
Can you show me how you are programming the ChipShouter?
I can only upload it this way since I am new user
This is just for debugging purposes to see if it is working with the python api. In practice I am using genetic algorithm to search the parameter space to find the most suitable combination for fault injeciton - minimising bits changed
Ok - BTW in the future if you can copy/paste as text, you won’t have upload limitations, and it’s easier for us to look into.
What you have looks OK; I recommend you go back to first principles:
- Pick a tip and a target that you know you can manually glitch fairly easily (e.g. 4mm tip, CW322, lower right corner).
- Now change to Python API mode; you should be able to glitch from the API as follows:
cs.reset_config = 1
cs.armed = 1
cs.pulse = 1
…and then build from there.
I might have figured out what was wrong.
Commands:
cs.armed = True
cs.pulse = 1
doesn’t seem to work when they are executed without pause in-between them such as:
time.sleep(1)
My guess is that if you try to fire right after arming there is not enough time for the device to charge up and it either fires with low voltage or some internal mekanism stops it from executing the fire completely but it doesnt show up as error. After I added the sleep command in-between the commands it started generating device configurations which were producing faults.
Before requesting the sleep all the time I had this line set up:
while not device.ready_for_commands():
time.sleep(1)
but I guess the function flagged the device as ready even if it wasn’t charged.
Sorry for the confusion. If you refer to the CS API page, ready_for_commands()
indicates CS is “ready to communicate”, which is not the same as “ready to pulse”.
You can either use a fixed sleep time, or you can query cs.armed
:
cs.armed = 1
while not cs.armed:
print('arming...')
time.sleep(0.1)
print('armed!')
Is there a similar way to see if the device is still firing, so I don’t disarm it by accident? I am not sure if i can read cs.pulse == 1
.
No. But the length of a pulse (or series of pulses) that cs.pulse = 1
kicks off is something you know and control.
Thank you for you help so far! Do you have any tips on how to get the 1mm probe to work? Some sample chipshouter settings that might produce faults on ballistic gel. Because I had no luck with those probes so far.