EEVblog #1144 - Padauk Programmer Reverse Engineering

[tim_]

Your programmer uses many different component, so it also does not have a very optimized BOM for production.

Yes, this programmer has a quite different approach. It is intended to feed VCC to a board, which may consume more current than the PIC itself would need. Also it is intended to set the voltage on VCC to values from approx. 2 volts to nearly 7 volts from the supply via USB and maintains the logic levels according to this span. That's probably a bigger gun than required for programming a Padauk controller.

But there are some details in the hardware, I would like to point on: the setup of the voltages is separated from the switches, it needs only a usual PWM and it is limited by the choosen values of the resistors, so no fault can occure if the software fails to limit it to the bounds given by the manufacturer.

Yeah, one could actually run the bost converter from an PWM output, i know that's also done in some PIC programmers. Or one could use a lowpass filter to get a DC reference voltage. Using a DAC saves some headache for calibration though and one can use an open-loop control. if it is available in the MCU it's a better approach in my books.

My comment was rather referring to the fact that you used many different component types. Not easier to get manufactured than the easypdkprog is now.

My problems with the easypdkprog are software problems, in particular the lacking definitions of the protocol between PC and programmer on the USB. I use to start any development by writing down the interface and protocol between different parts (like PC software and µC firmware), so the whole development can be divided into smaller parts and can be written separately.

And I love to split down the necessary functions of the programmers firmware to atomic ones, so the algorithms can be left on the PC side without making the whole procedere clumsy. If there is an interest in this, I can post it here.

This sounds a bit like the GNU/Hurd vs. Linux debate (not that I witnessed that first hand...) What you are proposing is certainly cleaner from an architecture point of view, but in the end both solutions work equally well for the user. Changing the software now would be a major undertaking.

One thing that could be very interesting though, would be to adopt the Pickit programmer hardware. There are many clones available on eby/aliexpress and the hardware looks like it could support the Paduak.

[spth]

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

Is this lite programmer mechanically compatible (i.e. will it fit into the same case as the normal programmer)?

The main problem I see for assembly is the USB connector. Replacing it with a through-hole part, while breaking mechanical compability, would make it easier to hand-solder (as JLCPCB does not solder connectors).

P.S.: Why not just put the design into free-pdk git, as an alternative programmer, to make it easier for people to have a closer look (and github issues might be better for discussion of individual features than this forum thread). We already have 10 repos there, so an 11th one won't hurt.

[tim_]

Ok, I finalized revision 0 of the EASYPDKPROG-lite now and ordered a few populated boards for testing purposes. They should arrive in about 3 weeks. I may share some boards after successful testing, since multiple people contacted me asking for one.



The programmer should be mechanically and functionally 100% compatible to the original. I had to change many parts though, to cater for the JLCPBC part selection, and made some simplifications. So there is a risk that the lite version has some yet-to-be-identified quirks.

Almost all parts can be populated by the JLCPCB assembly service. The cost is close to $2 when ordering 50 pc.

The following parts have to be assembled manually:

- The headers
- The power inductor L1
- The USB connector
- Optional: Xtal and push button.

So some assembly is still required. But this will also help to avoid certain regulations on the sales of electronics devices.

for further details, please refer to my design notes in the PDF.
 

[tim_]

Is this lite programmer mechanically compatible (i.e. will it fit into the same case as the normal programmer)?

The main problem I see for assembly is the USB connector. Replacing it with a through-hole part, while breaking mechanical compability, would make it easier to hand-solder (as JLCPCB does not solder connectors).

P.S.: Why not just put the design into free-pdk git, as an alternative programmer, to make it easier for people to have a closer look (and github issues might be better for discussion of individual features than this forum thread). We already have 10 repos there, so an 11th one won't hurt.

Yes, it should be 100% mechanically compatible. I considered your proposal of adding a through-hole USB connector. But unfortunately those are only available as A-type plug or socket. Adding them would have required significant changes to the board layout. Also type-A connectors seem to be somewhat outdated. So I stuck with the Micro-B, but moved some components around for easier soldering.

I can add the design files and ordering instructions to the easkypdk repository after testing.

[js_12345678_55AA]

Is this lite programmer mechanically compatible (i.e. will it fit into the same case as the normal programmer)?

The main problem I see for assembly is the USB connector. Replacing it with a through-hole part, while breaking mechanical compability, would make it easier to hand-solder (as JLCPCB does not solder connectors).

