“”"

spi_read_001.py

Very simple CW1200 SPI reader:

- Start HS2 clock

- Enable SPI

- Repeatedly issue 0x9F and read 3 bytes

- Log to logs/SPI.log (overwrite each run)

“”"

import os

import sys

import time

from datetime import datetime

CW_SRC = “/home/sen/WS_CW1200/chipwhisperer/software”

if os.path.isdir(CW_SRC) and CW_SRC not in sys.path:

sys.path.insert(0, CW_SRC)

import chipwhisperer as cw

from chipwhisperer.hardware.naeusb.fpga import FPGA

from chipwhisperer.hardware.naeusb.spi import SPI

LOG_PATH = “logs/SPI.log”

CLOCK_HZ = 50_000_000

SPI_HZ = 1_000_000

CMD = [0x9F]

READ_LEN = 3

def hexdump(buf):

return " ".join(f"{b:02X}" for b in buf)

def pick_cs(scope):

for name in ("tio1", "pdid", "tio2", "tio3", "tio4", "io1"):

    if hasattr(scope.io, name):

        return name

return None

def main():

os.makedirs(os.path.dirname(LOG_PATH), exist_ok=True)

with open(LOG_PATH, "w", encoding="utf-8") as log:

    log.write("timestamp,rx\\n")

    log.flush()



    scope = cw.scope()

    scope.clock.clkgen_freq = CLOCK_HZ

    time.sleep(0.2)

    try:

        scope.io.hs2 = "clkgen"

    except Exception:

        pass



    cs_attr = pick_cs(scope)

    cs_line = (scope.io, cs_attr) if cs_attr else None

    fpga = FPGA(scope.\_getNAEUSB())

    print(f"\[i\] FPGA programmed: {fpga.isFPGAProgrammed()}")

    print(f"\[i\] FPGA INITB: {fpga.INITBState()}")

    if not fpga.INITBState():

        print("\[!\] INITB low — FPGA not configured. SPI cannot start.")

        return



    spi = SPI(scope.\_getNAEUSB(), cs_line=cs_line, nrst_default="high")

    spi.enable(SPI_HZ)



    try:

        while True:

            tx = CMD + \[0x00\] \* READ_LEN

            rx = spi.transfer(tx)

            data = rx\[len(CMD):\] if rx else \[\]

            ts = datetime.now().strftime("%H:%M:%S.%f")\[:-3\]

            line = f"{ts},{hexdump(data)}"

            print(line)

            log.write(line + "\\n")

            log.flush()

            time.sleep(0.01)

    except KeyboardInterrupt:

        pass

    finally:

        try:

            spi.disable()

        except Exception:

            pass

        try:

            scope.dis()

        except Exception:

            pass

if _name_ == “_main_”:

main()

That’s not what the SPI class is meant for: it’s meant to actively drive a SPI interface.

If I’ve misunderstood, can you share more precisely what you are doing, i.e. the actual Python code which leads to the crash.

APIs used :

• cw.scope() — connect to CW1200
• scope.clock.clkgen_freq + scope.io.hs2 = “clkgen” — start HS2 clock
• SPI(scope._getNAEUSB(), cs_line=…) — SPI engine object
• spi.enable(speed) — enable SPI hardware
• spi.transfer(bytes) — read/write SPI
• FPGA(scope._getNAEUSB()).INITBState() — check FPGA config state

However, INITB is low.
My question is, is it even possible to use the dedicated DI, CS, SCK pins to read SPI data ? at 17 - 20MHz.

Thank you for that important insight. You’re absolutely right — my target uses an internal RC oscillator that’s not tied to any external clock, so I expect exactly the kind of drift you’re describing.

However, this is actually encouraging news for me. My current problem is much worse: I’m getting ~700 samples of jitter from Python bit-bang I2C, which makes even basic cross-correlation alignment fail completely. If the hardware bitbanger can reduce the I2C-side jitter to near zero, leaving only the target’s internal clock drift (which sounds like it would be in the range of tens of samples), that would be a huge improvement. Post-processing with fastdtw on traces that are “quite close” is a very different problem from trying to align traces that are 700 samples apart.

I’ll definitely look into fastdtw — thanks for the recommendation. In the meantime, I’m also experimenting with using a Raspberry Pi Pico as an external I2C master to eliminate the Python jitter while waiting for the bitbanger update.

