Husky: No Trigger Seen

Hi, I’m trying out “/notebooks/jupyter/courses/sca101/Lab 2_1B - Power Analysis for Password Bypass (HARDWARE).ipynb” tutorial with CW Husky. I’ve uploaded the compiled unmodified firmware onto the target board, which works fine.

Then I’m getting connection to Husky with this code, which works fine:

import chipwhisperer as cw
import time

SCOPETYPE = ‘OPENADC’
PLATFORM = ‘CWHUSKY’
SS_VER = ‘SS_VER_2_1’

scope = cw.scope()
target_type = cw.targets.SimpleSerial2
target = cw.target(scope, target_type)
print(“INFO: Found ChipWhisperer😍”)

prog = cw.programmers.SAM4SProgrammer

time.sleep(0.05)
scope.default_setup()

Then I’m defining these functions:

 def reset_target(scope):
     scope.io.nrst = 'low'
     time.sleep(0.25)
     scope.io.nrst = 'high_z'
     time.sleep(0.25)
     
 def read():
     reset_target(scope)
     s = ""
     while target.in_waiting() > 0:
         s += target.read()
         time.sleep(0.25)
     return s
 
 def cap_pass_trace(pass_guess):
     reset_target(scope)
     num_char = target.in_waiting()
     while num_char > 0:
         target.read(num_char, 10)
         time.sleep(0.01)
         num_char = target.in_waiting()
 
     scope.arm()
     target.write(pass_guess)
     ret = scope.capture()
     if ret:
         print('Timeout happened during acquisition')
 
     trace = scope.get_last_trace()
     return trace

But when I actually run the read() followed by cap_pass_trace() I get this error:

  1. Why don’t I see the whole text from read(), the last thing it read was “Pleas”, but it should read "Please enter password to continue: ", why is it missing some text. I’ve played with sleep to make it longer in case the data is not yet available, but it didn’t fix the issue.
  2. Why do I get the “Timeout in OpenADC capture(), no trigger seen! Trigger forced, data is invalid” error? There is an array of samples right after the error, so I’m not sure if the code obtained an actual power trace or not?

There’s a limited serial buffer on the Husky (IIRC 192 bytes or something like that), so it can be easy to lose bits of long serial messages. In this case, you can safely ignore this.

Try adding more of a delay before scope.arm(). You’re resetting again in cap_pass_trace(), so the device might still be sending out those boot messages by the same target.write() happens.

Alex