P.S.: Why not just put the design into free-pdk git, as an alternative programmer, to make it easier for people to have a closer look (and github issues might be better for discussion of individual features than this forum thread). We already have 10 repos there, so an 11th one won't hurt.

Yes, it should be 100% mechanically compatible. I considered your proposal of adding a through-hole USB connector. But unfortunately those are only available as A-type plug or socket. Adding them would have required significant changes to the board layout. Also type-A connectors seem to be somewhat outdated. So I stuck with the Micro-B, but moved some components around for easier soldering.

I can add the design files and ordering instructions to the easkypdk repository after testing.

Hi,

in case this needs to be identified as a board variant (which I think might not be required) it would be a good idea to connect one of the unused STM32 pins (e.g. choose one from PB8-PB15) to GND.
This would make it possible to identify this hardware variant in the firmware and to handle things different in case it's needed.

JS

[tim_]

Is this lite programmer mechanically compatible (i.e. will it fit into the same case as the normal programmer)?

The main problem I see for assembly is the USB connector. Replacing it with a through-hole part, while breaking mechanical compability, would make it easier to hand-solder (as JLCPCB does not solder connectors).

P.S.: Why not just put the design into free-pdk git, as an alternative programmer, to make it easier for people to have a closer look (and github issues might be better for discussion of individual features than this forum thread). We already have 10 repos there, so an 11th one won't hurt.

Yes, it should be 100% mechanically compatible. I considered your proposal of adding a through-hole USB connector. But unfortunately those are only available as A-type plug or socket. Adding them would have required significant changes to the board layout. Also type-A connectors seem to be somewhat outdated. So I stuck with the Micro-B, but moved some components around for easier soldering.

I can add the design files and ordering instructions to the easkypdk repository after testing.

Hi,

in case this needs to be identified as a board variant (which I think might not be required) it would be a good idea to connect one of the unused STM32 pins (e.g. choose one from PB8-PB15) to GND.
This would make it possible to identify this hardware variant in the firmware and to handle things different in case it's needed.

JS

I connected PB8 to ground, so the board is identifiable. See circuit and design notes.

In hindsight it would make sense to have one pin to indicate whether a crystal is present and a few others to identify boards. Maybe we can use PB8 to GND to identify boards without crystal? I can add some other ID pins in the final version.

[js_12345678_55AA]

I connected PB8 to ground, so the board is identifiable. See circuit and design notes.

In hindsight it would make sense to have one pin to indicate whether a crystal is present and a few others to identify boards. Maybe we can use PB8 to GND to identify boards without crystal? I can add some other ID pins in the final version.

Hi,

Crystal presence can be detected in software :-)

JS

[tim_]

I connected PB8 to ground, so the board is identifiable. See circuit and design notes.

In hindsight it would make sense to have one pin to indicate whether a crystal is present and a few others to identify boards. Maybe we can use PB8 to GND to identify boards without crystal? I can add some other ID pins in the final version.

Hi,

Crystal presence can be detected in software :-)

JS

Even better. Is this already implemented?

Well, then I'll keep it as it is and claim "PB8=GND" as identifier for the lite version.

Regards,
Tim

[js_12345678_55AA]

I connected PB8 to ground, so the board is identifiable. See circuit and design notes.

In hindsight it would make sense to have one pin to indicate whether a crystal is present and a few others to identify boards. Maybe we can use PB8 to GND to identify boards without crystal? I can add some other ID pins in the final version.

Hi,

Crystal presence can be detected in software :-)

JS

Even better. Is this already implemented?

Well, then I'll keep it as it is and claim "PB8=GND" as identifier for the lite version.

Regards,
Tim

Just a heads up... before you make new version.

Right now I'm working on supporting new flash types from PADAUK (PFS172 / PFC...). It looks like programing sequence changed. Now not sending high voltage on VPP (PA5) but on VDD instead. Looks like after CMD phase (2V voltage difference between VDD and VPP, e.g. 2.5 VDD / 4.5 VPP) new protocol sets VPP to 0 for read/erase/write and VDD needs to be 8.3V for write.

==> Right now programmer can not create 8.3V on VDD (we might need to change R6, maybe same value as R8 so both opamp outputs can produce same levels).

Still investigating.

JS

[tim_]

[ Specified attachment is not available ]

Just a heads up... before you make new version.

Right now I'm working on supporting new flash types from PADAUK (PFS172 / PFC...). It looks like programing sequence changed. Now not sending high voltage on VPP (PA5) but on VDD instead. Looks like after CMD phase (2V voltage difference between VDD and VPP, e.g. 2.5 VDD / 4.5 VPP) new protocol sets VPP to 0 for read/erase/write and VDD needs to be 8.3V for write.

