EEVblog #1144 - Padauk Programmer Reverse Engineering

[js_12345678_55AA]

Thank you for your detailed explanation! The major issue that I am having is that it is extremely difficult to obtain an EasyPDK programmer. STM32F072C8T6(and some other parts) becomes out of stock on LCSC for a long time(it means no jlcpcb SMT assembly). Also I found that assemble this programmer is really hard for people that lacks SMT soldering experience.

In case the STM32F072  C8T6 version is not available you also can use the CBT6 version (STM32F072CBT6).
Basically it is the same processor which just has more flash memory (In reality there is the same silicon inside as in the "smaller" variant).

The resistors and capacitors can be replaced with any other offering, just make sure value (... Ohm /...k / ...nF / ...uF) and size (0603/1206/...) match.

The coil HPC3015TF-6R8M could be replaced by this one: CMLW3015S6R8MST.


I already used bigger SMT components (0603) to make hand assembly easier (I did over 50 pcs already). 0603 components can be soldered with small soldering tip and without a microscope.


JS

[true]

I'm busy on other projects now, but have the supplies and can supply my own version of the programmer in a few months (maybe August). That is, if you aren't in a hurry...

[LovelyA72]

I am also having some questions related to the IDE. Is there a FreePDK IDE available? If not, is there any tool recommended to work with the SDCC compiler(like WinAVR can work with Programmer's Notepad)?

[HwAoRrDk]

The Code::Blocks IDE works quite well with SDCC.

[LovelyA72]

Thanks for your advice! I ended up using Programmer's Notepad. I configured pn to work with SDCC and it works really nice. The best thing about pn is that it's portable. I can put pn and sdcc on a thumb drive and use it anywhere I want.

[electronic_eel]

Hi,

did anybody investigate how the LVR (low voltage reset) fuses for the PFS154 work?

I tried to manually set the fuse for example to 0x36E1, which should set the LVR to 4V. At least according to https://github.com/free-pdk/fppa-pdk-documentation/blob/master/Reserved_Area_Last_8_Words_Of_Codemem.txt.

But the PFS154 powers on right at about 2V and powers off again if I go below 2V. I do not disable the LVR in the MISC register, so I think it should not switch on fully before Vdd reaches about 4V.

I read back the fuse value with the read command and it was indeed set to 0x36E1 as expected.

Or do I misunderstand how the LVR function works?

Thanks.

[js_12345678_55AA]

Hi,

did anybody investigate how the LVR (low voltage reset) fuses for the PFS154 work?

I tried to manually set the fuse for example to 0x36E1, which should set the LVR to 4V. At least according to https://github.com/free-pdk/fppa-pdk-documentation/blob/master/Reserved_Area_Last_8_Words_Of_Codemem.txt.

But the PFS154 powers on right at about 2V and powers off again if I go below 2V. I do not disable the LVR in the MISC register, so I think it should not switch on fully before Vdd reaches about 4V.

I read back the fuse value with the read command and it was indeed set to 0x36E1 as expected.

Or do I misunderstand how the LVR function works?

Thanks.

Hi,

the LVR value is not a fixed place in code memory on PFS154, you have to program a SFR instead. Original PDK initialization code uses a fixed position to get a value and sets the SFR based on this.

I defined the SFR register names and settings for PFS154 in pfs154.h (see dev branch: https://github.com/free-pdk/easy-pdk-programmer-software/blob/development/Examples/src/easypdk/pfs154.h )

Special Function Register (SFR) name is:

MISCLVR

Values are:

//misc_lvr definitions
#define MISCLVR_4V                   0x00
#define MISCLVR_3V5                  0x20
#define MISCLVR_3V                   0x40
#define MISCLVR_2V75                 0x60
#define MISCLVR_2V5                  0x80
#define MISCLVR_1V8                  0xA0
#define MISCLVR_2V2                  0xC0
#define MISCLVR_2V                   0xE0

So in order to setup 2V LVR you have to set (a good place for this is inside of _sdcc_external_startup() ):

MISCLVR = MISCLVR_2V;

Also make sure that you do not disable MISC_LVR in MISC register via MISC_LVR_DISABLE. The following line will disable MISC_LVR_DISABLE ... which means it is enabled.

MISC &= ~MISC_LVR_DISABLE;

Have fun,

JS

[electronic_eel]

Hi,

the LVR value is not a fixed place in code memory on PFS154, you have to program a SFR instead. Original PDK initialization code uses a fixed position to get a value and sets the SFR based on this.

I defined the SFR register names and settings for PFS154 in pfs154.h (see dev branch: https://github.com/free-pdk/easy-pdk-programmer-software/blob/development/Examples/src/easypdk/pfs154.h )

Special Function Register (SFR) name is:

MISCLVR

aha, so on the PFS154 they aren't using the fuse as on PMS150C, read out by hardware, to set LVR, but a regular, undocumented register you have to set in your initialization code.

I've now got it to work with the MISCLVR register. Thanks for your help.

[tim_]

I have been wondering whether there are ways to to make the EASYPDK-programmer a bit more accessible. Dave did a great series showing how to assemble it, but it also took him quite a while and he had issues with some small parts. (He made some things with the toolchain look way more complicated than they are, but that is probably a for another discussion)

Just some thoughts what could be done. The goal should be to reduce the total number of parts and use slightly larger ones, where possible. (e.g. 0805)

1) Maybe the programmer could be designed in a way to piggybag on a bluepill? This would remove the need to source the controller and solder the USB port. I have to admit that it is quite bodgy though... Alternatively one could switch to a more available, but slightly more expensive MCU, like the STM32F103. Does it have DFU mode? Another option: Switch to a low-cost 8051 based USB micro (WCH...). But porting the firmware will be painful...



2) There is a charge pump that generates -2.4V for the OPAMPs that control the programming voltages. This is needed to allow full voltage swing down to GND to be actually able to turn the supply voltages off. I have checked the AR358 (LM358 clone) datasheet and the output voltage swing goes down to 30mV. While this is not super-clean, pulling VPP and VDD to 30mV should be sufficient to disable the device to be programmed. SO maybe this part could be skipped and the OPAMP be connected to ground? JS, did you try this and it failed?



3) The step up converter comes with dual mosfet to disable power supply. The Step-up-converter itself has an enable pin that is tied tied to always active. Turning off the step-up converter using the enabled input would result in 5V on the 15V supply. However, the 15V supply is only used to feed the opamps. If using the opamps to pull VPP and VDD to ground, it would be acceptable for them to be supplied from 5V when the boost converter is inactive. I have to admit that this is not super robust, but it shold likely be fine as long as the MCU is controlling everything while the device to be programmed is connected. Thus, Q1, Q1, R7,C11,C19 could be removed? One may want to put in a filter to protect the rest of the circuit from noise, though.