I’ll keep an eye on the develop branch. Looking forward to it!

Thanks again!

This will obviously be target-dependent, but I’ll warn you that this may not solve all your trace synchronization problems, if your target’s internal clock is not tied to the I2C clock.

Here for example are a few power traces of the ATAES132A running an AES encryption. The traces are quite close, but not synchronized. Of course, synchronizing these traces in post-processing would likely be relatively easy. But in addition to static offsets, there can be jitter and wander, since our ADC clock is not locked to the target’s internal clock. I’ve used fastdtw in the past to deal with this with some success.

jpthibault:

Also, as it currently exists, scope.bitbanger doesn’t really work for I2C because it can’t do the starts and stops. However I’ve been working on adding functionality for that; it should be out hopefully next week.

Hi jpthibault,

That’s really exciting news about the I2C support for scope.bitbanger! I wanted to share some context on why this feature is so important for my work.

I’ve been running CPA (Correlation Power Analysis) on my I2C target using Python bit-banged I2C via TIO1/TIO2. The capture and tear-off setup is working great — I can reliably collect hundreds of power traces with the edge counter trigger on TIO4. However, the CPA results are not converging because of the timing jitter introduced by Python’s time.sleep() in the bit-bang loop.

Each I2C byte has roughly ~100µs of jitter, and over a full 7-byte command, the accumulated jitter reaches ~700µs — which is 700 samples at 1 MHz. This completely destroys the trace-to-trace alignment needed for correlation analysis. I tried cross-correlation alignment in post-processing, but the jitter is so large and inconsistent that the algorithm can’t find reliable reference points.

A hardware bitbanger with deterministic timing would eliminate this jitter entirely, making each trace perfectly aligned and the CPA viable. Based on published research on similar targets, as few as 100 well-aligned traces should be enough to recover the key.

I’m really looking forward to the I2C update — counting the hours! Is there anything I can do to help test an early build when it’s ready?

Thanks again for all your help throughout this project!

I didn’t realize that you were trying to connect to the J2 header: as the schematic shows, these connect to PB8/9.

There is no reason why UART2 wouldn’t work- it’s just not easy to access, and unfortunately it doesn’t look like you can route it to our J2 header.

# 1ms is plenty of idling time
target.clkusbautooff = True
target.clksleeptime = 1

This disables the target’s USB clock (used for communication) for 1ms after the “go” command has been sent, to reduce power trace noise.

The clock then comes back on approximately 1ms later (time is approximate because this is driven by Python), which for your clock settings would be 120K samples after the start.

I’m pretty sure this is what is happening: re-activating the USB clock creates a small power surge in the FPGA, and this is what you see.

Simply increase target.clksleeptime so that the USB clock doesn’t get turned back on during your capture.

Looking at this:

Thank you again for the answer.
Kris

scope.adc.offset = 0
scope.adc.samples = 100000
#measure multiple times to capture the full trace
trace = np.array([ ])
for j in range(3):
    #in last round capture less samples
    if(250000 < (j+1)*scope.adc.samples):
        scope.adc.samples = 250000 - j*scope.adc.samples

    ret = cw.capture_trace(scope, target, text_in, text_in, poll_done=True)
    trace = np.append(trace, ret.wave)
    scope.adc.offset += scope.adc.samples
scope.adc.offset = 0
scope.adc.samples = 100000

An the peak the zoomed in Peak is:

henrycase:

Is there a better/intended way to physically access arbitrary GPIO pins (like PA2/PA3) on the CW313 setup? Did I miss a header?

No. The schematic is here. We don’t break out all the pins; in general only what’s needed for our standard ChipWhisperer communication is broken out (although there are exceptions where we’ve added headers to the target board for additional signals).

That appears to be the case, though I’ve not used USART2 on these.

What does the “spike” look like when you zoom in?

Specifically, I acquire 100k samples per iteration and concatenate the traces. However, after approximately 130k samples, I consistently observe a significant negative spike (drop) in the signal. The exact location of this drop varies randomly within a range of roughly ±20k samples.

This behavior is illustrated in the attached figure.

When I run my own custom implementation instead of the AES example, the drop becomes even more pronounced

The errors desplaied by scope.errors are
sam_errors = False
sam_led_setting = Default
XADC errors = False
ADC errors = gain too low error,
extclk error = False
trace errors = False

