EEVblog #1144 - Padauk Programmer Reverse Engineering

[tim_]

Oh wow, nice find, JS! So instead of spending much time with a complicated power-on-reset they implemented it in software. You got to admire the ingenuity of the paudauk designer, but that was quite a trap.

Now the PFS173 also works with my power supply, I verified in the scope picture below. Channel2 is connected to PB0, which will output a single pulse at the beginning of the program before setting of LVS and oscillator.
The CPU starts executing at VCC=2V (ch1) and keeps resetting until 4V is reached. Then it does indeed execute at 8 MHz in a stable way.

We should somehow introduce this as a standard include because it is a very annoying pitfall.

Code: [Select]

unsigned char _sdcc_external_startup(void)
{
PBC=BIT0;
PB=BIT0;
PB=0;
MISCLVR = MISCLVR_4V;

CLKMD = CLKMD_IHRC_DIV2 | CLKMD_ENABLE_IHRC;  // 16/2=8 Mhz main clock
EASY_PDK_CALIBRATE_IHRC(F_CPU, 5000); // tune SYSCLK to 9.6MHz @ 5.00V
return 0; // perform normal initialization
}


[serisman]

Oh wow, nice find, JS!

Yes, agreed... nice find JS!  And thanks for the visualization tim_!

This probably explains some weirdness I was also seeing where things weren't always starting properly when I was using a bench PSU.  I kept thinking I had a bug somewhere in my code, although it always seemed to work if I manually disconnected and re-connected power instead of just using the PSU's on/off button.  I'll have to dig that project back out and see if this code change fixes it.

The CPU starts executing at VCC=2V (ch1) and keeps resetting until 4V is reached. Then it does indeed execute at 8 MHz in a stable way.

According to the datasheets I just checked, we should be able to achieve 8 MHz down to 3.5V.  Can you verify things are still stable with a lower LVR?

We should somehow introduce this as a standard include because it is a very annoying pitfall.

I'll add it to the appropriate free-pdk-examples later today.

[tim_]

According to the datasheets I just checked, we should be able to achieve 8 MHz down to 3.5V.  Can you verify things are still stable with a lower LVR?

The PFS173 I have been using for testing worked down to 2.35V at 8MHz. I suppose that should not be taken for granted as it will change with higher temperature and device to device variation.
I guess 3.5V is safe.

[serisman]

According to the datasheets I just checked, we should be able to achieve 8 MHz down to 3.5V.  Can you verify things are still stable with a lower LVR?

The PFS173 I have been using for testing worked down to 2.35V at 8MHz. I suppose that should not be taken for granted as it will change with higher temperature and device to device variation.
I guess 3.5V is safe.

Here is what I found so far (by parsing the datasheets):

Code: [Select]

DEVICE:           PFS154         PFS172  PFS173  PMS150C PMS152  PMS154C PMS171B
MISCLVR or FUSE:  MISCLVR(basic) MISCLVR MISCLVR FUSE    MISCLVR FUSE    MISCLVR
>= 8 MHz needs >= 3.5V           3V      3.5V    3V      3.5V    3.5V    3V
>= 4 MHz needs >= 2.5V           2.2V    2.5V    2.2V    2.5V    2.5V    2.2V
>= 2 MHz needs >= 2V             1.8V    2.2V    2V      1.8V    1.8V    1.8V

Unfortunately, I'm not sure there is enough similarity between devices to make a standard include for this.  I was thinking of something similar to the AUTO_INIT_SYSCLOCK() macros from free-pdk-examples/include/auto_sysclock.h.  It looks like 3.5V would work across the board for all devices even though some only seem to need 3V.  But the bigger problem is that the MISCLVL register is also used for other things, and sometimes LVR needs to be set by a FUSE instead of the MISCLVR register.

[tim_]

Interesting, it seems now also the undocumented clk setting can be used to activate 16 MHz in the PFS173:

Code: [Select]

