for my target chip, I need 4 IO lines (TX, RX, RST and bootloader_enable).
I looked into the ChipWhisperer capture v2 schematics and found that all 4 IO lines go through a bi-directional level shifter directly to the target.
However, in the ChipWhisperer capture software the only function IO4 pin can have is “HighZ”.
Is there a specific reason why the IO4 Pin can not be used ?
In my application, I need to toggle both the RST as well as the bootloader_enable line in a specific pattern.
There is no reason that isn’t enabled, but the current FPGA code does force that to be High-Z. I can try to get that into a new release for you which would enable the I/O 4 as an actual controllable pin.
I’ve added this, so should be a part of the next release. If you don’t want to wait:
I’ve attached a new version of the FPGA bitstream. To use this extract the file, then in the CW Firmware Config, set the FPGA mode to ‘DEBUG’, and point to this bitstream. The partial configuration data isn’t available yet so you can’t use some of the glitch functionality.
it is working.
Which glitching features do not work without partial reconfiguration and what would be required to get it working ?
With my setup, I’m planning to do both clock and voltage glitching (with a FET attached).
The “% glitch width” and “% glitch offset” don’t work. I’ve just got to run a very long script here (takes ~6 hours) to generate all the partial reconfiguration data. I’ll try to do that later today anyway, which would be part of the release but can send you an advanced copy if I don’t get that out.
I had planned on doing a full 0.9 release very soon anyway.
An updated firmware (zip file) has been pushed to the GIT, and is included here too. If you use the attached file just copy it to chipwhisperer\hardware\capture\chipwhisperer-rev2 and don’t unzip it. In the capture GUI switch back to ‘release’ mode, and if needed point to the location of the zip file.
wow, that was really quick.
I’m currently working on a script to get my target into the bootloader state I’m interested in so that I can start glitching from there.
As soon as the bootloader setup is complete, I’ll check out the glitching part with your new code and post the results here.
I just tried it.
With my script I can now always get into the right bootloader state. From there I would like to trigger a glitch based on the serial TX line using the Digital Pattern Trigger Module.
When setting the ‘Glitch Trigger’ to manual mode, I can see the generated glitch on the scope.
However, when setting it to “Ext Trigger:Single-Shot”, setting up the serial port configuration in the"Digital Pattern Trigger Module" and configuring a trigger character, it never triggers even though I send the trigger character multiple times to the device.
Any ideas ? Is this maybe related to the new firmware version ?
Was this working before? The ‘single-shot’ mode only arms once you start the capture, which isn’t always clear! Does it work in ‘continuous’ mode? It is possible there was a bug introduced in the new firmware as it did modify the routing code a little.
indeed I was not aware that the glitch triggering only works if capture is started.
I enabled capture now, set the timeout to a value large enough and if I send the trigger character to the device, it triggers both capture and the glitch as it it supposed to be.
Great! The documentation is lacking there - I did update the software without describing the difference between the ‘continuous’ and ‘single shot’. The latest documentation makes a reference to that now, but will make it more clear. The full 0.09 release includes the updated .zip file too which allows control of PGIO4.