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.
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.
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?
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)
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!
Thanks again for any insights you can provide, and also for your efforts in crafting this family of tools!
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.
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.
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!
