EEVblog #1144 - Padauk Programmer Reverse Engineering

[jacola]

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_]

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_]

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_]

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]

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_]

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]

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.

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]

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]

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]

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)?

(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]

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]

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]

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]

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]

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]

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]

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_]

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_]

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_]

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_]

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.