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

0 Members and 1 Guest are viewing this topic.

Offline tim_

  • Regular Contributor
  • *
  • Posts: 162
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1225 on: October 05, 2020, 08:21:34 pm »
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
}
« Last Edit: October 05, 2020, 08:25:56 pm by tim_ »
 
The following users thanked this post: daveatol, serisman

Offline serisman

  • Regular Contributor
  • *
  • Posts: 94
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1226 on: October 05, 2020, 08:33:50 pm »
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.
« Last Edit: October 05, 2020, 08:38:21 pm by serisman »
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 162
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1227 on: October 05, 2020, 08:53:02 pm »
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.
 

Offline serisman

  • Regular Contributor
  • *
  • Posts: 94
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1228 on: October 05, 2020, 09:01:55 pm »
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.
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 162
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1229 on: October 05, 2020, 09:03:05 pm »
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.
« Last Edit: October 05, 2020, 09:14:40 pm by tim_ »
 
The following users thanked this post: js_12345678_55AA

Offline pacmancoder

  • Contributor
  • Posts: 5
  • Country: ua
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1230 on: October 05, 2020, 10:17:09 pm »
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.
« Last Edit: October 05, 2020, 10:20:59 pm by pacmancoder »
 
The following users thanked this post: js_12345678_55AA

Offline serisman

  • Regular Contributor
  • *
  • Posts: 94
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1231 on: October 06, 2020, 01:38:18 am »
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.
« Last Edit: October 06, 2020, 01:47:30 am by serisman »
 
The following users thanked this post: tim_

Offline spth

  • Regular Contributor
  • *
  • Posts: 135
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1232 on: October 06, 2020, 06:08:43 am »
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.
 

Offline spth

  • Regular Contributor
  • *
  • Posts: 135
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1233 on: October 06, 2020, 06:25:27 am »
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>
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 254
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1234 on: October 08, 2020, 04:57:57 pm »
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
Easy PDK programmer and more: https://free-pdk.github.io
 
The following users thanked this post: tim_

Offline tim_

  • Regular Contributor
  • *
  • Posts: 162
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1235 on: October 08, 2020, 05:48:03 pm »
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?
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 254
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1236 on: October 09, 2020, 11:36:54 am »
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  ;D (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 ;D

...
  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.



« Last Edit: October 09, 2020, 07:14:46 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 
The following users thanked this post: tim_

Offline tim_

  • Regular Contributor
  • *
  • Posts: 162
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1237 on: October 13, 2020, 05:46:58 am »
PFS173: VDD=5.7V, SYSCLOCK=16MHZ, CALIBRATED to 24MHZ  ;D (the higher VDD seems to make a huge difference, @5.0V max was 18Mhz):

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

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

Offline tim_

  • Regular Contributor
  • *
  • Posts: 162
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1238 on: November 07, 2020, 07:38:09 am »
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.
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 162
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1239 on: November 07, 2020, 07:48:20 am »
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.



 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1254
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1240 on: November 07, 2020, 08:00:34 am »
Please try to add more industrial grade parts to the supported list, Parts with -40 to 85C working temp
I'm a Digital Expert from 8-bits to 64-bits
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 162
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1241 on: November 17, 2020, 09:01:00 pm »
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.

« Last Edit: November 17, 2020, 09:38:09 pm by tim_ »
 
The following users thanked this post: ali_asadzadeh, serisman

Offline LovelyA72

  • Contributor
  • Posts: 26
  • Country: us
  • Kashikoma from Massachusetts!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1242 on: November 25, 2020, 06:10:02 pm »
Their FT16F01x series is basically PIC16F648. They might even binary compatible with eachother.
Kashikoma!
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf