Feature: improved target power backfeed safety

[dragonmux]

Detailed description

During a conversation on Discord with @compuphase it came up that the native hardware with current firmware allows you to some quite nasty things with the target power pin once feeding power from BMP has been enabled.

Saying "don't backfeed tpwr" is fine and all, but given the STM32F103 and related devices have an internal 1.2V bandgap reference, we set about figuring out how hard it might be to use the systick timer to sample that bandgap every few miliseconds and if we detect too much of a voltage rise or fall, switch tpwr feeding off.

This PR is the culmination of that work and should provide robust handling of tpwr backfeeding causing VCC to be driven up above 3.6V or down below 3.0V.

Your checklist for this pull request

• I've read the Code of Conduct
• I've read the guidelines for contributing to this repository
• It builds for hardware native (make PROBE_HOST=native)
• It builds as BMDA (make PROBE_HOST=hosted)
• I've tested it to the best of my ability
• My commit messages provide a useful short description of what the commits do

Closing issues

[desertsagebrush]

I was able to test this a bit with a programmable power supply; the general test procedure for testing overvoltage protection was:

• enable target power
• match power supply voltage to that (current limit 100mA) and enable
• slowly increase the voltage (10 mV steps) until twpr disables^1.
• repeat several times

Cut-off over-voltage results, given as voltage (current drawn before cutoff):

	BMP (native) v2.3b	BMP (native) v2.1e
	3.81 V (80 mA)	3.70 V (30 mA)
	3.80 V (80 mA)	3.72 V (40 mA)
	3.79 V (80 mA)	3.70 V (30 mA)
	3.81 V (80 mA)	3.70 V (40 mA)
	3.79 V (80 mA)	3.70 V (40 mA)
	--------------------	--------------------
avg	3.8 V	3.70 V

Best guess for the difference is that there are slight differences in the bandgap generation between the GD23F103 and the STM32F103 implementations. (Or resistor differences, etc)

Will get to the under-voltage side a little bit later/in a few days

^1: This can also be seen as the point when the device stops sinking current from the power supply.

Power Supplies tested: Siglent SPD3303X-E, BK Precision 9206 (will test early next week)

[dragonmux]

3.7-3.8V feels a bit high, but that's great that the feature works! that makes it seem like it's worth us adjusting the thresholds a little to get that 10-20mV down and closer to 3.3V for safety - but not bad.

Thank you for the help testing this. We look forward to seeing the under-voltage results

[desertsagebrush]

Apologies for not responding sooner, but work came up with a vengeance and I've been dealing with that.

That being said, I did play with it a bit with both the Siglent SPD3303X-E and BK Precision 9206, and over-voltage stays the same. I still haven't been able to test the under-voltage side because lowering the output from the power supply doesn't pull the probe output voltage down (which makes sense; the power supply is designed to source current, not sink it), and I do not have a programmable load floating around.

[desertsagebrush]

(I tested stuff again a few days ago before your newer commits, just FYI)

[dragonmux]

Thank you for your help with this - the "new" commits have only been us rebasing the branch forward to keep it in sync with main.

Interesting behaviour on trying to undervolt the target power pin - guessing then that the regulator puts out progressively more current till reaching the current limit. If @esden is contented with this, we'll try and figure out a value that is closer to 3.6V for the upper cut-off and convert this PR to ready for review so we can get it included in v1.10

[dragonmux]

We've added a voltage threshold adjustment for the upper bound, which should improve the safety factor from it kicking in at 3.7-3.8V to it kicking in between 3.6-3.7V. We'll mark this ready for merge in the mean time as it's shown to work at least for the over-voltage side of things, and that's a great improvement over not having this at all.

[esden]

LGTM, I think the best thing to do is to merge this so that it gets more use and testing before the next release.

[dragonmux]

Agreed, sounds good :)