No input protection

[Winkelkatze]

First of all, thanks for the great work!

But since I managed to kill my programmer, I noted that there are a few avoidable failure modes that could lead to the destruction of the programmer and / or the target.

The five volt tolerant inputs of the STM32 do not have any protection towards the positive rail, so an accidental short between VPP and an input pin of the programmer will fry that pin.

If for some reason the negative voltage is not being generated, the target vdd could rise up to the 15V, which will kill the target and the programmer.

Damage to the programmer could be easily avoided by adding zener diodes to the inputs (after the protective resistors). About the negative voltage for the OpAmp, it may be better to just use an OpAmp that works down to the negative rail and remove the charge pump.

[cpldcpu]

These are good points.

Regarding the negative voltage generator: Both this one and the power switch are eliminated in the lite design, therefore this failure mode should be eliminated. (see here: https://github.com/free-pdk/easy-pdk-programmer-hardware/files/5470996/EasyPDKprog_lite.pdf)

Regarding the zener diodes: I am not sure how exactly you would do this, as it would also be preferrable not to destroy the zener diodes if a pin is connected to 5V? Also, the protection may not introduce any voltage delta to VPP and VCC.

[Winkelkatze]

The STM32 inputs have an absolute maximum voltage of VCC + 4V, so using zeners with a voltage of about 7V (probably a bit less) from the IOs to ground should do the trick. They wouldn't be used for to the VCC / VPP pins, just for the 5 other IOs. Since the 7V is beyond the maximum target VDD (6.6V), it also won't induce any additional load on that. About destroying the zeners, I guess this may be an issue if you are using small diodes and the VPP is injected into that pin for an extended period of time. But usually the programmer should turn off VPP rather quickly in any case, so this should be fine.

[cpldcpu]

Ok, thank you, understood. I also checked the documentation of the STM32F072 now. The maximum allowable voltage would be 3.3V+4V=7.3V, so the Zener voltage should be very close to 7V, maybe 6.8V to 7.2V.

There are no suitable devices in the basic parts library at JLCPCB, but I will look into adding footprints for a potential lite r2 design, so people can populate it afterwards. Due to the additional capacitive loading, it may also be necessary to adjust some programming voltages.

In addition, there needs to be a software protection layer. Some ideas:

• Before programming: Short check between VPP and GPIO by wiggling VPP and checking whether any other pint changes. Of course there could be false positives if the padauk-mcu in the test socket also has a program on it.

• During programming: Short check on VPP by monitoring the voltage.

@freepdk what do you think?

[cpldcpu]

@Icaltary

What do you think about this device? https://datasheet.lcsc.com/szlcsc/ON-Semicon-ON-SMF05CT1G_C15879.pdf

It's available as basic part at JLCPCB. One problem is though, that the breakdown voltage is a little low. If it is used after the series resistors this may still be ok, though, since it's not an issue if logic levels are limited.

[Winkelkatze]

The SMF05CT1G looks almost perfect since the breakdown voltage is 6.2V - 7.2V. The padauk controllers are specified up to 5.5V only anyway, so the 6.6V of the programmer is more of a theoretical limit that shouldn't be reached during normal usage.

I wouldn't be too worried about capacities. The programmer has already a 100n cap parallel to the VPP and VDD. Adding a few more pF to the IO's shouldn't change anything.

About the software based approach, I'm not sure if that's viable. The IOs may (and probably will) change even if everything is connected correctly. This is especially true for MTP controllers, since they may start executing their program.

[freepdk]

A simple check for shorts could be added to software. Maybe there is no need for the protection diodes then.

Maybe something like this:

• create 2.5V as VPP
  • check if any of the IO pins sees a "high" ==> if so, abort with "VPP short detected"
• create 4.5V as VPP and 2.5V as VDD (this enters programing mode and prevents the IC from starting the user program)
  • check if any of the IO pins sees a "high" ==> if so, abort with "VDD short detected"

[Winkelkatze]

You are probably right. You would have to turn on the Pull-Downs to prevent leakage current from triggering that detection. And you need to verify, that all IOs are indeed LOW in the programming mode / while only VPP is applied. Btw you don't really need to detect VDD shorts, since (if there are no HW faults) the VDD shouldn't be able to exceed 6.6V anyway.

It wouldn't prevent damage from a faulty target or a short that occurrs during programming, but this may be acceptable.

Another option for the diodes would be to add clamping diodes against the 5V from the USB. This would be very simple, but would limit the max voltage to 5.7V. That's still greater that the 5.5V max, but its pretty low.

[cpldcpu]

A software check would be preferrable in any case, since it could be easily applied to existing programmers. And indeed, if it's possible to do the check while the device is in a controlled programming mode, it should be quite robust, too.

I will add the footprint of the protection device to the next revision of the lite programmer if I get around, then people could still add it as a precautionary measure.

Clamping vs. the USB supply somehow feels not right.

[freepdk]

I'm not sure, but maybe sending signals out to the IOs and use the ADC to check if voltage changes on VPP/VDD while virtually creating 0V for VPP/VDD might also be an option.

[cpldcpu]

Maybe something more pragmatic: How about entering programming mode using voltages below 7V and simply trying to read the device ID as a first step? If that works, then most likely there is no short between VPP and one of the lines used for programming. In addition one would need to check whether any of the lines that are not used by the programming interface are toggled.

[freepdk]

Maybe something more pragmatic: How about entering programming mode using voltages below 7V and simply trying to read the device ID as a first step? If that works, then most likely there is no short between VPP and one of the lines used for programming. In addition one would need to check whether any of the lines that are not used by the programming interface are toggled.

The probe command is doing that (4.5V VPP / 2.5V VDD + READ).

So just adding the probe procedure before READ/WRITE/ERASE should (implicitly) do the thing?

[cpldcpu]

Indeed, that would be a simple and robust solution that would at least catch some of the most obvious "miswirings".