newaetech / chipshouter Goto Github PK

I am using ChipSHOUTER with an external trigger circuit(fpga) connected to my target.

After few runs, I end up getting the fault["fault_high_voltage", "fault_trigger_glitch"]

I am suspecting the high voltage fault is because of constantly changing the capacitor voltage to control the amplitude of the glitch and second one is because of fault which disarms and glitch still continues. Please advice on any alternative on controlling the glitch power ?

Even if i call the cmd_clear_fault after catching the latched exception(something similar in the usermanual for reset exception. i keep getting the same exception even after power cycling.

Is there any firmware revision which can disable this high voltage and trigger glitch fault?

I even tried talking to the serial directly to control it. but the shouter keeps resetting or more faults. but operation was way faster than the API.

I have similar problem to newaetech/ChipSHOUTER-python#8, but not after 5s.. after 15-60 min of run with or without triggersafe used

ChipSHOUTER xformer: 51, MOSFET: 44, diode: 35  - temperature 
ChipSHOUTER voltage measured: 457, set: 470
ChipSHOUTER absent time after trigger: 1
ChipSHOUTER glitched 73 times, runs: 00:17:25
Faults current:  [], latched:  ['fault_temp_sensor'] ['fault_temp_sensor']

Also after that when you read temp values they are all -1 or 65535
Only device reset clear them

ChipSHOUTER xformer: 65535, MOSFET: 65535, diode: 65535 - temperature
This is a bug I think. This values should never be overshoot like that. When reading this value it goes in fault state. It is also possible to Arm with this failure values. If trigger_safe is not set you can still arm.. but only reset of device clear them

Then when you enable trigger_safe and ARM with xformer: 65535, MOSFET: 65535, diode: 65535 ChipSHOUTER goes to Fault state. This should prove that this is software bug

Of course you can see this -1 values in normal UART menu, so it is not python API problem

RJ12 pinout in printed manual is wildly inaccurate somehow. Not only is pin numbering reversed from standard RJ12 expectations, the pins are still totally wrong (just just mirrored). The following is the fixed pinout:

A HV charge circuit error causes a latched fault. This is not obvious as it prevents you from arming, but the reported fault condition appears identical for the initial/new fault & a latched fault.

The result is that if there is an HV error (such as issue #5 ), fix the error but don't clear the fault, and re-arm the system, the resulting error message is identical to before. It should be more clear the previous (uncleared) fault is the issue, and the ChipSHOUTER is not even checking if the issue is cleared.

I use the mobaxterm to connect to the usb interface, input no echo, and output garbled characters.

I am using chipwhisperer and chipsohuter jointly and I would like to know how to modify the output pulse width of the chipshouter?

I have tried to modify the scope.glitch.repeat parameter on the chipwhisperer side and the cs.pulse.width parameter on the chipshouter side, but it doesn't look like this is working from the oscilloscope.

Our internal tests set the voltage to 150V, arm the ChipSHOUTER, and then cycle through voltage settings.

However, there is occasionally a bug when you set to other voltage levels and arm the chipshouter causing a fault to occur. This occurs because we don't wait long enough before checking if the HV charge is working OK. This will be fixed in a future firmware version.

For now if you see the charge error, simply change your set voltage to a lower voltage (150V), Arm the chipshouter, then set final voltage. If this still gives you error try a different voltage as the initial setting until you find one that reliably arms, and use that for your initial voltage.

A mistake in Firmware 1.9.0 causes the device to enter "triggersafe" mode if you do a full "get". This applies both via the API (reading the base cs object) or just typing "get" in the command line.

This occurs because the "triggersafe" attribute is read - which has the side effect of disabling the triggersafe mode, which then causes a temp error if the unit is armed. As a quick work-around just don't read the "triggersafe" attribute. Or if you do, do a "disarm" then "arm" cycle.

The following is an example - arming the unit then doing a "get" causes the error:

# disarmed:Arm

# arming:# Arm 

# armed:get
# id                                        IGC6KG:1.9.0 .....[Board ID]
# state                                     armed ............[Current Arm operating mode of the board.]
# voltage                                   500v .............[capacitor bank voltage]
# voltage                                   500v(measured) ...[capacitor bank voltage]
# pulse width                               160ns ............[pulse width (nS)]
# pulse width                               160ns(measured) ..[pulse width (nS)]
# pulse repeat                              3 Repeat .........[pulse repeat (times)]
# pulse deadtime                            10msec ...........[pulse deadtime (mS)]
# arm_timeout                               2 Minutes ........[Arm timeout (seconds)]
# hwtrig_term                               0 bool ...........[*hardware trigger in (sma) high impedance.]
# hwtrig_mode                               1 bool ...........[*Hardware trigger in (SMA) active HIGH]
# emode                                     0 bool ...........[*rj12 pin 6 is pulse in trigger (sw)]
# mute                                      0 bool ...........[*buzzer is enabled]
# bootbits                                  85 Decimal .......[Boot bits]
# fault_active                              0000000000000 ....[Active faults]
# fault_latch                               0000000000000 ....[Latched faults]
# fault latched probe                       0 probe  .........[*Probe attached]
# fault latched overtemp                    0 overtemp  ......[*temperature is fine]
# fault latched open                        0 panel Open  ....[*cover is secure.]
# fault latched highv                       0 high voltage  ..[*high voltage circuit ok]
# fault latched ramcrc                      0 RAM CRC  .......[*ram is all good.]
# fault latched eecrc                       0 EEPROM CRC .....[*eeprom is all good]
# fault latched gpio                        0 GPIO  ..........[*gpio is all good]
# fault latched charge                      0 charge  ........[*charging circuit is all good]
# fault latched trigger                     0 trigger ........[*trigger is all good.]
# fault latched hw                          0 hardware exc ...[*hardware is good.]
# fault latched trig_g                      0 trigger glitch .[*Trigger was NOT glitched while disarmed... Thanks!]
# fault latched overvoltage                 0 overvoltage ....[*No Charging overvoltage.. all good ]
# fault latched temp_sensor                 0 sensor fault ...[*Temperature sensors all good]
# temperature mosfet                        30C ..............[Temperature of MOSFET]
# temperature xformer                       35C ..............[Temperature of transformer]
# temperature diode                         27C ..............[Temperature of diode]
# triggersafe                               1 bool ...........[Check if we a clear for trigger]
# absent_temp                               1 Seconds ........[Temperature sensor absent time in Seconds.]
# pat_enable                                0 bool ...........[*pulse follows basic width trigger]
# pat_wave                                   .................[Set waveform using 1 and 0 (max N, extend with pat_append)]

# armed:
# armed:# fault latched temp_sensor    1
# Error: Change System State not allowed [System in fault]
# fault latched temp_sensor    1

Deadtime has a constant offset of ~ 40 ms, consistent for various values of repeat

Looks like we can add hooks to auto-update submodule to latest, so this repo always points to latest API for example. Need to investigate.

On ChipWhisperer 5 vagrant VM (Python 3.6), clone the ChipSHOUTER git including "python" submodule, then try typical python3 module installation (e.g. "pip3 install " or "python3 setup.py install") but always get this error when running "from chipshouter import ChipSHOUTER":

Cannot import name 'ChipSHOUTER'

Additionally, ChipSHOUTER documentation does not yet specify installation instructions beyond "install with pip install chipshouter" in parentheses (https://chipshouter.readthedocs.io/en/latest/), which does not work in Python 3.