unsigned char _sdcc_external_startup(void)
{
MISCLVR = MISCLVR_4V;

CLKMD = CLKMD_IHRC | CLKMD_ENABLE_IHRC;  // 16 Mhz main clock
PDK_USE_FACTORY_IHRCR_16MHZ();

return 0; // perform normal initialization
}

My 8 MHz blinky is twice as fast, so it seems to work. I never tried it before, maybe it worked all along?

Edit: Minimum voltage for 16 MHz is 3.9V. So I suppose that it is quite marginal and even 5V might fail at higher temperatures. I guess that is why they did not document this setting.

[pacmancoder]

Looks like my concerns about using p registers were right.
I have tried to perform ldt16/stt16 with the p register in __asm__ block, but my program started to work abnormally. After further investigation, I found out that sdcc ignores fact that p virtual register is overriten by the custom asm code. For example, I have the following fucntion (this example with stt16, it is broken the same way ldt16 do):

Code: [Select]

#define __stt16(var) __asm__("mov a, "_STR_VAR(var)"\n"\
    "mov p, a\n"\
    "mov a, "_STR_VAR(var)"+1\n"\
    "mov p+1, a\n"\
    "stt16 p\n");
// ....
static uint16_t tm16Value = 0;

void reset_timer16_counter(void) {
    uint8_t timerMode = T16M;
    T16M = T16M_CLK_DISABLE;
    __stt16(tm16Value);
    T16M = timerMode;
}

The asm code generated for this function is the following:

Code: [Select]

0x004c:   0x0186    MOV A, IO(0x06)  ;T16M
0x004d:   0x1700    MOV [0x00], A     ; <---- sdcc uses p as local variable storage
0x004e:   0x5700    MOV A, 0x00
0x004f:   0x0106    MOV IO(0x06), A  ;T16M
0x0050:   0x1f02    MOV A, [0x02]
0x0051:   0x1700    MOV [0x00], A     ; <---- value overwritten by the __asm__ block
0x0052:   0x1f03    MOV A, [0x03]
0x0053:   0x1701    MOV [0x01], A
0x0054:   0x0600    STT16 [0x00]
0x0055:   0x1f00    MOV A, [0x00]      ; <---- restored wrong value
0x0056:   0x0106    MOV IO(0x06), A  ;T16M
0x0057:   0x007a    RET

If I add additional context saving for __asm__ block, everything is working normally.

So for now, the most usable way of using ldt16/stt16 is to make sdcc to place uint16_t variables to the word aligned address by placing as the first items in the first translation unit as JS suggested, or by introducing the additional single byte variables before ldt16/stt16 operand variables if their address is non-aligned.

[serisman]

I just finished up and published another Padauk related project... a temperature controlled 4-pin PWM fan controller: https://github.com/serisman/pdk-temp-pwm-fan/

I needed this for a UPS that was converted to run on a much larger battery, and therefore have a much longer run-time.  The problem with longer run-time is that the original design assumed it wouldn't be running for long enough to worry about heat dissipation, so adding a fan was a must.  Since it will be in bypass mode 99.99% of the time, I didn't want to run the fan at a full 100% all the time (waste of power and noisy).

So, this circuit and firmware were whipped up to be able to run the fan at a minimum setting until cooling capacity is actually needed.

Temperature measurement is performed by using a 10k NTC thermistor between 5V VCC and a 1K resistor to GND.  The output of this voltage divider is connected to the COMP+ pin, and the COMP- pin is connected to the internal voltage source that can be set between GND and 1/2 VCC in 16 steps.  So... not the most precise temperature measurement, but works fine on the '3 cent' 6-pin PMS150C, and good enough for the crude temperature control I needed!

Originally, I had attempted to build this to control a 3-pin (non-PWM) fan, but wasn't happy with the performance so I switched to the 4-pin PWM fan which is much easier to control and has much better performance (i.e. it can go to slower speeds, lower noise, more efficient).  The fan I wanted to use was a 4-pin anyway, so no real loss.  I may re-approach the 3-pin design at a future time, because I could see it being handy as well.