==> Right now programmer can not create 8.3V on VDD (we might need to change R6, maybe same value as R8 so both opamp outputs can produce same levels).

Still investigating.

JS

Thanks for the heads up. I need to change the board anyways for mass production to find a better position for the mounting holes. There will be a "r1".

Regarding the PFS172: It seems it supports two programming modes, right? This is described in unusual detail in the datasheet. The current revision of easypdkprog should be able to support the limited voltage programming mode. They just don't mention why one needs the "normal mode" at all...

[js_12345678_55AA]

@tim_

Thanks for reminding me of the limited voltage mode. I saw the higher VDD in data sheet and also measured it during programing but forgot about the limited voltage mode :-)

I will try to use this with writer and report back.

JS

[spth]

Regarding the PFS172: It seems it supports two programming modes, right? This is described in unusual detail in the datasheet. The current revision of easypdkprog should be able to support the limited voltage programming mode. They just don't mention why one needs the "normal mode" at all...

Maybe the reduced volatge programming mode has reduced retention? Or programming is slower?

[tim_]

Regarding the PFS172: It seems it supports two programming modes, right? This is described in unusual detail in the datasheet. The current revision of easypdkprog should be able to support the limited voltage programming mode. They just don't mention why one needs the "normal mode" at all...

Maybe the reduced volatge programming mode has reduced retention? Or programming is slower?

They have a minimum retention specification, so I guess both modes are equeal in that regard. 

It being about programming speed seems more likely. I assume they use a HCI-MTP IP, so the programming speeds depend on voltage and current. I guess programming time is an important cost factor for many of their customers. Maybe not so much for us...

[js_12345678_55AA]

Regarding the PFS172: It seems it supports two programming modes, right? This is described in unusual detail in the datasheet. The current revision of easypdkprog should be able to support the limited voltage programming mode. They just don't mention why one needs the "normal mode" at all...

Maybe the reduced volatge programming mode has reduced retention? Or programming is slower?

Hi,

I think I figured out "limited voltage" programing.

The logic analyzer capture showed the trick:

Programing needs 4 words on PFS172 to be programmed at same time.

In limited voltage programming mode VDD is set to 5.3V and only 1 of the 4 words is programmed (the other 3 words are all '1's, so nothing will change during programming).
After the first word is programmed, the second word of this group is programmed, ...

so instead of programing

A W W W W

it will take 4 passes:

A W X X X
A X W X X
A X X W X
A X X X W

then address is incremented and next 4 word group is programmed.

Address(A), Word(W), AllOnes(X)


This also might be a nice trick to make a real cheap programmer for the flash variants (e.g. using the 5V of Arduino and a 2 resistor voltage divider to have a second voltage to enter programing mode)


JS

[serisman]

Hello All,

I've been watching this thread off and on for over a year now, and finally have a few projects that I'm itching to try.  Obviously, getting a working programmer and some ICs is the first step, and that is what has held me back for a while.  But, it looks like things have progressed to a point where I think I'll jump in.  Thanks everyone for all your hard work on this!

Anyway, I spent some time today familiarizing myself with the programmer hardware schematics, and noticed that the base portion is roughly the same as the infamous STM32 blue-pill boards.  So, I ended up creating a (mostly compatible) variation that is a top-hat for said boards.  This is smaller than the original programmer, so it will be a bit cheaper to get one-offs produced (well technically 3-offs... $4.80 for 3x shipped from OSHPARK).

Important: Because the blue-pill's STM32F103C8T6 doesn't offer a DAC, it will have to be replaced with the STM32F072C8T6 that the original programmer uses (they are pin compatible), or possibly the software would have to be modified to use PWM instead of DAC (might not be easy/possible).  Also if the LEDs are populated, the blue-pill's 32kHz crystal and supporting capacitors may need to be removed.