The “gain too low” warning may be expected, as most of the captured trace corresponds to idle state, while the AES operation itself spans only ~100 samples. For my own implementation which takes more than 250k samples to finish the error does not occure.

Here are my settings:
scope.default_setup()
scope.adc.bits_per_sample = 12
scope.adc.offset = 0
scope.adc.basic_mode = “rising_edge”
scope.adc.samples = Samples
scope.clock.clkgen_freq = 10e6
scope.clock.clkgen_src = “extclk”
scope.clock.adc_mul = 12

target.vccint_set(1.0)
target.pll.pll_enable_set(True)
target.pll.pll_outenable_set(False, 0)
target.pll.pll_outenable_set(True, 1)
target.pll.pll_outenable_set(False, 2)

What could be causing this large negative spike in the trace when capturing extended sample windows? Is this related to the segmented capture method, clocking, or ADC behavior? Additionally, what steps can be taken to eliminate or stabilize this artifact?

I’m running a STM32F215RET6 on a CW308T target board connected to a CW313. My firmware uses two UARTs:

• USART1 (PA9/PA10) for SimpleSerial communication with the ChipWhisperer
• USART2 (PA2/PA3) for a second serial channel in my custom firmware

Since the CW313 doesn’t seem to have a labelled GPIO header that exposes PA2/PA3, I ended up soldering thin wires directly to pins 16 (PA2) and 17 (PA3) on the STM32F215 LQFP-64 package to connect a USB-UART adapter.

My questions:

1. Is there a better/intended way to physically access arbitrary GPIO pins (like PA2/PA3) on the CW313 setup? Did I miss a header?
2. Can you confirm that USART2 on the STM32F215RET6 (LQFP-64) is indeed on physical chip pins 16 (PA2/TX) and 17 (PA3/RX)?

Thanks!

1. On reset, the Boot ROM executes first - The CPU starts running code from ROM at 0x13000000

2. The Debug Access Port (DAP) is disabled - The MEM-AP (Memory Access Port) that allows debuggers to read/write memory is not accessible immediately after reset

3. Standard debug methods fail - Commands like reset halt don’t work because the debug interface isn’t ready

4. The chip appears “locked” - Even though SWD is physically connected, the debugger can’t control the CPU

This is intentional design by NXP - the Boot ROM must complete certain initializations before debug access is allowed . However, when the flash is blank or contains invalid firmware, the Boot ROM never reaches the point where it enables debug access.

Below is lpc55xx_unlock procedure to force-enable debug access by directly manipulating the Debug Mailbox (AP2).

# lpc55xx-unlock.cfg
proc lpc55xx_unlock { } {
    global _CHIPNAME
    
    echo "Starting LPC55S69 unlock sequence..."
    
    # AP2 is the Debug Mailbox (DM)
    set dm_ap 2
    
    # DM register offsets
    set DM_CSW 0x00
    set DM_REQUEST 0x04
    set DM_RETURN 0x08
    
    # DM command values
    set DM_CSW_RESYNCH_REQ_MASK 0x01
    set DM_CSW_CHIP_RESET_REQ_MASK 0x20
    set DM_START_DBG_SESSION 7
    
    # Step 1: Set RESYNCH_REQ and CHIP_RESET_REQ in DM.CSW
    echo "Step 1: Requesting chip reset via debug mailbox..."
    set cmd [expr {$DM_CSW_RESYNCH_REQ_MASK | $DM_CSW_CHIP_RESET_REQ_MASK}]
    $_CHIPNAME.dap apreg $dm_ap $DM_CSW $cmd
    sleep 200
    
    # Step 2: Verify CSW cleared (reset completed)
    set csw [$_CHIPNAME.dap apreg $dm_ap $DM_CSW]
    if {$csw != 0} {
        echo "Warning: DM.CSW not cleared after reset: $csw"
    }
    
    # Step 3: Write debug unlock request
    echo "Step 3: Sending debug unlock request..."
    $_CHIPNAME.dap apreg $dm_ap $DM_REQUEST $DM_START_DBG_SESSION
    sleep 100
    
    # Step 4: Read return status
    set status [$_CHIPNAME.dap apreg $dm_ap $DM_RETURN]
    set status_low [expr {$status & 0xFFFF}]
    if {$status_low == 0} {
        echo "Unlock successful!"
    } else {
        echo "Unlock returned error: 0x$status_low"
        return -error "Unlock failed"
    }
    
    # Step 5: Now examine the CPU
    echo "Examining CPU..."
    $_CHIPNAME.cpu arp_examine
}