As usual, PCB design and gerber files are available on the GitHub project page.

[spth]

Interesting, it seems now also the undocumented clk setting can be used to activate 16 MHz in the PFS173:

[…]

My 8 MHz blinky is twice as fast, so it seems to work. I never tried it before, maybe it worked all along?

Edit: Minimum voltage for 16 MHz is 3.9V. So I suppose that it is quite marginal and even 5V might fail at higher temperatures. I guess that is why they did not document this setting.

Historically, many datasheets mentioned a 16 MHz setting, but by now, it apparently has been removedf rom all (and any time I asked Padauk about contradictionary information regarding it in diffeerent sections of a datasheet, the resolution was removal of the 16 MHz setting). I suspect that it didn't work reliably in some way.

[spth]

Thanks JS, But there is a wired error at compile time!

what's going on wrong?

To use uint32_t, you need to

Code: [Select]

#include <stdint.h>

[js_12345678_55AA]

Hi,

I added automatic LVR setup for high clock rates to the Examples folder of the easy-pdk-programmer-software *development branch*.

=> https://github.com/free-pdk/easy-pdk-programmer-software/tree/development/Examples/src  and defines in "easypdk" folder there.

Now when you use EASY_PDK_INIT_SYSCLOCK_8MHZ() it will automatically set the correct LVR value for the IC (either via MISCLVR register or via FUSE).


JS

[tim_]

I added automatic LVR setup for high clock rates to the Examples folder of the easy-pdk-programmer-software *development branch*.

=> https://github.com/free-pdk/easy-pdk-programmer-software/tree/development/Examples/src  and defines in "easypdk" folder there.

Nice! I noticed you also added 16 MHz at 4 Volt for the PFS154 and at 4.5V for the PFS173. Does it mean that the PFS154 is more stable at 16V than the PFS173?

[js_12345678_55AA]

Nice! I noticed you also added 16 MHz at 4 Volt for the PFS154 and at 4.5V for the PFS173. Does it mean that the PFS154 is more stable at 16V than the PFS173?

It does not mean anything. 4V was just the highest value available for PFS154 and I just used the highest possible LVR value for 16MHz... most likely it will not work reliable. Time / experiments will tell.

JS.

EDIT: I did some overclocking speed tests (not sure how stable this is, just the calibration loop).

Hi-Scores:

PFS173: VDD=5.7V, SYSCLOCK=16MHZ, CALIBRATED to 24MHZ  (the higher VDD seems to make a huge difference, @5.0V max was 18Mhz):

...
  EASY_PDK_INIT_SYSCLOCK_16MHZ();                //use 16MHz sysclock
  EASY_PDK_CALIBRATE_IHRC(24000000,5700);        //tune SYSCLK to 24MHz @ 5.700V
...


Searching programmer... found: /dev/tty.usbmodem1234567855AA1
FREE-PDK EASY PROG - HW:1.2 SW:1.3 PROTO:1.3
Erasing IC... done.
Blank check IC... done.
Writing IC (186 words)... done.
Verifiying IC... done.
Calibrating IC
* IHRC SYSCLK=24000000Hz @ 5.70V ... calibration result: 24199035Hz (0x9F)  done.

----------------

PFS154: VDD=5.9V, SYSCLOCK=16MHZ, CALIBRATED TO 23MHZ

...
  EASY_PDK_INIT_SYSCLOCK_16MHZ();                //use 16MHz sysclock
  EASY_PDK_CALIBRATE_IHRC(23000000,5900);        //tune SYSCLK to 23MHz @ 5.900V
...


Searching programmer... found: /dev/tty.usbmodem1234567855AA1
FREE-PDK EASY PROG - HW:1.2 SW:1.3 PROTO:1.3
Erasing IC... done.
Blank check IC... done.
Writing IC (186 words)... done.
Verifiying IC... done.
Calibrating IC
* IHRC SYSCLK=23000000Hz @ 5.90V ... calibration result: 23088037Hz (0x9E)  done.

