Trigger Signals

Hi Colin!

I tried to use the digital pattern matching module for triggering a smartcard acquisition on target_IO3 (which is also the smartcard IO pin). I am using the correct baud rate, parity, etc, but it does not work. I have yet to dive into the VHDL or Python code for the trigger module, but wondered if there were any obvious issues I am missing?

On a side-note, I thought it’d be nice to also have software trigger capability as it’s very convenient (though probably much less precise than a hardware trigger). It’s already written, yet to be tested, and I will post it if it is useful.

Best Regards

Have you played around with the ‘threshold’ or ‘initial bit correction’ numbers? I don’t have a good note, but sometimes need to adjust them up/down 1-3 numbers.

It’s also worth trying to ensure that you are trying to trigger on the first character appearing on the line. Once this works can look at triggering on later characters.

Let me know what settings you are using anyway and can try it on my setup here too.

Let me know about the software trigger too! Yes it’s much more convenient doing this stuff in SW compared to FPGA modules :wink:

Dear Colin, I have another question about digital pattern matching -

Since the pattern is 1-byte long, there might be ‘collisions’ e.g. with the random plaintext. I am guessing that the trigger is initiated on the first instance the pattern occurs (when the openadc is not busy).

What do you suggest as the best work-around to avoid these ‘collisions’?
I am currently thinking of increasing the pattern to 2 bytes.

Thanks in advance

The 2-byte solution is the answer you need! There is a bit of a caveat with the 2-byte solution though: the two bytes may not be perfectly timed, since most protocols don’t require precise timing between the end of one byte and start of the next.

But you can specify a wide range in-between the two bytes. I’m not sure if the current SW does this correctly - it looks like the “strToBits()” just inserts a stop bit then a start bit (with optional ‘guard bits’. Ideally I should insert a special character to indicate a large wait is possible. This is on the ‘todo’ list somewhere…

What I almost always ended up doing was either using a unique character (such as character-return), using a character at the start of the transmission + a large offset, or using a single byte and just throwing away instances where it triggered incorrectly.

Let me know about the software trigger too! Yes it’s much more convenient doing this stuff in SW compared to FPGA modules ?:wink:

Hi Bellag,

What I did was to edit reg_chipwhisperer.v to use bit 6 and 7 (previously unused) of addr_trigmod to implement a software trigger. I realised later on that no code change was needed as one could also force a trigger using bit 6 of the Settings register (probably with same effect)… :frowning: :frowning:

SW Triggering is convenient but traces are horribly misaligned, sometimes by more than 20k samples (this was tested only on smartcard targets) between traces.

For DPA, CPA, profiling etc, traces need to be aligned for a meaningful attack. But all is not lost as you can align the traces after acquisition (i use proprietary software for this).

Best regards,