# Execute the sequence
init
lpc55xx_unlock
halt

The steps this procedure does:

1. Write to DM_CSW with reset bits - Forces a chip reset without losing debug connection.

2. Check DM_CSW cleared - Verifies reset completed.

3. Write 7 to DM_REQUEST - Sends "start debug session" command to Boot ROM.

4. Read DM_RETURN - Checks if Boot ROM accepted the request (0 = success).

5. arp_examine - Re-examines CPU, now with full debug access.

Without lpc55xx_unlock I get:

bash-3.2$ ../src/openocd -f interface/jlink.cfg -c "transport select swd" -f target/lpc55xx.cfg
Open On-Chip Debugger 0.12.0+dev-02431-gd73afae35 (2026-03-19-15:48)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : J-Link V11 compiled Jan 30 2023 11:22:20
Info : Hardware version: 11.00
Info : VTarget = 3.303 V
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x6ba02477
Error: [lpc55xx.cpu] Could not find MEM-AP to control the core
Error: [lpc55xx.cpu] Examination failed
Warn : target lpc55xx.cpu examination failed
Info : [lpc55xx.cpu] starting gdb server on 3333
Info : Listening on port 3333 for gdb connections

With extra functionality:

bash-3.2$ ../src/openocd -f interface/jlink.cfg -c "transport select swd" -f target/lpc55xx.cfg -f lpc55xx-unlock.cfg
Open On-Chip Debugger 0.12.0+dev-02431-gd73afae35 (2026-03-19-15:48)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : J-Link V11 compiled Jan 30 2023 11:22:20
Info : Hardware version: 11.00
Info : VTarget = 3.305 V
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x6ba02477
Error: [lpc55xx.cpu] Could not find MEM-AP to control the core
Error: [lpc55xx.cpu] Examination failed
Warn : target lpc55xx.cpu examination failed
Info : [lpc55xx.cpu] starting gdb server on 3333
Info : Listening on port 3333 for gdb connections
Starting LPC55S69 unlock sequence...
Step 1: Requesting chip reset via debug mailbox...
Step 3: Sending debug unlock request...
Unlock successful!
Examining CPU...
Info : [lpc55xx.cpu] Cortex-M33 r0p3 processor detected
Info : [lpc55xx.cpu] target has 8 breakpoints, 4 watchpoints
Warn : [lpc55xx.cpu] target was in unknown state when halt was requested
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections

Finally, connect to the OpenOCD via telnet and write the flash by

flash write_image erase /path/to/firmware.elf

Also, as it currently exists, scope.bitbanger doesn’t really work for I2C because it can’t do the starts and stops. However I’ve been working on adding functionality for that; it should be out hopefully next week.

First of all, thank you so much for the tip about the new Hardware Bitbanger feature! I’ve successfully updated my environment and Husky firmware to the develop branch. This is exactly what I needed to eliminate the USB latency and jitter issues I was facing with my AT88SC25616C target.

I was reviewing the demo notebooks for SWD and 1-Wire, and I noticed that the bitbanger is configured to use the front panel pins (USERIO_D0, USERIO_D1, etc.).

My current custom breadboard is meticulously wired to the CW313 interposer using TIO1 (SDA) and TIO2 (SCL), with custom pull-ups and a solid ground plane to keep the noise floor as low as possible for the charge pump DPA.

To avoid running long jumper wires from the Husky’s front panel to my board (which would introduce noise), I am planning to route the bitbanger directly to the TIO pins like this:

scope.bitbanger.data_pin = ‘tio1’
scope.bitbanger.clock_pin = ‘tio2’
scope.bitbanger.inactive_state = ‘high_z’ # For I2C Open-Drain

My questions are:

1. Does the Husky FPGA allow the Hardware Bitbanger module to drive TIO1 and TIO2 directly just like the USERIO pins?

2. Are there any hardware, routing, or timing caveats I should be aware of when using the TIO pins for open-drain bit-banging instead of the front USERIO connector?

Thanks again for the amazing support and for releasing this feature!

Now for the moment I have had to stop as the partition i have allocated for ubuntu has filled up pretty quickly, stupidly I only allocated 15gig , ill be back once I have reinstalled in a larger HDD

unkownterminal:

I am aware there is a method to allow the usb to be seen in vm sections but I cant remember how to do so,