4) The 3.3V Supply (RT9193) could also be removed if the bluepill is used.

Does it make sense? Anything to add?

[greenpossum]

@#853: I'd be happy to whip up and contribute a C::B wizard for Padauk when the hardware stuff becomes available to me. I just did one for STM8 with SDCC.

[electronic_eel]

1) Maybe the programmer could be designed in a way to piggybag on a bluepill? This would remove the need to source the controller and solder the USB port.

The Bluepill has two big downsides:
1) it nowadays often comes with incompatible, cloned microcontrollers, see for example https://www.mikrocontroller.net/topic/488417
2) Even when genuine, it uses the STM32F103, see below

Alternatively one could switch to a more available, but slightly more expensive MCU, like the STM32F103. Does it have DFU mode? Another option: Switch to a low-cost 8051 based USB micro (WCH...). But porting the firmware will be painful...

The STM32F103 does not come with a USB-Bootloader. So you would have to flash one in first. You'd need a ST-Link or similar for that, which makes first bringup much more complicated than now where you just have to hold a button.

Also the STM32F103 does not have DACs, which are necessary for the programmer to function. One could emulate that with PWM and some opamps, but that would add complexity, not reduce it.

The same goes for lowcost 8051 solutions. Getting it to work there is a lot of work and in the end won't make it cheaper or easier to build.

2) There is a charge pump that generates -2.4V for the OPAMPs that control the programming voltages. This is needed to allow full voltage swing down to GND to be actually able to turn the supply voltages off. I have checked the AR358 (LM358 clone) datasheet and the output voltage swing goes down to 30mV. While this is not super-clean, pulling VPP and VDD to 30mV should be sufficient to disable the device to be programmed. SO maybe this part could be skipped and the OPAMP be connected to ground? JS, did you try this and it failed?

This could maybe be optimized, but I'm not sure if it is worth it. The charge pump circuit is really small and straight forward. What could be done though is replacing the two small diodes with one BAT54S in SOT23. That would make populating it easier.

3) The step up converter comes with dual mosfet to disable power supply. The Step-up-converter itself has an enable pin that is tied tied to always active. Turning off the step-up converter using the enabled input would result in 5V on the 15V supply. However, the 15V supply is only used to feed the opamps. If using the opamps to pull VPP and VDD to ground, it would be acceptable for them to be supplied from 5V when the boost converter is inactive. I have to admit that this is not super robust, but it shold likely be fine as long as the MCU is controlling everything while the device to be programmed is connected. Thus, Q1, Q1, R7,C11,C19 could be removed? One may want to put in a filter to protect the rest of the circuit from noise, though.

I think the current solution is much cleaner, because it prevents any small power glitches and similar during turnon when the STM32 is still starting up. The way it is now, the Padauk only gets powered when the STM32 is fully controlling things.

I like the design of the programmer as it is now, as it does what it should without unnecessary bells and whistles. The footprints and lack of silkscreen sometimes make it harder to build than necessary though. There is some work being done porting the layout to Kicad right now, see github pull requests. I think this is a good starting point for optimizations in these areas.

[tim_]

I think the current solution is much cleaner, because it prevents any small power glitches and similar during turnon when the STM32 is still starting up. The way it is now, the Padauk only gets powered when the STM32 is fully controlling things.

Actually the reference voltage inputs of the OPAMP are pulled to GND by R4 and R9, so that the voltage at VDD and VPP of the device will always be GND, unless the STM32 is fully in control. I don't think power gating the boost-converter is necessary.

I like the design of the programmer as it is now, as it does what it should without unnecessary bells and whistles. The footprints and lack of silkscreen sometimes make it harder to build than necessary though. There is some work being done porting the layout to Kicad right now, see github pull requests. I think this is a good starting point for optimizations in these areas.

I also have little incentive to change anything in the programmer, because I have two working ones and JS did a very good job with the programmer and the firmware. But saying that there is no need to lower the entry barrier by reducing the programmer complexity, where possible, may be ignoring the many people that have issues with building one. I was hoping to get some constructive discussion going.

Btw, I noted the STM32F072C8T6 is available at LCSC again.

[electronic_eel]

Actually the reference voltage inputs of the OPAMP are pulled to GND by R4 and R9, so that the voltage at VDD and VPP of the device will always be GND, unless the STM32 is fully in control. I don't think power gating the boost-converter is necessary.

Ok, you are right. So one could get rid of Q1, Q2, R7 and enable the stepup from the STM32, keeping R26 as pulldown for the EN. The datasheet of the MT3608 defines EN input high as minimum 1.5V, so we are good with the 3.3V from the STM32.

C11 and C19 are necessary though, they are the input capacitors for the stepup, no reliable operation without them.

[tim_]

Btw, I noticed that JS has optimized the BOM of the EASYPDKprog for lowerst cost at LCSC.

JLPCB has a slightly different catalogue for part they allow to use for their assembly service. All parts in the "Basic" category do not require any addional set up cost. So, if it was possible to build the easypdkprog only from parts in the basic category, it could be ordered fully assembled at reasonable cost.

https://jlcpcb.com/parts

[js_12345678_55AA]

Hi,

There are several things which could be stripped down to make e.g. a "LITE" version:

- remove LEDs
 (-3 leds, -3 resistors)
- remove push button (users could bridge two pads to enter DFU mode)
 (-1 push button)
- remove ADC input, this is not needed for normal operation, it's for a future feature, to be able to read out protected ICs by writing 0 bits and monitor power consumption, but not needed in LITE version
 (-4 resistors)
- remove of transistors for step up enable (as long as STM32 is not running, negative voltage is not generated for opamp. since the step up outputs the input voltage in case enable pin is low this will let some small voltage go directly to the socket)
 (-2 transistors, -1 resistor)
- remove negative opamp feed (diodes) - this might cause trouble during programing, but with all observations of already supported ICs an offset voltage on VDD to GND might be compensated with a higher programing voltage
 (-2 diodes, -2 capacitors)
- remove crystal (the crystal is there for high accurate tuning of IC after writing ... in case the LITE version is always attached to USB and will not have stand alone mode - planned future feature - then clock can be synced to USB to achieve good tuning result)
 (-1 crystal, -2 capacitors)
- use resistor array for connections to IC
 (-5 resistors, +1 array)

The main idea when creating the programmer over a year ago was to have a versatile platform which leaves room for improvements and testing new tricks which not been implemented / tested in this moment.

Personally I think it is to early to reduce the programmer. Maybe the ADC will be very handy in future? Maybe the 0 voltage output of the opamp is required for some ICs? Maybe the conservative way of completely disabling the output of the step up saved a lot of ICs since during STM32 startup/ USB connects / DFU updates / ... a lot of wired states been observed?

And since the target ICs will never be close to any "Arduino" experience, writing software for them is a much bigger challenge than to save a handful of components.

It would be more helpful to support adoption of new ICs and to create better introductions / walk throughs for beginners.

You saw Dave struggling when he tried his own "Hello World" (even that there are fully working and pre compiled examples including make files coming with the EasyPDK programmer software... He just overlooked this).

JS

EDIT: Direct link to EasyPDK code examples: https://github.com/free-pdk/easy-pdk-programmer-software/tree/master/Examples  <=============== CODE EXAMPLES

[electronic_eel]

Btw, I noticed that JS has optimized the BOM of the EASYPDKprog for lowerst cost at LCSC.

JLPCB has a slightly different catalogue for part they allow to use for their assembly service. All parts in the "Basic" category do not require any addional set up cost. So, if it was possible to build the easypdkprog only from parts in the basic category, it could be ordered fully assembled at reasonable cost.

I like the idea of opitmizing the programmer so that it can be easily populated by the JLCPCB SMT service. Unfortunately the STM32F072C and the MT3608 are both "extended" parts, so I don't see any way around that additional setup fee without creating a substantially different programmer.

When using the SMT service for the first time, you usually get a coupon, which reduces the cost. So I don't think the price of the programmer is too much of an obstacle for widespread adoption.

[tim_]

Hi JS,

thanks a lot for your insights.

- remove negative opamp feed (diodes) - this might cause trouble during programing, but with all observations of already supported ICs an offset voltage on VDD to GND might be compensated with a higher programing voltage
 (-2 diodes, -2 capacitors)

My understanding is that this will not generate an offset, but it will not allow VDD to go to 0V. Instead it will move to 20mV. To be honest, I don't think that is an issue since the main requirement is to pull VDD low enough for the POR circuit to perform a reset. 20mV should be more than sufficient. The datasheet says the POR limit is >1.8V.

It would be more helpful to support adoption of new ICs and to create better introductions / walk throughs for beginners.

You saw Dave struggling when he tried his own "Hello World" (even that there are fully working and pre compiled examples including make files coming with the EasyPDK programmer software... He just overlooked this).

Fully agree. To be really honest, we may need to solve the issue of having example code for four different environments first. (Small C examples, Philips examples with no make file, my examples using different includes etc.).

Btw, one question in addition: Which function is assigned to each of the three LEDs on the easypdkprog? I would like to add some silkscreen for explanation.

[tim_]

Ok, I had the audacity to create a preliminary "lite"-Version of the easypdkprogrammer, based on "Basic" components from the JLCPCB catalogues.



You can find the schematics below. I had to change quite a few parts. I simplified the supply a bit, as discussed above. The functionality should be exactly identical, including the not-yet-used ADC sense lines.

The inductor, USB-port and headers have to be soldered manually. The XTAL is optional, but can still be populated. The switch is also optional. Two pins can be used instead to invoke the bootloader.

The MCU can be either populated by JLCPCB or manually.

Cost for populated PCBs without MCU is $16.95 for five, so $3.39 each. That includes the PCB, but no shipping. Cost with CPU is $26.8 for five, $5.36 a piece.

Let me know if you have additional input. I will most likely test this the next time I order at JLCPC, which could still be a while. If anybody else wants to try, i can share the design files.

p.s.: It seems that EasyEDA has updated all their libraries with slightly increased solder pad sizes. If you update the footprints, a lot of designrules in the easypdkprogrammer pcb are violated.

[daveatol]

You can find the schematics below. I had to change quite a few parts. I simplified the supply a bit, as discussed above. The functionality should be exactly identical, including the not-yet-used ADC sense lines.

You can get rid of another 4 resistors if you connect PB0 & PB1 to the opamp pin 2 & 6

[tim_]

You can find the schematics below. I had to change quite a few parts. I simplified the supply a bit, as discussed above. The functionality should be exactly identical, including the not-yet-used ADC sense lines.

You can get rid of another 4 resistors if you connect PB0 & PB1 to the opamp pin 2 & 6

True, good observation. But on the other hand I wonder what you would measure then? Effectively you observe the voltage difference between the negative and positive opamp input, the reguluation input. This is basically dependent on opamp gain. So it would vary depending on temperature and part-to-part variation. It would only be a very indirect indicator of supply current.

But the same applies to the implementation as it is now? Adding the resistors costs only fractions of cents, btw.

[daveatol]

But on the other hand I wonder what you would measure then?

You measure exactly what you're measuring with the resistor dividers R14/15/16/17, just scaled differently.