The schematic (attached), aside from missing the STM32, USB, Vreg, etc... is exactly the same (with the same ref #'s as well), except for these minor changes:

• PB0/PB1 was moved to PA0/PA1.  This kept the final board size smaller and means the blue-pill's boot mode jumpers aren't blocked.  I don't think this will be a problem, although it will require a software modification, and I haven't tested it yet.  Worst case, I can bodge wire it over to the original pins.
• All 0603 components (resistors/capacitors/leds) were changed to 0805.  That's what I have on hand, and they are a bit easier to hand solder
• The inductor footprint was changed to CD32.  That's what I have on hand.  Not sure if they are compatible size wise, but CD32's are available from lcsc or aliexpress if needed.
• I used a 8-pin IC header layout instead of the 16-pin.  This kept the board smaller.  None of the top pins were connected anyway.
• PB9 is connected to GND to make it easier to identify this hardware variant from software
• PA15 isn't connected to BOOT0 (although it could be with a bodge wire).  Not sure why it is on the original?

Here are the components that the blue-pill board already populates, and therefore are not in my schematic or on my board:

• USB connector (and resistors R10,R11)
• U1 - STM32 MCU (and capacitors C5,C8,C9,C12,C17)
• U2 - 3.3v regulator (and capacitors C6,C7,C22)
• SWD header
• SW1 switch (and resistor R3)
• X1 crystal (and capacitors C15,C16)

I sent these boards off to OSHPARK (https://oshpark.com/shared_projects/z5EAm6HO) to get produced and will build one up when they get back in a few weeks.  Hopefully I didn't mess up anything to badly on the schematic.  Assuming all goes well, I'll publish the source files as well (I used Kicad).

[spth]

Due to the high number of different pinouts on the 8-pin Padauk devices, I had to create five different variants of the minimal evaluation boards:

https://github.com/free-pdk/f-eval-boards

Thanks to easypdkprog, three of them have been tested (for a total of 5 µC-board combinations), and work well. Corresponding demo programs are at

https://github.com/free-pdk/sdcc-pdk-code-examples

The goal is to have a board for every Padauk flash device (as a side effect, there are some µC that fit on multiple boards).

P.S.: From the table in the README it looks as if the f-eval-pdk-s08b board is redundant. It was created since the PFC161, despite also having the S08A package listed in the datasheet currently is available in S08B package only.

[js_12345678_55AA]

• PB0/PB1 was moved to PA0/PA1.  This kept the final board size smaller and means the blue-pill's boot mode jumpers aren't blocked.  I don't think this will be a problem, although it will require a software modification, and

This should not be a problem at all. It also can be used to auto detect the programmer variant.

• PA15 isn't connected to BOOT0 (although it could be with a bodge wire).  Not sure why it is on the original?

This connection is intended to also have the button state on a GPIO so the programmer can be used in stand alone mode (later) - firmware is stored in MCU flash, no computer attachached, press button to program IC.

JS

[tim_]

Hi,

I think I figured out "limited voltage" programing.

The logic analyzer capture showed the trick:

Programing needs 4 words on PFS172 to be programmed at same time.

In limited voltage programming mode VDD is set to 5.3V and only 1 of the 4 words is programmed (the other 3 words are all '1's, so nothing will change during programming).
After the first word is programmed, the second word of this group is programmed, ...

so instead of programing

A W W W W

it will take 4 passes:

A W X X X
A X W X X
A X X W X
A X X X W

then address is incremented and next 4 word group is programmed.

Address(A), Word(W), AllOnes(X)


This also might be a nice trick to make a real cheap programmer for the flash variants (e.g. using the 5V of Arduino and a 2 resistor voltage divider to have a second voltage to enter programing mode)


JS

Ah ok, that makes a lot of sense. When I tried to program the PFS154 with my Arduino based contraption I had to resort to the same approach of only writing one byte at a time. Apparently the programming mode is somehow current limited and writing fewer bits at the same time allows programming when less current is available.

That's good news, because then the only impact of low-voltage programming is that the writing is slower. This is propbably quite inconsequential for us.

[serisman]

Ok, I was thinking more about the programmer top-hat that I posted a few posts up, and pcbs are so much fun to design and order, so I decided to go ahead to create a bottom board to go along with it.  I call this the STM32 Mini-Pill.  It is essentially 1/2 of the infamous "Blue-Pill" board, and also has a very similar schematic to the STM parts of the original free-pdk programmer.

Combining both modules together essentially nets the same thing as the original programmer (with the slight differences called out above).  The only real 'advantages' are: a smaller size (stacked instead of long), possibly easier hand soldering (uses 0805 instead of 0603), and a base-board module that can be re-used with other projects.  That last point is key for me.  I don't want more than a couple of Padauk programmers, but I could see myself using a larger number of these base-board modules.  So, one can place a small order for the top-hat, and a larger order of the Mini-Pill if desired (or just use the Blue-Pill with the required modifications listed above).

I ordered up a set from OSHPARK for $4.50 for 3x (including free shipping), and will build them up when I get all the parts in.  (https://oshpark.com/shared_projects/8USgL5pT)

The Schematic and Gerber files are attached.  I will post the original Kicad files somewhere after testing everything.

Aside from the obvious parts, I used the following footprints:

• All capacitors, resistors, and the LED are 0805
• USB connector: LCSC C393940 (https://lcsc.com/product-detail/USB-Connectors_SHOU-HAN-MICRO5-9mmusb_C393940.html)
• Reset and Boot0/PA15 "side" buttons: LCSC C393942 (https://lcsc.com/product-detail/Tactile-Switches_SHOU-HAN-TS24CA_C393942.html)
• 8MHz crystal: 5032 2 pin: LCSC C122522 (https://lcsc.com/product-detail/SMD-Crystal-Resonators_TAE-Zhejiang-Abel-Elec-SMD-5032-2P-8M-20pf-30ppm_C122522.html)
• 3.3v regulator: XC6206P332MR: LCSC C347376 (https://lcsc.com/product-detail/Low-Dropout-Regulators-LDO_UMW-Youtai-Semiconductor-Co-Ltd-XC6206P332MR_C347376.html)

[serisman]

This should not be a problem at all. It also can be used to auto detect the programmer variant.

JS, thanks for the confirmation.     I was looking at the source code, and if I am reading it correctly, it looks like I would only need to modify the code to use ADC 0/1 instead of ADC 8/9.  Does that sound right?

This connection is intended to also have the button state on a GPIO so the programmer can be used in stand alone mode (later) - firmware is stored in MCU flash, no computer attachached, press button to program IC.

Ahh... that makes sense.  I included it on the STM32 Mini-Pill that I just posted.

[serisman]

Due to the high number of different pinouts on the 8-pin Padauk devices, I had to create five different variants of the minimal evaluation boards:

https://github.com/free-pdk/f-eval-boards

spth:  I was looking at this repo yesterday and found myself desiring to see a preview of these boards.  Maybe there is one somewhere and I just didn't see it?  I'm not even sure what to do with the .sch and .lht files to generate my own.  (What tool are those files for?)  Would it be possible for you to upload some .pngs of the boards and schematics to the repo?

[serisman]

This also might be a nice trick to make a real cheap programmer for the flash variants (e.g. using the 5V of Arduino and a 2 resistor voltage divider to have a second voltage to enter programing mode)

JS, that sounds pretty neat.  Would this approach work for all the flash based parts, or only the newer ones?  For now, because of availability and cost, I find the PFS154 and PFS173 to be more interesting than the PFS172 which isn't currently stocked at lcsc.

Also, do you know the current status of the PMS152 when used with the easy-pdk-programmer?  Is it still read-only, or has the write mode been written/tested?  The PCS152-S16 is currently the cheapest 16-pin variant on lcsc and I was thinking of picking some up in addition to the flash variants if they are likely to work.

[spth]

spth:  I was looking at this repo yesterday and found myself desiring to see a preview of these boards.  Maybe there is one somewhere and I just didn't see it?  I'm not even sure what to do with the .sch and .lht files to generate my own.  (What tool are those files for?)  Would it be possible for you to upload some .pngs of the boards and schematics to the repo?

Tools are noted in the README:

Tools used:

* gschem for the schematic (symbols used to be found in pdk-gschem-symbols repository)
* pcb-rnd for the pcb design

So far I have not added any generated files (I am still unsure if the repo should contain sources only vs. also some genrated files). Would adding some photographs of the assembled boards help (even though it would show how bad I am at hand-soldering)?

[coppice]

Padauk is not making any money selling the programmer, so why don't ask them for the programming protocol?

Companies are reluctant to publish information that might want to change at any time. If they want to alter the silicon, maybe to change fabs or for a die shrink, and change the protocol, its a nightmare trying to deal with an open ended set of tools.

Adding support for  universal programmers like TL866 can help sell tons of 3cent microcontrollers.

Nobody buys a ton of parts and programs them with a tool like the TL866. People only program handfuls with a TL866, and nobody gets rich selling 3 cent parts by the handful.

[serisman]

Would adding some photographs of the assembled boards help (even though it would show how bad I am at hand-soldering)?

Yes, photos of the boards would help a lot!  If possible, a screenshot of the schematics would also help.  Having both of these would allow people to review/troubleshoot without downloading files and opening them in an external program.