We have some instructions for that here.

At what point does it hang? We need more information.

And I am stuck now it would appear the file system doesn’t look like the one I have currently installed, i looked over what I typed and didnt again. And still nothing, its not loading or the hardware doesn’t appear to be seen, I dont really know ubuntu very, I am aware there is a method to allow the usb to be seen in vm sections but I cant remember how to do so, I am assuming its that, that is what mine doesn’t look like. Its similar. But not exactly the same.

Thank you so much for the detailed schematic and the explanation! It completely clarified the “dual path” issue I was facing. Moving the MOSFET before the measurement block to isolate the I2C pull-up noise from the DPA trace is a brilliant approach.

I have completely rewired my breadboard to match your diagram, effectively creating a single power path controlled by the MOSFET. However, I’ve run into a physical roadblock on the CW313 board itself: the power reaches the measurement block but doesn’t come out the other side.

Here is my exact current setup based on your FILTHP suggestion:

The Setup:

• JP4: REMOVED (To prevent the CW313’s 3.3V LDO from feeding the target directly and bypassing the MOSFET).

• MOSFET Source: Connected to the generic 3.3V pin on the CW313.

• MOSFET Gate: Connected to TIO3 (with a 10kΩ pull-up to Source).

• MOSFET Drain (Node A): Connected to the SHUNTH pad on the CW313 AND to the I2C 4.7kΩ pull-up resistors.

• Target Power: A wire going from the SHUNTL pad directly to the Target’s VCC (Pin 8).

The Multimeter Test & The Problem: I wrote a simple script to pull TIO3 LOW (turning the MOSFET ON) and took measurements with my multimeter referenced to the CW313 GND.

• Source: 3.3V (Power is arriving from Husky)

• Gate: 0.0V (Husky is successfully pulling it low)

• Drain / SHUNTH: 3.3V (MOSFET opens perfectly, and power reaches the input of the measurement block!)

• I2C Pull-ups: 3.3V (I2C lines are correctly powered from Node A)

• SHUNTL / Target VCC: 0.0V

My Question: The power completely dies between SHUNTH and SHUNTL. The target remains unpowered. Is it possible that my CW313 board is unpopulated/missing the internal SMD shunt resistor between SHUNTH and SHUNTL? Or is there another jumper (perhaps J4 / Measure) or trace I need to configure/cut to allow the power to flow through the onboard shunt when driving SHUNTH externally via the MOSFET?

Thank you again for your time and guidance!

The key to understanding is that in this example configuration, the glitch will happen scope.glitch.ext_offset cycles after each trigger, BUT there is only a single ext_offset counter in the hardware. So if a second trigger event occurs when a first trigger’s ext_offset hasn’t been reached yet, then the second trigger isn’t seen and won’t result in glitches.

A simple illustration: in the first case, the second trigger doesn’t overlap the first trigger’s associated glitch, so both triggers generate a glitch. (yellow = trigger, blue = fast clock)

In the second case, I’ve increased scope.glitch.ext_offset to push out the glitch after the second trigger; because the second trigger happens before the first trigger’s glitch has gone out, it’s ignored.

This is strange because scope.errors has existed for a super long time. By any chance did you previously have an older version installed?

Run the following to see where chipwhisperer is getting imported from:

import chipwhisperer as cw
print(cw.__file__)

You could use bit-banging and manually alternate driving the line and tristating it.

You won’t be able to use the simpleserial_write()/ simpleserial_read() this way; instead you’ll do things like:

scope.io.tio2 = 1
scope.io.tio2 = 0
scope.io.tio2 = 1
scope.io.tio2 = None # tristate the line so that target can drive it
rdata = scope.io.tio_states[1] # read what's on the line

I’m using CW1200 to communicate with a custom target board (ARM) over a 1-wire UART protocol.
The ChipWhisperer-Pro can easly send the commands but the reception is not that good. As you can see on the picture, when it is the target turns to communicate the line doesn’t go low enough.

I tried to change the pin configuration to scope.io.tio2 = scope.io.GPIO_MODE_SERIAL_RX or GPIO_MODE_HIGHZ but it doesn’t improve.

The ChipWhisperer-Pro is powering the target and the baudrate is 115.2 kbps.

Does the CW1200 has any pull-up resistor that I’m missing to disable? Or if someone knows any workaround for this scenario?

Thank you