[tim_]

PFS173: VDD=5.7V, SYSCLOCK=16MHZ, CALIBRATED to 24MHZ  (the higher VDD seems to make a huge difference, @5.0V max was 18Mhz):

PFS154: VDD=5.9V, SYSCLOCK=16MHZ, CALIBRATED TO 23MHZ

Searching programmer... found: /dev/tty.usbmodem1234567855AA1
FREE-PDK EASY PROG - HW:1.2 SW:1.3 PROTO:1.3
Erasing IC... done.
Blank check IC... done.
Writing IC (186 words)... done.
Verifiying IC... done.
Calibrating IC
* IHRC SYSCLK=23000000Hz @ 5.90V ... calibration result: 23088037Hz (0x9E)  done.

Nice! Looks like the oscillator can be trimmed to run at even higher frequency. Time to bring out the LN2 cooling for serious overclocking

[tim_]

No activity here for quite some time?  Some updates that I am aware of:

* There are two nice new projects with the PFS154 by Ralph S. on µC.net:

https://www.mikrocontroller.net/topic/505698
https://www.mikrocontroller.net/topic/506253

(Sorry, it's in german)

* Documentation of undocumented features in the Padauk MCUs:

https://free-pdk.github.io/undocumented-features

* The design files of the lite-version of the EasyPDKProgrammer are now here:

https://github.com/free-pdk/easy-pdk-programmer-lite-hardware

The documentation is still in progress, but the design works as is.

[tim_]

Also, philipp brought up that a few new devices were announced:

https://github.com/free-pdk/easy-pdk-programmer-software/issues

The PFS252 is the most interesting of the bunch

http://www.padauk.com.tw/en/news/show.aspx?num=219

It seems to be the first low cost device with two FPPAs.

Unfortunately LCSC seems to be very reluctant to pick up new devices from Padauk for their lineup, I asked them to no avail.
It's still not easy to obtain even the "older" new devices like PFS172.

[ali_asadzadeh]

Please try to add more industrial grade parts to the supported list, Parts with -40 to 85C working temp

[tim_]

Sooo, in case someone is looking for a new 8 bit MCU to reverse. There seems to be a a new chinese competitor to Padauks strategy, aptly named "Fremont Micro Devices". Of course, they are absolutely not based in Fremont. (Correction, they seem to have an office there, but it's not even listed on their homepage)

https://lcsc.com/products/Other-Processors-And-Microcontrollers-MCUs_11116.html?q=fremont%20micro%20devices
https://www.fremontmicro.com/en/product/mcu/index.aspx

They have a line up of flash based 8 bit microcontrollers. The cheapest one (FT60F210) is only $0.05, beating the PFS154. The documentation is a bit unclear whether they are really flash based, but there are several references. They don't look too exciting. The core is again PIC-related. One interesting feature is integrated EEPROM. They also have slightly more complex periphery than Padauk in the larger devices.

The programming interface seems to be low voltage, which is interesting. A big caveat is that the documentation only seems to be chines.

Well, it's not too interesting, as there are already Padauk MCUs.

edit: Okay, the MCU core is a PIC16 clone. The IDE actually comes with an ancient version of the Hi-tech C-compiler.

[LovelyA72]

Their FT16F01x series is basically PIC16F648. They might even binary compatible with eachother.

[pastaclub]

Hi, I'm trying to find out what I need to know about the pins of Padauk's OTP device if they are to be programmed AFTER PCB assembly, not before. The datasheet doesn't say that.

Obviously there are two aspects to it:
- the programming signals must not damage other components connected to the Padauk
- the other components must not interfere with the programming of the Padauk

This should be a non-issue for pins where for example push buttons are connected. But what about pins for example connected to the middle pin of a 5KOhms potentiometer between GND and VCC? Also, is VCC during programming something usual such as 3V3 or can it be way up which risks damaging other components?

I can imagine it could also be an option to have jumpers on the PCB which are manually closed after programming, but I would really need the information of which pins are concerned and what I need to know about them. Can you point me to that information?

[js_12345678_55AA]

Hi, I'm trying to find out what I need to know about the pins of Padauk's OTP device if they are to be programmed AFTER PCB assembly, not before. The datasheet doesn't say that.

Obviously there are two aspects to it:
- the programming signals must not damage other components connected to the Padauk
- the other components must not interfere with the programming of the Padauk

This should be a non-issue for pins where for example push buttons are connected. But what about pins for example connected to the middle pin of a 5KOhms potentiometer between GND and VCC? Also, is VCC during programming something usual such as 3V3 or can it be way up which risks damaging other components?

I can imagine it could also be an option to have jumpers on the PCB which are manually closed after programming, but I would really need the information of which pins are concerned and what I need to know about them. Can you point me to that information?

Hi,

From my experience interfering in any way with any of the programing signals always causes trouble during programing or in the tuning step.

VCC can be as high as 5.8V during programing (depending on IC, have a look at "fpdkicdata.c" in the programmer repository to find "vdd_write_hv" - which is usually the highest vdd during programing)

Suggestion: Even for production runs try to use FLASH parts (e.g. PFS173 is available in almost all packages - even 6 pin version - and does not cost a lot more than OTP variants, if you do not need the ADC and/or the "big" RAM then you also can use PFS154).


JS

[rameshd]

Here is a placement diagram for the original PDK programmer, which I had created a while back.
Hope it is still useful.

Ramesh

[socram]

Sooo, in case someone is looking for a new 8 bit MCU to reverse. There seems to be a a new chinese competitor to Padauks strategy, aptly named "Fremont Micro Devices". Of course, they are absolutely not based in Fremont. (Correction, they seem to have an office there, but it's not even listed on their homepage)

https://lcsc.com/products/Other-Processors-And-Microcontrollers-MCUs_11116.html?q=fremont%20micro%20devices
https://www.fremontmicro.com/en/product/mcu/index.aspx

They have a line up of flash based 8 bit microcontrollers. The cheapest one (FT60F210) is only $0.05, beating the PFS154. The documentation is a bit unclear whether they are really flash based, but there are several references. They don't look too exciting. The core is again PIC-related. One interesting feature is integrated EEPROM. They also have slightly more complex periphery than Padauk in the larger devices.

The programming interface seems to be low voltage, which is interesting. A big caveat is that the documentation only seems to be chines.

Well, it's not too interesting, as there are already Padauk MCUs.

edit: Okay, the MCU core is a PIC16 clone. The IDE actually comes with an ancient version of the Hi-tech C-compiler.

I got my hands on 50x FT60F211 thinking they would be compatible enough to be not only used with PIC development tools, but also being programmed with a PIC programmer, which would make them a much much easier to use alternative to Padauk. Sadly, when trying to read them as any kind of 8 pin PIC, my TL866CS complains that it's got an overcurrent issue. Oh well.

Maybe it would be interesting if there's more people willing to help to create a post for reverse engineering these too?

[socram]

Since I was interested, instead of hijacking this thread I've created a new one with all the information I've gathered so far: https://www.eevblog.com/forum/projects/fremont-micro-devices-microcontroller-programming/

Help is welcome!

[ali_asadzadeh]

Do we have a Verilog implementation of the CPU so it can be used in a FPGA and SDCC can be used for it

[tim_]

Since I was interested, instead of hijacking this thread I've created a new one with all the information I've gathered so far: https://www.eevblog.com/forum/projects/fremont-micro-devices-microcontroller-programming/

Help is welcome!

Nice, will check it out!

Looks like my order from LCSC with the controller was lost lost in transit, or rather delivered to someone else. oh well...