This is basically dependent on opamp gain. So it would vary depending on temperature and part-to-part variation. It would only be a very indirect indicator of supply current.

Resistor dividers don't really suffer from temperature dependence. I'm not sure what this has to do with supply current.

[tim_]

But on the other hand I wonder what you would measure then?

You measure exactly what you're measuring with the resistor dividers R14/15/16/17, just scaled differently.

This is basically dependent on opamp gain. So it would vary depending on temperature and part-to-part variation. It would only be a very indirect indicator of supply current.

Resistor dividers don't really suffer from temperature dependence. I'm not sure what this has to do with supply current.

I meant VDD and VPP of the device to be programmed.

The thing is that the operational amplifier can be seen as a device that tries to create a "virtual short" between the positive and negative inputs. So, with a perfect opamp you would basically measure your DAC output voltage at the ADC input. In a real circuit you will measure a small delta, because the gain of the OPAMP is finite. The OPAMP gain however, depends on part-to-part variation, ambient temperature, and supply voltage in a non-predictable way. In addition we will also observe an influence of the opamp output impedance.

But yes, you measure basically the same in both resistor configurations.. The thought experiment of simplifying the schematics just shows that the information to be gained from the sense input is to be treated with caution. You can surely detect a short condition, but any attempt of measuring more nuanced information needs to be scrutinized in respect to the deviation introduced by the opamp.

[daveatol]

In a real circuit you will measure a small delta, because the gain of the OPAMP is finite. The OPAMP gain however, depends on part-to-part variation, ambient temperature, and supply voltage in a non-predictable way. In addition we will also observe an influence of the opamp output impedance.

The opamp gain is so large w.r.t. the closed-loop gain that its variance doesn't matter. The input offset voltage would have more of an effect.

The thought experiment of simplifying the schematics just shows that the information to be gained from the sense input is to be treated with caution. You can surely detect a short condition, but any attempt of measuring more nuanced information needs to be scrutinized in respect to the deviation introduced by the opamp.

If you want to measure the VDD/VPP current consumption, keep R14/15/16/17 on the output of the opamp, but add a series resistor (10R should be OK) between there and the header pins; this resistor should be inside the feedback loop. I agree that the sense configuration as currently drawn is not very informative.

[tim_]

The opamp gain is so large w.r.t. the closed-loop gain that its variance doesn't matter. The input offset voltage would have more of an effect.

Good point. Looks like the input offset for the LM358 is 5 mV and the gain is 100dB, so there is at least 2 oom difference wrt to FS output.

If you want to measure the VDD/VPP current consumption, keep R14/15/16/17 on the output of the opamp, but add a series resistor (10R should be OK) between there and the header pins; this resistor should be inside the feedback loop. I agree that the sense configuration as currently drawn is not very informative.

Hm.. the ADC is 12 bit and assuming FS=3.3V we can resolve 0.8 mV per count. The voltage dividers R14-R17 divide by a factor of 6, so we can resolve ~5mV in the higher voltage domain. For a 10 Ohm sense resistor that would correspond to 500µA resolution. A second sense input may be needed for reference. No idea whether this would provide meaningful insight. JS, what was the idea behind the sensing?

In general, it would, of course, make most sense if the lite version behaves identical to the original one.

Edit, changed ratio.

[EEVblog]

Ok, I had the audacity to create a preliminary "lite"-Version of the easypdkprogrammer, based on "Basic" components from the JLCPCB catalogues.

(Attachment Link)

You can find the schematics below. I had to change quite a few parts. I simplified the supply a bit, as discussed above. The functionality should be exactly identical, including the not-yet-used ADC sense lines.

The inductor, USB-port and headers have to be soldered manually. The XTAL is optional, but can still be populated. The switch is also optional. Two pins can be used instead to invoke the bootloader.

The MCU can be either populated by JLCPCB or manually.

Cost for populated PCBs without MCU is $16.95 for five, so $3.39 each. That includes the PCB, but no shipping. Cost with CPU is $26.8 for five, $5.36 a piece.

Let me know if you have additional input. I will most likely test this the next time I order at JLCPC, which could still be a while. If anybody else wants to try, i can share the design files.

p.s.: It seems that EasyEDA has updated all their libraries with slightly increased solder pad sizes. If you update the footprints, a lot of designrules in the easypdkprogrammer pcb are violated.

Awesome work Tim!
If people can buy a turn-key assembled board from JLC then that wold be awesome, but one-off's aren't practical so someone in each country couldn't make up a bunch on sell locally perhaps?
Don't JLC have a public open source projects thing?
Will this be going back into the git?