If you don’t want the second power path, why don’t you simply disconnect it?

I’m also doing work with an I2C target at the moment; this is how I’ve wired it:

Here it’s wired as a “normal” ChipWhisperer target, powered via Husky’s target_pwr.

The labels refer to pins on the CW313. In your case, you could simply connect your “Node A” to where I have FILTHP.

I seem to have an issue with larger ext_offsets (>180k ish) where the glitch is placed after the rising edge of the trigger (blue) not falling. This then “loops around” to the start.

Any ideas?

You don’t need to feed an external clock. What you need to do is set scope.glitch.output = ‘clock_xor’, and have the glitch shaped so that it cancels out the clock as much as possible.

Here’s an example:

scope.default_setup()

scope.glitch.clk_src = 'clkgen'
scope.glitch.output = 'clock_xor'
scope.glitch.trigger_src = 'ext_continuous'
scope.glitch.repeat = 5
scope.glitch.width = 49
scope.glitch.offset = 1

scope.io.hs2 = 'glitch'

With this setup the glitch will occur when TIO4 goes high; you should get something like this:

I just wanted to know whether we can check the round wise output for the AES implementation running in the STM32F303 target of the CW-Lite. How do we observe that? In the simpleserial-aes.c code, chipwhisperer/firmware/mcu/simpleserial-aes/simpleserial-aes.c at develop · newaetech/chipwhisperer · GitHub - Do we use “simpleserial_get()” command at every round to observe the round wise output? Could you please support with this?

Do I need to feed the CW with an external clock that it then mixes with the glitch?

So I followed the install as mentioned, followed it to stop it from screaming at me, installed WSL , unbuntu da da da, and then fell on to the instructs for install , attempted to run the chipwhisper-updater “ which automates the process”

But hangs for me , great…. 25mins in and nothing… im going to check my firewall settings somthing isn’t happening that may well be the problem, I installed the ARM gcc within WSL

the input to the internal clock circuitry is through a divide-by-two flip-flops.

is telling you that the ChipWhisperer’s glitchy clock doesn’t directly clock the internal logic. This divide-by-two flop won’t filter out glitches the way a PLL would, but it will change the glitch characteristic.

Based on what you’ve described, I think you have a good chance of success if you focus your glitches on simply disabling the clock for multiple cycles (e.g. set scope.glitch.output to “enable_only”, with high repeat counts). You want to replicate, with control, the kind of clocking that the target is seeing when you’re fiddling with the wires and get a successful glitch effect.

There’s nothing in the datasheet that mentions PLL except

XTAL1 and XTAL2 are the input and output, respectively, of an inverting amplifier. The pins can be configured for use as an on-chip oscillator, as shown in the logic symbol, page 3. (page 3 shows external crystal connected to pins 18 and 19).

To drive the device from an external clock source, XTAL1 should be driven while XTAL2 is left unconnected. There are no requirements on the duty cycle of the external clock signal, because the input to the internal clock circuitry is through a divide-by-two flip-flops.

I never disconnected XTAL2 pin from the external crystal so does that mean that it’s a form of PLL?

Then I recommend you try a clean-slate install of our latest 6.0 release, following our instructions carefully (linked above) and not making any assumptions.

Usually, this means that voltage glitching or EMFI is a better approach.

You should usually be able to confirm the PLL hypothesis from the target’s datasheet. Sometimes the datasheet will tell you how to bypass the PLL.

I am currently glitching an 8051 device to do a jump from internal ROM to external program space (EEPROM) with my own code in there. I’ve been at it for weeks doing voltage glitching with few results.

A few days ago I tried clock glitching and again was getting almost no results. I verified with the oscilloscope that the glitches were happening according to the settings (width, repeat, offset, ext_offset) but there was no reaction from the target.

However, while I was faffing with the connections between the target and the CW-Lite, I suddenly had successful glitches and was able to take limited control of the chip. However, the glitch parameters didn’t seem to have any commonality - they were all over the place. I then suspected some float somewhere as the “glitches” were happening even when I wasn’t arming the CW for the glitch! (they weren’t glitches generated by CW)

After a few more closer looks at the wiring I realised that my ground from target to CW via the SMA port was somewhat loose. And the tiniest of wiggles caused the “glitch”.

The setup is:

1. Target powered by external power supply
2. Clock generated by CW and is fed to the target (with an option to switch to external crystal derived clock)
3. Serial pin on 8051 connected to TX in on the CW (allows me to monitor activity on the target)
4. nRst on CW connected to RST on target
5. Glitch SMA connected to target’s 5V and ground - largely for ground connection

scope.clock.adc_src = "clkgen_x1"
scope.clock.clkgen_freq = 11.059E6

scope.glitch.clk_src = "clkgen"
scope.glitch.output = "clock_xor"
scope.glitch.trigger_src = "ext_single"

scope.trigger.triggers = "tio4" # This is connected to nRst pin to trigger on reset (not sure if there's a better way)

scope.io.hs2  = "glitch"
scope.io.glitch_hp = False
scope.io.glitch_lp = False

Observations:

1. When the target’s clock is generated by the onboard crystal, it never glitches when fiddling with the ground connection
2. The glitch settings don’t seem to matter when the target is driven by CW’s clock
3. The glitch /sometimes/ happens when fiddling with the clock pin

It seems to me that there has to be a substantial jitter on the clock line to make the target misbehave in a desired manner and that seems to be the ground connection between the target and CW. So my thinking is that the CW isn’t generating a jittery enough clock. Perhaps it needs to be out of phase with the source clock, faster clock or something else that cannot be achieved natively.

What are my options here? Would slowing or speeding up the target help in my case? The target can run on between 2MHz and 16MHz clock. clkgen_x1 vs clkgen_x4 ? Can I do a mixed clock/voltage glitch with CW-Lite? I think the closest I can get to this is to generate a voltage glitch while the clock is being generated by CW, which I think is setting scope.io.hs2 = "clkgen"?

Any other advice/suggestions would be much appreciated.

Thank you for your patience — I apologize for not being clear enough with words. You’re absolutely right that a schematic is needed. I’ve attached one below showing the full circuit with both power paths.

The key issue is visible in the diagram: Node B (target VCC) receives power from two paths simultaneously — one through the MOSFET (which I can control) and one through the SHUNTL measurement wire (which is always on when target_pwr is active). This prevents the target from fully resetting when I turn off only the MOSFET.

I’ve been stuck on this for over two weeks now and haven’t been able to make progress. I would really appreciate any guidance on how to properly handle power-cycling in this configuration.

Thank you very much for your time and willingness to help.

POWER PATH 1 (MOSFET — fast, controlled by TIO3):
  3.3V ──► IRF9540N Source ──► Drain ──► [220Ω] ──► Target VCC (Pin 8)

  POWER PATH 2 (SHUNTL — always on when target_pwr = True):
  target_pwr ──► CW313 LDO ──► CW313 onboard shunt ──► SHUNTL pad
                                                            │
                                                         wire on
                                                        breadboard
                                                            │
                                                     ──► Target VCC (Pin 8)

  PROBLEM: When MOSFET is OFF, Path 2 still powers the target.
           Target never fully resets. I2C state machine gets stuck.

 ══════════════════════════════════════════════════════════════════════

  ACTIVE CONNECTIONS SUMMARY:
  ─────────────────────────────────────────────────
  CW313 Pin         →  Destination
  ─────────────────────────────────────────────────
  3.3V               →  IRF9540N Source
  TIO1 (GPIO1)       →  Node SDA (target Pin 5)
  TIO2 (GPIO2)       →  Node SCL (target Pin 6)
  TIO3 (GPIO3)       →  IRF9540N Gate
  TIO4 (GPIO4)       →  Node SCL (same as TIO2)
  SHUNTL pad         →  Node B (target VCC side of 220Ω)
  GND                →  Target Pin 4
  ─────────────────────────────────────────────────
  IRF9540N Source    →  3.3V + [10kΩ to Gate]
  IRF9540N Gate      →  TIO3 + [10kΩ to Source]
  IRF9540N Drain     →  Node A (input side of 220Ω)
  ─────────────────────────────────────────────────
  220Ω               →  Between Node A and Node B
  4.7kΩ #1           →  Between Node A and Node SDA
  4.7kΩ #2           →  Between Node A and Node SCL
  ─────────────────────────────────────────────────

Note: Node B is where SHUNTL wire, 220Ω output, and Target VCC (Pin 8) all connect.
This creates the dual power path problem: SHUNTL back-powers the target when MOSFET is OFF.
Pull-ups connect to Node A (MOSFET Drain side) so they only have power when MOSFET is ON.