Author Topic: EEVblog #1144 - Padauk Programmer Reverse Engineering (Read 638424 times)

jacola · « **Reply #1475 on:** August 28, 2023, 09:44:28 pm »

well, pretty much quiet here .. seems padauks are not in favor any more

I have put out a 500$ bounty for the PFS132 support ..

https://app.bountysource.com/issues/123829632-pfs132-support

Cheers

Johannes

tim_ · « **Reply #1476 on:** August 29, 2023, 04:59:11 am »

Seems that Padauk is realigning their strategy:

https://www.digitimes.com/news/a20230814PD207/consumer-electronics-mcu.html

Could mean that they are looking into more complex and/or very specialized products. In any case, there seems to be reduced focus on ultra-low-cost MCU.

tim_ · « **Reply #1477 on:** August 29, 2023, 05:08:54 am »

Quote from: jacola on August 28, 2023, 09:44:28 pm

well, pretty much quiet here .. seems padauks are not in favor any more
I have put out a 500$ bounty for the PFS132 support ..

https://app.bountysource.com/issues/123829632-pfs132-support

Cheers

Johannes

It seems the PFS123 is a direct replacement for the discontinued PFS173, but with a capacitance based ADC instead of resistor based. PFS173 is already supported. The amount of memory and periphery seems to be basically the same.

The section in the datasheet about the programming is identical for both devices. I'd guess there is a high likelyhood that the programming algorithm is the dame for both devices and only the deviceid needs to be changed. Have you already tried something in that direction.

tim_ · « **Reply #1478 on:** August 29, 2023, 05:24:30 am »

Ok, i realized you were asking for PFS132, not PFS123.

The PFS132 is indeed a bit different, although the programming instructions are the same as for PFS123/PFS173. Possibly using the PFS173 programming algorithm still works when changing chipid and adjusting for different memory size?

crossbound · « **Reply #1479 on:** October 17, 2023, 01:49:45 am »

Just my little contribution at this time. I have been working on a breakout board and programmer riser design for the EasyPDK programmer. The breakout board features a pad on the bottom side for a decoupling capacitor and the top has a place for an LED and current limiting resistor connected to PA4. Pads are designed in such a way that 1206, 0805, or 0603 components can be used.
There will be two different versions of the gerber files, one that has a single board and riser, the other is panelized with mouse bites that will yield 15 breakout boards and 5 risers per panel. Dimensions of the panel is such that it will allow for ordering 5 panels for $2 on JLCPCB.
If anyone is interested I'll upload the gerbers to Github. Will be ordering a set for myself soon to verify.

tim_ · « **Reply #1480 on:** October 17, 2023, 05:08:39 am »

Looks really neat! 0'1" less wide and you would not need the riser.

But then, no place for silk screen...

Btw, which PCB layout program did you use?

crossbound · « **Reply #1481 on:** October 17, 2023, 02:50:33 pm »

Thank you.. I tried getting the header closer in to avoid using a riser, but unfortunately they would end up touching the pads for the MCU..

Kicad is my software of choice. I did play around with EasyEDA, but it was not for me. I do however like the integration with LCSC for picking the parts.

Quote from: tim_ on October 17, 2023, 05:08:39 am

Looks really neat! 0'1" less wide and you would not need the riser. But then, no place for silk screen...

Btw, which PCB layout program did you use?

HwAoRrDk · « **Reply #1482 on:** January 10, 2024, 04:42:52 pm »

Can anyone give me some insight into how the 16-bit timer on Padauk MCUs works?

What I want to do is create a timeout timer of around 500 msec. I've figured I can do this by setting the T16 clock source to SYSCLK (which will be IHRC/16 = 1 MHz), dividing by 16 for 62.5 kHz tick rate, then setting the interrupt source to be bit 15 of the counter (count of 32,768). This should give me a timeout period of approximately 524 msec, which is good enough for my purposes.

