SWD or UART as trigger problem

[Grivus]

Hi!
I'm struggling for several days now, tldr: faultier can't see neither SWD nor UART signal as a trigger, always says trigger timeout.

my setup: I have a stm32f405 chip placed in an adapter board, so every pin is conveniently exposed, there is a test program running there, all power and grounds connected either directly to the faultier pins or to the breadboard and then to faultier, no capacitors or any other stuff.
Now I want the glitch to be triggered by the signal I'm sending over SWD or UART interface (tried both in this order). I also use oscilloscope to see at the signals I have.
On the faultier the glitch is connected to VCAP2, MUX0 to NRESET and EXT0 to the one of SWDIO, SWCLK, UART TX.
I can clearly see the signal on each of these on the oscilloscope screen (negative pulses swdio, positive pulses swclk, negative pulses uart tx), the result of operation performed is success.
I've also tried to connect directly the UART TX to the EXT0, without any intermediate stuff, the result is the same, so my guess the problem is not in weak wires connection on a breadboard.
The glitch config I use looks like:

ft.configure_glitcher(
    power_cycle_output = faultier.OUT_MUX0,
    power_cycle_length = 3000000,
    trigger_source = faultier.TRIGGER_IN_EXT0,
    trigger_type = faultier.TRIGGER_PULSE_NEGATIVE, // tried here every option
    glitch_output = faultier.OUT_CROWBAR
)

and the way I use it:

# glitch non blocking
ft.glitch_non_blocking(delay=d, pulse=p)
# operation
status = operation() # this activates SWDIO and SWCLK or UART TX
# block glitch
try:
    ft.glitch_check_non_blocking_response()
except Exception as e:
    print(f"exception: {e}")

No matter what trigger type I use with each option (SWDIO,SWCLK,UART TX) I always get the "exception: Trigger timeout!"
I have positive experience using some pin set to HIGH in firmware code as a trigger - it works just fine, so this is not the broken EXT0.

The questions are: is there some missing part of software configuration on my side, or a bug in software on some level, or this is a hardware problem?

[nezza]

Heya,

Interesting - this works here :/ Do you know how long the delay is between starting your operation and the SWD trigger?

I have positive experience using some pin set to HIGH in firmware code as a trigger - it works just fine, so this is not the broken EXT0.

This one is interesting - so if you in firmware set the pin it works, but with an SWD signal it doesn't? Do you have access to an oscilloscope to check the logic levels?

[Grivus]

Do you know how long the delay is between starting your operation and the SWD trigger?

Around few seconds, since there is openocd starting as subprocess, it may vary a little. I've tried to play with timeout property, found it .py code, but with no success (however, it may be that I set it not in proper moment or not proper value)

This one is interesting - so if you in firmware set the pin it works, but with an SWD signal it doesn't?

Yes

Do you have access to an oscilloscope to check the logic levels?

To check if the voltage for pin set and for swd are the same? My guess they are not the same, SWD was lower (that is how I remember them on a display), but I should check this specifically. I'm in a trip now and will have an access to the oscilloscope later in Dec (closer to 29-30) and will post an update then.
If it appears that levels are indeed not the same and that may be the issue, is there any sensitivity config available?

[Grivus]

@nezza I've checked with an oscilloscope what you asked.

So, this is the triggered state of my pin, which works as a trigger fine:
it is low by default, and when the pin is set it is high at 3.2V

And here is the SWDIO measurements during openocd command:

it is high by default at 3.2V level, and then there are a lot negative pulses to 0V, which are for some reason does not work as a trigger (tried again with TRIGGER_PULSE_NEGATIVE and TRIGGER_LOW settings).

Seems I remembered wrong and levels are the same.

[Grivus]

@nezza I have also tried to use an external stlink device to connect via swd (and to trigger faultier), it connects but also fails to trigger.
Could there be a way to trace what is going on in the faultier itself while all these happens?

[Grivus]

@nezza Ok, I think I've found the reason for this behaviour.

If the code in https://github.com/hextreeio/faultier is actual, then there is hardcoded timeout "1 second currently" (file main.c line 670), and the timeout that appears in python code is a different timeout, not related to the glitcher itself.
As I'm accessing the SWD from the faultier itself, I use forked openocd, which starts as child process and it tooks more than 1 second to do it.
I've connected external stlink again and now used not openocd but pyswd to control it, and the trigger timeout exception is gone now.

Now the question is: how to workaround this, preferably without using external stlink?
Should I build a modified firmware for faultier with bigger timeout, or is there some in-code SWD API for tamarin to use so delay will be smaller?

[nezza]

Ahh, maybe I can just make the timeout adjustable! Apologies, I thought that you already tried adjusting that timeout (misunderstanding on my side).

I will make it configurable so you can just set it to 10 seconds or whatever.

Thanks for hunting this down!

[Grivus]

Thanks, this should help

I've tried to modify the timeout of device object, which I've found in python code, however it seems to be other timeout (serial comm I guess), not related to the one that is discussed.