Pulse on Target NRST when target_pwr set to 0

Hello NewAE Team,

I’d like to report what seems to be unintended behavior of CW-Lite-ARM hardware, using release 5.7.0 of the software. We’re running the code in a Jupyter workbook.

We’re still getting up to speed on the system, however have what seems to be consistently and easily reproducible behavior which is probably not as intended.

The circumstances are:

scope = cw.scope()
scope.io.nrst = 0
scope.io.target_pwr = 0

The result is displayed in the scope pictures (please excuse the photos… was the fastest way to get the images)

As can be seen in the first photo, NRST is asserted LO before the command to disable target power. At the moment the target_pwr = 0 command is sent, there is an appx 5ms deassertion of NRST, then it is once again asserted. The zoom photo is just to give a better view of the pulse width.

The hardware is CW-Lite-ARM, and the boards are still attached. There is a 1K resistor added between the switched 3.3V supply and GND on the connector. This only helps discharge the caps a bit faster, the anomaly occurs whether this resistor is in place or not.

As can also be seen in the scope trace, there is no pulse when tgt_power is turned on again. So this seems to be limited to the turning off operation.

We’d be grateful for confirmation that this is indeed an issue the team is able to reproduce. If there are some additional settings or other factors which could help us mitigate this, that would be welcome.

Please feel free to ask for any additional information which could be helpful.


Just a quick follow up on this post.

Based on the waveform, and a bit more noodling and research, it appears the “pulse” is actually the TNRST pin being set to High-Z during this time. Clearly, since the amplitude of the TNRST signal is following the power supply, this is being driven by the internal pullup in the uC on the NRST pin.

This however, still doesn’t exonerate the CW hardware! If the pin is set to be LOW, then changing the power state should not affect the TNRST pin of the CW FPGA (causing it to momentarily go High-Z).

So, mystery still there, just perhaps a more refined place to look?

Much thanks for insights!


Thanks for bringing this up. The Lite does set some of its target IO pins to high-z when turning power off, but looking at the code, this shouldn’t apply to the nRST pin (and even if it was supposed to, going high-z for a short period definitely isn’t intended behaviour)

I’ve opened a github issue to track this: nRST briefly goes high-z when setting target_pwr=0 · Issue #481 · newaetech/chipwhisperer · GitHub

Thanks Alex!

Appreciate you looking into it!

I suspect this is probably a fairly low-prio thing for you guys. Would you be OK with nudging this topic if it gets fixed?

Also, we’ve ordered a Husky, do you anticipate that this behavior would be present in that code, or is this particular to the Lite?



I’ve just confirmed that Husky has the same behaviour – as expected (the FPGA logic responsible for this is exactly the same).

We need to figure out how to best address this, then we can definitely provide an update here.

Awesome, Much thanks Guys!

Really appreciate all your efforts!

Hey Alex & Jean-Pierre,

A question came to mind, as you are looking over that code for the various signals on those FPGA pins…

Alex mentioned that when power is “OFF” to the target, certain GPIO pins on the FPGA are set to Hi-Z. The question recently was pondered over here…

Let’s say we set some of those pins explicitly to levels (ie. they are outputs set to HI or LO), Target_Pwr is deasserted, those pins go Hi-Z. When Target_Pwr is once again asserted (Power is turned on), do those pins which were set before power-off, regain their output status, and retain the values they were set to?

The question is simply to help better understand the statefulness of those pins, in conjunction with the Target_Pwr signal. Knowing this can help those of us using these capabilities to better craft code so we don’t get unintended (or unwanted) wiggles on those pins.

Also, a corollary question. If those pins are set to certain logic values while Target Power is OFF, is that state accepted by the FPGA/API, or is it rejected. If rejected, is that silent, or does it cause an error?

No expectations here, just trying to better understand the nuances!

If we had a vote:

  • State is retained across power cycling
  • State set during Power Off would be reflected on the pins when power is turned on! :slight_smile:

Thanks again for any insights you can provide, and also for your efforts in crafting this family of tools!

Yes, that is exactly what happens.

If you change the state of a pin that’s currently tristated because target_pwr is False, the change will be accepted, but it won’t alter the actual state of the pin until target_pwr is turned back on.

Awesome Jean-Pierre, thanks for the confirmation!

Is there documentation someplace as to which of the signals are affected by tgt_power?

Also, in anticipation of our Husky, would this apply to the additional GPIOs provided on that platform?

We will add it to the scope.io.target_pwr docstring (accessible in Jupyter via scope.io.target_pwr?); in the meantime, the complete list is:

  • PDID
  • PDIC
  • nRST
  • MOSI
  • SCK
  • HS2
  • IO1-4

No, target_pwr does not affect Husky’s front panel USERIO pins, nor the AUX I/O or Trigger/Glitch out MCXs.

Thanks for the reply Jean-Pierre.

A question (which I suppose could fall into the “feature request” category). I realize this could be argued a number of different ways, so I’ll present the case for your thoughts.

In the case of nRST, it might be nice to be able to have that asserted LOW even with power off. This way one could power on the device, while assuring that nRST remains LOW until the time when it is set HI or Hi-Z.

The counter argument is that when power is off to the target, one would not want to be driving any of the pins with voltage. Weird stuff can happen and even (poorly) power a target via a signal through unintended paths. Probably this was the intention of the original objective to Hi-Z the signals.

I’d plead the case that given this is a tool that is meant to be used by people who are “supposed” to know what they’re doing, allowing nRST to remain driven even when power is off (and the rest of the signals are Hi-Z) might be a nice compromise to assure no spurious behavior on the signal when power is reapplied.

In theory, the signal should be driven low (from Hi-Z), when target_pwr is set to turn on target power, and probably will get there faster than the power rail. But this is down to how the logic is implemented.

Just wanted to bring this additional thought to the discussion as you contemplate the best fix.

That is probably what we will do-- give the user the option to either drive nRST or tristate it when target_pwr is off.

Update: this has been fixed on the CW develop branch (Merge pull request #485 from newaetech/fpga-updates · newaetech/chipwhisperer@d460865 · GitHub), for CW-Lite/Pro/Husky.

The default behaviour is unchanged; there is now a scope.io.nrst_drive_poweroff property which, when set to True, makes CW keep driving nRST when the target is powered down, which avoids the pulse problem that you found.

Thank you for finding this and helping us make improvements!

Thanks for the update Jean-Pierre, and for the speedy resolution!

Grateful for your work, and happy to help make CW a better tool for all!