Implement target power control in DAP_Connect/DAP_Disconnect handlers

[Disasm]

V1.1 hardware has T_VCC_EN signal that controls 3.3V target power (and should be handled carefully), V1.2 hardware also has T_ENABLE signal to control 5V line.

[adamgreig]

How would you map DAP_Connect onto T_VCC_EN etc? Turning them on when we connect, or only when we connect and no target vcc is discovered, sounds liable to cause unexpected and bad surprises if the user didn't want 3v3 to suddenly appear on the target. Last time I looked I didn't really find anything in CMSIS-DAP that's suitable for controlling probe-supplied-power; maybe it needs to be a vendor command.

[Disasm]

AFAIK, target power is usually handled in DAP_Connect, but I agree that controlling 3V3 line can be dangerous. We can control 5V line, though, this should be safe. This line is "reserved" in stlink docs, but controlled by stlink.

[Yatekii]

I'd rather make this a persistent setting with a vendor specific command :) Because I want it to always supply power :)

[adamgreig]

Persistent as in "as long as the probe remains powered", so you turn it on/off separately from a debug session?

Would we extend probe-rs to add hs-probe's vendor specific command for controlling power? Not sure if you'd then have to expose that through to the cargo flash/embed etc tools or make a new binary that just lets you set power on/off...

[Disasm]

3V3 power can be provided via pin2, just like on stlinkv3 (though it doesn't provide enough power on this line).

[adamgreig]

Ah, only on the STDC14 connector though, not on the standard Cortex Debug connector (the inner 10 pins)?

[Disasm]

@adamgreig yes, 5V and 3V3 are present only on STDC14.

[adamgreig]

At least on the 1.2 schematic, aren't STDC pins 2 and 3 both connected together, so the cortex debug connector pin 1 (stdc14 pin 3) is also toggleable 3v3?

[Disasm]

Yes, they are connected on V1.2 schematic and it's probably something we should reconsider :)

[adamgreig]

I've lost track of what changed in 1.1 too, but previously didn't we have 5v and 3v3 both hardwired on STDC14 1 and 2, and then the selectable 3v3 on STDC14 pin 3? I'd still really want to be able to toggle 3v3 supply on STDC14 pin 3, so that when using it with a standard debug cable/connector you can still supply target power.

[Disasm]

This "power" part was the same in all hs-probe versions so far. Ok, so it's better to leave the schematics as it is, but control 3V3 line only with a special vendor command (or persistent configuration)?

[adamgreig]

The schematics seem fine, though I don't know if STDC14 users would normally expect pins 1 and 2 to be always on (or at least always on when you try to connect to a target). Certainly we don't want pin 3 to be always on 3v3, but it seems good to be able to turn that on when desired, so probably the current schematic is the best option.

I would have thought the vendor command is what enables power until either the probe is unplugged from USB or another vendor command is used to disable power. I don't know if @Yatekii meant it should persist it to non-volatile memory so it applies power again when you next plug the probe in, though that seems like it might also be quite surprising or cause accidents. I don't know what software we'd provide to let the user run those vendor commands, though.

[Yatekii]

Persistent as in "as long as the probe remains powered", so you turn it on/off separately from a debug session?

Would we extend probe-rs to add hs-probe's vendor specific command for controlling power? Not sure if you'd then have to expose that through to the cargo flash/embed etc tools or make a new binary that just lets you set power on/off...

Persistent as in "stored in eeprom" :)

Idk what the best way to control this is :)

[korken89]

I'd not have it persistent as in "stored in eeprom" as this might have strange effect when going between different boards.
However to keep it during one "plug in" is fine IMO.

[Yatekii]

Well, then you cannot use that feature independently of a driver :) Works for me, but idk for others :)

[korken89]

And now with the v1.3 there is one more place 5V can come that needs to be handled (KEY pin). :)

[dbrgn]

Well, then you cannot use that feature independently of a driver :) Works for me, but idk for others :)

We could control this via cargo feature in the firmware, and then you simply flash the "5V default on" firmware variant?

[dbrgn]

As a quick-and-dirty workaround to enable the 5V and 5V_KEY output pins, this should do, right?

diff --git a/firmware/src/main.rs b/firmware/src/main.rs
index 8c3c8d1..822a9b9 100644
--- a/firmware/src/main.rs
+++ b/firmware/src/main.rs
@@ -70,6 +70,7 @@ fn main() -> ! {
         led_green: gpiob.pin(8),
         led_blue: gpioe.pin(0),
         t5v_en: gpiob.pin(1),
+        t5v_key_en: gpiod.pin(7),
         tvcc_en: gpioe.pin(2),
         reset: gpiog.pin(13),
         gnd_detect: gpiog.pin(14),
diff --git a/hs-probe-bsp/src/gpio.rs b/hs-probe-bsp/src/gpio.rs
index 924e349..ea0ecb3 100644
--- a/hs-probe-bsp/src/gpio.rs
+++ b/hs-probe-bsp/src/gpio.rs
@@ -368,6 +368,7 @@ pub struct Pins<'a> {
     pub led_blue: Pin<'a>,

     pub t5v_en: Pin<'a>,
+    pub t5v_key_en: Pin<'a>,
     pub tvcc_en: Pin<'a>,
     pub reset: Pin<'a>,
     pub gnd_detect: Pin<'a>,
@@ -419,6 +420,13 @@ impl<'a> Pins<'a> {

         // Push-pull output drives target 5V supply enable.
         self.t5v_en
+            .set_high()
+            .set_otype_pushpull()
+            .set_ospeed_low()
+            .set_mode_output();
+
+        // Push-pull output drives 5V key supply enable (low = active).
+        self.t5v_key_en
             .set_low()
             .set_otype_pushpull()
             .set_ospeed_low()

At least it does seem to work 🙂

(Careful, the 5V_KEY pin needs a hardware fix, since it's on the wrong pin of the connector.)

[Disasm]

A feature-gate would also help to contain the magic smoke inside other probes :)