But, I only want to enable this timeout timer on-demand, and wait for either an I/O pin to toggle or the timeout to expire (i.e. I don't want something to repeat every 500 msec).

I'm thinking there's two potential ways I can go about this. When I want to start the timeout, I could either:

- Reset the timer counter to zero, then enable the interrupt for T16 (INTEN |= INTEN_T16). Disable the interrupt at all other times.
- Enable T16 by setting its clock source, hopefully the counter is reset to zero whenever the timer is re-enabled. Keep T16 disabled (i.e. T16M_CLK_DISABLE) at all other times. Interrupt is enabled at all times.

The first method is difficult because the T16 counter can only be written or read with specific assembly instructions, STT16 and LDT16, and these instructions only read/write from/to a fixed memory address. To reset the counter to zero, I would have to do something like declare a global variable with a value of zero, then use inline assembly to write that value to the counter.

Code: [Select]

static uint16_t t16_reset_val = 0;

/* Wherever I need to reset T16 counter: */
__asm__("stt16 _t16_reset_val\n");

Also, the Free-PDK website detailing the PDK13 instruction set says that the memory address for STT16 and LDT16 must be word-aligned. I don't know how to ensure that with SDCC, or if it's even possible.

The second method, I don't know if the counter value gets reset whenever the T16 is disabled/enabled. If it does, this approach would work, but if not it's not viable. Anyone know?

spth · « **Reply #1483 on:** January 12, 2024, 08:57:59 am »

If you want to set the timer to 0, why not just do so?

Code: [Select]

__sfr16 timercnt;

void f(void)
{
	timercnt = 0;
}

SDCC doesn't have much support for alignment yet, and support for the 16-bit timer is quite incomplete (some stuff, in particular setting the counter to a small value, works), but it should always either generate correct code or give an error message.

HwAoRrDk · « **Reply #1484 on:** January 12, 2024, 05:31:29 pm »

Quote from: spth on January 12, 2024, 08:57:59 am

If you want to set the timer to 0, why not just do so?

Haha, yeah, I subsequently found that myself just yesterday.

I previously saw the definition for T16C in the Free-PDK headers for a __sfr16 but with no address (i.e. no __at()) and thought that was odd and perhaps some vestigial thing. But then I found it is actually used in some example code. I couldn't comprehend how that worked, so I went looking in the SDCC code for how the stt16 instruction was emitted.

Am I interpreting this code correctly, or is SDCC hard-coded to handle this specially? Does it just assume that any assignment of a literal value to any __sfr16 should be translated to a stt16 instruction loading from pseudo-register p? That seems a bit of a hack...

I suppose technically there are no 16-bit peripheral or CPU registers, so this is a fairly safe assumption to make, but what happens if someone attempts to use __sfr16 to access a contiguous pair of high/low registers on a peripheral (e.g. PWM generator)?

Quote from: spth on January 12, 2024, 08:57:59 am

(some stuff, in particular setting the counter to a small value, works)

Yes, I note that it only works assigning values 0-255, which is unfortunate, because I need to assign a value greater than that.

Will still need to use the global variable method. Or maybe I will try writing some inline assembly to use p, given that is implicitly guaranteed to be at a word-aligned address.

spth · « **Reply #1485 on:** January 12, 2024, 07:42:35 pm »

Yes, the 16-bit timer counter is the only 16-bit I/O location, so _sfr16 is considered to always mean the 16-bit timer counter.

The pseudoregister p is used as an 8-bit register followed by a 0x00 byte. So it cannot be used to write values larger than 255.

HwAoRrDk · « **Reply #1486 on:** January 14, 2024, 06:57:45 pm »

Anybody got any idea what's up with this Padauk app note regarding programming of PMS150G chips?

It seems like they're saying that for the PMS150G you need to add a 100 ohm resistor in series between the chip and the programmer on the PA5 line. They detail bodging some kind of adapter board that plugs in to a header on the back of the official Padauk programmer (and indeed, the latest versions of which apparently come with a proper adapter).

Does this seem like it would be applicable or necessary for programming the PMS150G with the Easy-PDK programmer?

I think they're just trying to add some over-voltage transient suppression to avoid damage to the IC when used in automated programming machines with long wires running from the programmer, because I think as PA5 is the VPP pin, it has no upper input protection diode. Indeed, even in the datasheet they say "Please put 33Ω resistor in series to have high noise immunity when this pin is in input mode".

HwAoRrDk · « **Reply #1487 on:** January 22, 2024, 08:10:16 am »

Frustratingly, the latest released binaries of the Easy-PDK programmer software on the GitHub repository are only for the older v1.3, so they are missing support for many more recent Padauk MCU models (e.g. PMS150G). Support for these have only been added in the "development" branch of the software (which is essentially v1.4), so if you want that you have to build the software yourself.

I wanted to build the Windows binary, but for most *nix-centric software actually doing so on Windows itself is usually a clusterfuck (authors typically expect an environment with all sorts of nonsense like cygwin, msys, etc.), so it's nearly always much, much easier to cross-compile on Linux.

In case anyone else at some point wants to do the same, I figured out how:

1. Download (and unzip) or Git clone the "development" branch: https://github.com/free-pdk/easy-pdk-programmer-software/tree/development
2. If not already available, install the MinGW development tools (e.g. sudo apt-get install mingw-w64 on a Debian-based system).
3. Build the included argp-standalone library (from within lib/argp-standalone-1.3 folder): ./configure --host=x86_64-w64-mingw32 CFLAGS='-w -Os' && make
4. Finally, build easypdkprog: make CC=x86_64-w64-mingw32-gcc EPDKVER=1.4 ECFLAGS=-Ilib/argp-standalone-1.3 ARGPSALIB=lib/argp-standalone-1.3/libargp.a EXE_EXTENSION=.exe

KaeTo · « **Reply #1488 on:** February 18, 2024, 01:39:31 pm »

Hello,

I have a problem with the PMS150C regarding the bandgap. Maybe somebody here can help me or at least verify my observed behavior.
When I do the bandgap calibration for PMS150C-SO8 everything is okay. I get a calibration result != 0 and the bandgap behaves as expected. When I use my PMS150C-U6 chips I get a result of 0x00 and the bandgap is way of. Has anyone else seen this behavior with the U6 (SOT23-6) variant or could verify it, if you get the same calibration result.
At the moment my suggestion would be, that I got a bad batch.

Thank you

spth · « **Reply #1489 on:** March 11, 2024, 07:53:57 am »

Padauk has been discontinuing and introducing devices, and the free programmer hasn't gotten support for new devices in a while.
How can we restart the process of getting support for more devices? Is anyone with experience in adding support for additional devices still active?

crossbound · « **Reply #1490 on:** March 29, 2024, 12:25:21 am »

I realize that most people have moved on from this thread, but I still wanted to add a redesign of the EasyPDK programmer I did. Just to give back a little something to this community. It's called the PurplePDK programmer and is based on the easy-pdk-lite programmer.
The github repository can be found at https://github.com/cross-bound/PurplePDK

Enjoy

Bug191 · « **Reply #1491 on:** April 08, 2024, 01:26:28 pm »

Hi I am new to Padauk and am currently working with pfs154 for my final project in uni.

I need some help with going to deep sleep and waking up. Currently I am trying to get IC to go to deep sleep and wake up on interrupt on pin PA0. After wakeup I set pin PA3 to HIGH to verify that IC is not still in sleep. When I do this it successfully goes to sleep (verified with current draw of only a few uA) but after I bring rising edge to pin PA0 for wakeup it doesnt do anything for about few seconds and then if gives me square wave on pin PA3 instead of just HIGH. After that it shuts down again going to few uA of current draw. I even added capacitor to VDD (5V) to make sure there is enough current for fast wakeup.

I attached my code below.

Please help

tim_ · « **Reply #1492 on:** April 24, 2024, 04:44:56 am »

Quote from: Bug191 on April 08, 2024, 01:26:28 pm

Hi I am new to Padauk and am currently working with pfs154 for my final project in uni.

I need some help with going to deep sleep and waking up.

Not exactly sure about your specific issue. Have you looked this example?
https://cpldcpu.wordpress.com/2021/02/07/ultra-low-power-led-flasher/

I recall I rather had issue not to wake up the device due to noise on the pins.

tim_ · « **Reply #1493 on:** April 24, 2024, 04:57:01 am »

Quote from: spth on March 11, 2024, 07:53:57 am

Padauk has been discontinuing and introducing devices, and the free programmer hasn't gotten support for new devices in a while.
How can we restart the process of getting support for more devices? Is anyone with experience in adding support for additional devices still active?

Are there any notable new devices that can actually be bought publically? e.g. at LCSC?

tim_ · « **Reply #1494 on:** May 03, 2024, 12:49:07 am »

I did something on the Padauks again:

https://github.com/cpldcpu/BitNetPDK

Apologies if it is not terribly useful. It's one of those things that had to be done, because they were possible.

tim_ · « **Reply #1495 on:** October 13, 2024, 04:38:28 am »

A new OTP device was introduced. This looks like a very cheap OTP MCU for LED control.
Functionality looks like it was inherited from the PFS154, but there is less memory.

https://www.padauk.com.tw/en/product/show.aspx?num=165&kind=41

Unfortunately, as all the other new devices, it is not listed at LCSC. $:-\$

PetersDirk · « **Reply #1496 on:** June 11, 2025, 10:48:25 am »

I'm late but now I want to start with this chips

I build me a Free PDK and install the firmware from https://github.com/free-pdk/easy-pdk-programmer-software/tree/master/Firmware. It should work with Windows version from https://github.com/free-pdk/easy-pdk-programmer-software/releases/tag/1.3 and if I "probe" a chip I returned the data.
Unfortunately I have PFS122 and PFC161. I read that the PFS122 should work as a 172 (https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/msg4581304/#msg4581304). That's all fine

Now I'm searching for a firmware which supports more chips. My can:

Code: [Select]

 MCU390   (0xC31): OTP  : 2048 (14 bit), RAM: 128 bytes (RO)
 PFS154   (0xAA1): FLASH: 2048 (14 bit), RAM: 128 bytes
 PFS172   (0xCA6): FLASH: 2048 (14 bit), RAM: 128 bytes
 PFS173   (0xEA2): FLASH: 3072 (15 bit), RAM: 256 bytes
 PMC131   (0xC83): OTP  : 1536 (14 bit), RAM:  88 bytes (RO)
 PMC251   (0x058): OTP  : 1024 (16 bit), RAM:  59 bytes (RO)
 PMC271   (0xA58): OTP  : 1024 (16 bit), RAM:  64 bytes (RO)
 PMS131   (0xC83): OTP  : 1536 (14 bit), RAM:  88 bytes (RO)
 PMS132   (0x109): OTP  : 2048 (14 bit), RAM: 128 bytes (RO)
 PMS132B  (0x109): OTP  : 2048 (14 bit), RAM: 128 bytes (RO)
 PMS133   (0xC19): OTP  : 4096 (15 bit), RAM: 256 bytes (RO)
 PMS134   (0xC19): OTP  : 4096 (15 bit), RAM: 256 bytes (RO)
 PMS150C  (0xA16): OTP  : 1024 (13 bit), RAM:  64 bytes
 PMS152   (0xA27): OTP  : 1280 (14 bit), RAM:  80 bytes
 PMS154B  (0xE06): OTP  : 2048 (14 bit), RAM: 128 bytes
 PMS154C  (0xE06): OTP  : 2048 (14 bit), RAM: 128 bytes
 PMS15A   (0xA16): OTP  : 1024 (13 bit), RAM:  64 bytes
 PMS171B  (0xD36): OTP  : 1536 (14 bit), RAM:  96 bytes
 PMS271   (0xA58): OTP  : 1024 (16 bit), RAM:  64 bytes (RO)

I found this one: https://github.com/cjacker/opensource-toolchain-padauk/tree/main/easypdkprogrammer But this did not work ("Error: Programmer protocol mismatch - Please update programmer firmware.").
Is there a new Windows Version of easypdkprog.exe with works with the new Firmware?

Thank you.

spth · « **Reply #1497 on:** June 16, 2025, 10:53:06 am »

Code: [Select]

easypdkprog list using easypdkprog built from current git master (on Debian GNU/Linux) gives me:

Code: [Select]

Supported ICs:
 MCU390   (0xC31): OTP  : 2048 (14 bit), RAM: 128 bytes (RO)
 PFC151   (0xCA7): FLASH: 2048 (14 bit), RAM: 128 bytes 
 PFC154   (0x34A): FLASH: 2048 (14 bit), RAM: 128 bytes 
 PFC161   (0xCA7): FLASH: 2048 (14 bit), RAM: 128 bytes 
 PFC232   (0xBA8): FLASH: 2048 (14 bit), RAM: 128 bytes 
 PFS121   (0xCA6): FLASH: 2048 (14 bit), RAM: 128 bytes 
 PFS122   (0xCA6): FLASH: 2048 (14 bit), RAM: 128 bytes 
 PFS123   (0xD44): FLASH: 3072 (15 bit), RAM: 256 bytes 
 PFS154   (0x542): FLASH: 2048 (14 bit), RAM: 128 bytes 
 PFS172   (0xCA6): FLASH: 2048 (14 bit), RAM: 128 bytes 
 PFS172B  (0xCA6): FLASH: 2048 (14 bit), RAM: 128 bytes 
 PFS173   (0xD44): FLASH: 3072 (15 bit), RAM: 256 bytes 
 PFS173B  (0xD44): FLASH: 3072 (15 bit), RAM: 256 bytes 
 PMC131   (0xC83): OTP  : 1536 (14 bit), RAM:  88 bytes (RO)
 PMC251   (0x058): OTP  : 1024 (16 bit), RAM:  59 bytes (RO)
 PMC271   (0xA58): OTP  : 1024 (16 bit), RAM:  64 bytes (RO)
 PMS131   (0xC83): OTP  : 1536 (14 bit), RAM:  88 bytes (RO)
 PMS132   (0x109): OTP  : 2048 (14 bit), RAM: 128 bytes (RO)
 PMS132B  (0x109): OTP  : 2048 (14 bit), RAM: 128 bytes (RO)
 PMS133   (0xC19): OTP  : 4096 (15 bit), RAM: 256 bytes (RO)
 PMS134   (0xC19): OTP  : 4096 (15 bit), RAM: 256 bytes (RO)
 PMS150C  (0xA16): OTP  : 1024 (13 bit), RAM:  64 bytes 
 PMS150G  (0x639): OTP  : 1024 (13 bit), RAM:  64 bytes 
 PMS152   (0xA27): OTP  : 1280 (14 bit), RAM:  80 bytes 
 PMS154B  (0xE06): OTP  : 2048 (14 bit), RAM: 128 bytes 
 PMS154C  (0xE06): OTP  : 2048 (14 bit), RAM: 128 bytes 
 PMS15A   (0xA16): OTP  : 1024 (13 bit), RAM:  64 bytes 
 PMS15B   (0x639): OTP  : 1024 (13 bit), RAM:  64 bytes 
 PMS171B  (0xD36): OTP  : 1536 (14 bit), RAM:  96 bytes 
 PMS271   (0xA58): OTP  : 1024 (16 bit), RAM:  64 bytes (RO)

PetersDirk · « **Reply #1498 on:** June 27, 2025, 09:09:33 am »

I use windows and not Linux and it will be fine if I can find a newer Tool.

PetersDirk · « **Reply #1499 on:** June 30, 2025, 11:46:20 am »

Hello

No one can help me?
Which is the actual version? Where can I find it? On github is only 1.3 Where can I find an actual .dfu firmware?


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: EEVblog #1144 - Padauk Programmer Reverse Engineering (Read 638424 times)

Share me