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

crossbound and 8 Guests are viewing this topic.

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1275 on: February 04, 2021, 03:37:45 pm »
Hi everyone:
Padauk IDE 0.91 version. It update PDK "29" version
Don't depdk it?

Where did you get the "PDK 29 version" information from? Is this you Kent Lee?  ::)

JS
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline vitohong

  • Newbie
  • Posts: 2
  • Country: tw
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1276 on: February 04, 2021, 04:10:10 pm »
for using PMS150G,I download IDE 0.91 version.
"opossum" tool at this forum. Show PDK 29
 

Offline homeworkboy

  • Contributor
  • Posts: 15
  • Country: tw
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1277 on: February 05, 2021, 12:48:27 am »
Hi JS:
code1: original
code2: oposum disassble
code3: your dispdk

 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1278 on: February 06, 2021, 10:59:24 pm »
Really.... ? ? ? ?

Self modifying code now in PADAUK IDE to "protect" the "obfuscation" and then the only "new" thing is xoring 4 different values from key and changing 0x12345678 to 0x123457AE ?

 :-DD

=> depdk / dispdk got support for IDE 0.91 pdk files (check github)

JS
Easy PDK programmer and more: https://free-pdk.github.io
 
The following users thanked this post: oPossum

Offline tim_

  • Regular Contributor
  • *
  • Posts: 237
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1279 on: February 07, 2021, 03:41:04 am »
Really.... ? ? ? ?

Self modifying code now in PADAUK IDE to "protect" the "obfuscation" and then the only "new" thing is xoring 4 different values from key and changing 0x12345678 to 0x123457AE ?

 :-DD

=> depdk / dispdk got support for IDE 0.91 pdk files (check github)

JS

One has to wonder what the point of trying to make the file format "more secure" is anyways. I have not seen anyone trying to use a custom programmer with the PADAUK IDE. Or don't they want us to decode future instuction sets? As long as the programming algorithm is not encrypted I don't see a chance there...

One another note: It seems that the stock of Padauk MCUs at LCSC is depleting and they are not reordering? I enquired about the PFS154-S16 and they responded with the part being "unavailable". I also asked LCSC if they are planning to add some of the newer decices and it seems they had no plan to.

Is anyone aware of an alternative distributor that can be used as easily as LCSC? Taobao is quite a hassle when you are not living in china...


 

Offline homeworkboy

  • Contributor
  • Posts: 15
  • Country: tw
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1280 on: February 07, 2021, 09:59:16 am »
I download the update tool
Already completely correct
Thanks JS
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 237
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1281 on: February 07, 2021, 10:46:02 am »
I investigated the low power modes of the PFS154 a bit. Turns out the Padauks are actually quite competitive, even compared to "low power" 8 bit MCUs.

https://cpldcpu.wordpress.com/2021/02/07/ultra-low-power-led-flasher/

There were some some surprises to work around. One of them was that  all timers can be used to wake up from STOPEXE instead of only the 16 bit timer. This is not quite clear from the manual.

While investigating this, I measured the transient power consumption of the PFS154. (I used a self-made wide bandwidth transimpedance amplifier with JFET input to amplify the current). You can see an example of a power signature for LRC execution below. It appears that the Padauk is a true 1 cycle design. Both edges of the clock are used, supposedly for fetch/exec and write back. It should be possible to deduce information about the type of instructions being executed from the power trace, but I did not go deeper.

I also found that there is an active 8 bit counter in STOPEXE, even when all timers are turned off. Not sure if this is intentional. So if the Padauk designers read this, they may want to look into their clock-gating :) (Yes, I am complaining about 10µA transients that need maybe 1pC of charge).


« Last Edit: February 07, 2021, 10:52:24 am by tim_ »
 
The following users thanked this post: js_12345678_55AA

Offline tim_

  • Regular Contributor
  • *
  • Posts: 237
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1282 on: February 14, 2021, 01:21:17 pm »

It seems that LCSC has run out of all flash version of the Padauk controller. An inquiry came back with the info that these parts are unavailable. That's a pity, because they were the only supplier that was somewhat hassle-free. Also, none of the products that were released during 2020 every made it to LCSC. All the official distributors listed on padauk are actually rather small dealers on 1688 and taobao.

Looks like it will be very difficult to acquire new stock.
 

Offline LovelyA72

  • Regular Contributor
  • *
  • Posts: 60
  • Country: us
  • Kashikoma from Massachusetts!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1283 on: February 14, 2021, 07:35:31 pm »
Currently, you can still find some classic Padauk models from Aliexpress. I contacted some guys from Taobao, seems like they're also laking micros due to the high demand in Mainland China. I purchased a few hundreds of PMS150C from them. They're really friendly. If you have a WeChat account, you can add one or two official resalers as friends so you can get your padauk micros directly from them.
Kashikoma!
 

Offline LovelyA72

  • Regular Contributor
  • *
  • Posts: 60
  • Country: us
  • Kashikoma from Massachusetts!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1284 on: February 14, 2021, 07:39:28 pm »
Also, I got an official writer and in-circuit emulator. Now I can freely switch between FreePDK and their Mini-C :-+. If you guys want me to test anything like a new ic or capture some programming sequences, feel free to tell me! I have a basic level oscilloscope and a 24Mhz FX2LP logic analyzer.
Kashikoma!
 
The following users thanked this post: icraftcrafts

Offline LovelyA72

  • Regular Contributor
  • *
  • Posts: 60
  • Country: us
  • Kashikoma from Massachusetts!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1285 on: February 20, 2021, 08:51:23 am »
Here's an update on the official writer. Padauk's official writer will enforce the difference between PMS150C and PMS15A. The writer will not write PMS150C's binary into a PMS15A.
If you modify .Assembly   User_Size   200h manually, the WRITER software will refuse to load the compiled binary.
One more point to FreePDK programmer!
« Last Edit: February 20, 2021, 11:42:44 am by LovelyA72 »
Kashikoma!
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1286 on: February 22, 2021, 10:12:30 am »
Just saw this offer:

https://detail.1688.com/offer/521685377594.html

PADAUK IC combined with wireless sender/receiver (maybe something like a NRF24L01 clone).

Wireless remote control for <0.20 USD ? I guess a battery will cost more than the rest of this.

 :)
« Last Edit: February 22, 2021, 10:18:16 am by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 
The following users thanked this post: icraftcrafts

Offline LovelyA72

  • Regular Contributor
  • *
  • Posts: 60
  • Country: us
  • Kashikoma from Massachusetts!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1287 on: February 22, 2021, 02:51:16 pm »
Padauk with wireless? That sounds like a nice combination. Seems like they offer multiple versions. Besides the PMS132 one, we can basically use them with FreePDK without any additional hard to gather hardware information.
Kashikoma!
 

Offline electronic_eel

  • Regular Contributor
  • *
  • Posts: 201
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1288 on: February 22, 2021, 03:25:37 pm »
While investigating this, I measured the transient power consumption of the PFS154. (I used a self-made wide bandwidth transimpedance amplifier with JFET input to amplify the current). You can see an example of a power signature for LRC execution below.
Could you show more details how you created this power trace with your JFET amplifier? What kind of bandwidth do you estimate for it?

I'm interested in doing similar measurements for low power optimization.
 

Offline LovelyA72

  • Regular Contributor
  • *
  • Posts: 60
  • Country: us
  • Kashikoma from Massachusetts!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1289 on: February 22, 2021, 05:11:46 pm »
A further thought on PMS15A and PMS150C: The die in PMS15A and PMS150C might be the same, the initial information stored in the OTP ROM might differ between these two ICs. And that's how the official Padauk programmer distinguishes these ICs.
Kashikoma!
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1290 on: February 22, 2021, 06:51:47 pm »
A further thought on PMS15A and PMS150C: The die in PMS15A and PMS150C might be the same, the initial information stored in the OTP ROM might differ between these two ICs. And that's how the official Padauk programmer distinguishes these ICs.

There is no such thing as OTP-ROM. There is just the OTP area we can read. Since we also use the exact same sequence WRITER uses to check for PMS150C there is really not any difference.
Can you read a blank PMS15A of yours and share the readout "easypdkprog -n PMS150C -b read pms15aempty.bin".

It might be possible that at factory they do write "0" to some portions of the upper half of the OTP area and that is how WRITER detects it...

The PMS15A I bought do not differ in a single bit from PMS150C.

JS
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline LovelyA72

  • Regular Contributor
  • *
  • Posts: 60
  • Country: us
  • Kashikoma from Massachusetts!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1291 on: February 23, 2021, 10:45:55 am »
Can you read a blank PMS15A of yours and share the readout "easypdkprog -n PMS150C -b read pms15aempty.bin".

There are differences between 150C and 15A's readouts. From 0x7Ec to the end of the binary file.
Kashikoma!
 

Offline homeworkboy

  • Contributor
  • Posts: 15
  • Country: tw
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1292 on: February 24, 2021, 08:55:05 am »
They are different  fab.
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1293 on: February 24, 2021, 01:09:23 pm »
Can you read a blank PMS15A of yours and share the readout "easypdkprog -n PMS150C -b read pms15aempty.bin".

There are differences between 150C and 15A's readouts. From 0x7Ec to the end of the binary file.

Thanks for the readout. Looks like 2 single bytes are written in reserved area so WRITER can determine if it is a PMS15A labeled PMS150C.
This also means we still can use PMS15A as a full featured PMS150C (just missing 2 bytes in reserved area which we can not program anymore - no loss at all).

 :)
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline gir

  • Contributor
  • Posts: 16
  • Country: at
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1294 on: March 14, 2021, 02:35:15 pm »
I've been experimenting with the PMS150c recently, and I have hit a snag: What's the correct way to initialize Timer16 to fire an interrupt in assembly?

Here's my attempt (full code attached):

Code: [Select]
        ;XXX: timer16 setup -- this is broken
        mov     a, #(( 1<<0 | 1<<3 | 4<<5 ))    ; ovf@bit9, clk/4, ihrc
        mov     t16m, a
        mov     a, #2           ; enable timer16 int, disable all others
        mov     inten, a
        ; ...
        engint

I want timer16 to cause an interrupt every 512 cycles. The IVR then changes the PWM duty cycle of timer2 (timer2 works).

Looking at the generated code (with dispdk, also attached), it seems like it should work :/

Thanks in advance for any help!
« Last Edit: March 14, 2021, 02:43:30 pm by gir »
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1295 on: March 14, 2021, 07:05:36 pm »
I've been experimenting with the PMS150c recently, and I have hit a snag: What's the correct way to initialize Timer16 to fire an interrupt in assembly?

Here's my attempt (full code attached):

Code: [Select]
        ;XXX: timer16 setup -- this is broken
        mov     a, #(( 1<<0 | 1<<3 | 4<<5 ))    ; ovf@bit9, clk/4, ihrc
        mov     t16m, a
        mov     a, #2           ; enable timer16 int, disable all others
        mov     inten, a
        ; ...
        engint

I want timer16 to cause an interrupt every 512 cycles. The IVR then changes the PWM duty cycle of timer2 (timer2 works).

Looking at the generated code (with dispdk, also attached), it seems like it should work :/

Thanks in advance for any help!

Hi


   mov     a, #2 ; enable timer16 int, disable all others  <== here is most likely your error, T16 int is BIT2  = 1<<2 =  4  ==> mov a, #4
   mov     inten, a


In case you like some more comments:

* your setup of TM16 is wrong, according to your comment you want every 512 cycles to get an interrupt. For this you need to setup BIT8 overflow (see data sheet: "9.2.5.   TIMER time out" for full details)

* your comment about "no calibration" is incorrect. In fact without setting IHRCR it will stay 0 after reset which causes for IHRC/4 something around 2.5MHz instead of the 4MHz (this also affects your PWM timing)

* your interrupt does not have the pushaf / popaf (this could cause problems if you ever add some more code to your "loop")

* pac all set as output will not save power... (unused pins should be set as input)

* you cold save the the extra variable and some instructions if you use tm2b directly and add 4 to it (mov a, tm2b    add a,#4   mov tm2b, a)


JS
« Last Edit: March 14, 2021, 08:11:40 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline gir

  • Contributor
  • Posts: 16
  • Country: at
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1296 on: March 14, 2021, 08:50:29 pm »
hi, js!

here is most likely your error, T16 int is BIT2  = 1<<2 =  4  ==> mov a, #4

Oh, wow, what an embarrassing mistake! Thanks, that fixed it!

In case you like some more comments:

i do!

* your setup of TM16 is wrong, according to your comment you want every 512 cycles to get an interrupt. For this you need to setup BIT8 overflow (see data sheet: "9.2.5.   TIMER time out" for full details)

Again, thanks. Off by one! I do wonder, though: shouldn't bit8 flip at value 256? (i have read the datasheet, i just think that's unintuitive)

* your comment about "no calibration" is incorrect. In fact without setting IHRCR it will stay 0 after reset which causes for IHRC/4 something around 2.5MHz instead of the 4MHz (this also affects your PWM timing)

I noticed that it was way too slow; I intend to use the instructions from the EASY_PDK_CALIBRATE_RC_M macro once I got the other parts working. And while i have your attention: I guess, just pasting those ANDs in and removing the --nocalibrate flag is enough? And I assume it's possible to calibrate to "odd" values, like 4.096MHz?

* your interrupt does not have the pushaf / popaf (this could cause problems if you ever add some more code to your "loop")

am aware, was just too lazy for this test.

* pac all set as output will not save power... (unused pins should be set as input)

good to know, thanks!
« Last Edit: March 14, 2021, 08:53:41 pm by gir »
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1297 on: March 14, 2021, 11:22:43 pm »

* your comment about "no calibration" is incorrect. In fact without setting IHRCR it will stay 0 after reset which causes for IHRC/4 something around 2.5MHz instead of the 4MHz (this also affects your PWM timing)

I noticed that it was way too slow; I intend to use the instructions from the EASY_PDK_CALIBRATE_RC_M macro once I got the other parts working. And while i have your attention: I guess, just pasting those ANDs in and removing the --nocalibrate flag is enough? And I assume it's possible to calibrate to "odd" values, like 4.096MHz?

The macro takes 4 parameter: type, frequency, voltage and the register offset of IHRCR.

The tuning is using SYSCLK as reference. So if you want 4MHz sysclock then you have to setup CLKMD first and right after that you insert the "magic ANDs". The immediate values of the ANDs are used to encode the 4 parameter.

   
  ; clock setup (no calibration):
  set1  clkmd, #4       ; enable IHRC
  mov  a, #(( 0<<5 | 1<<4 | 0<<3 | 1<<2 | 0<<1 | 0<<0 ))
  mov  clkmd, a         ; switch to IHRC/4, WDT off; keep ILRC on

  ; calibration placeholder and parameters
  and a, #'R'
  and a, #'C'
  and a, #1                ;type 1 = IHRC calibration
  and a, #( 4194304 )      ;4MHz = 4194304Hz
  and a, #( 4194304>>8 )
  and a, #( 4194304>>16 )
  and a, #( 4194304>>24 )
  and a, #( 5000 )         ;5V = 5000mV
  and a, #( 5000>>8 )
  and a, #0x0B             ;register offset of IHRCR


The magic ANDs (will act as NOPs) been chosen that any programmer can still write the code and even if no calibration is performed the IC will still work (wrong frequency, but works).
EasyPDK programmer will replace them before writing with calibration code which is altered again after calibration.

You can *try* to calibrate to any value in Hz... just keep in mind that the IC is not very precise. If you are unlucky it is off by +-20kHz. It also drifts a lot by temperature change (just touching the IC is enough) or voltage change (always tune to the intended target voltage).

JS
« Last Edit: March 14, 2021, 11:24:14 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline homeworkboy

  • Contributor
  • Posts: 15
  • Country: tw
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1298 on: March 20, 2021, 08:18:05 am »
Hi everyone:
I compile calib-and-fuse-demo.c.

It generate asm
;   calib-and-fuse-demo.c: 41: EASY_PDK_CALIBRATE_IHRC(8000000,5000);        //tune SYSCLK to 8MHz @ 5.000V
   and   a, #'R'                       
   and   a, #'C'                       
   and   a, #((1))         
   and   a, #((8000000))     
   and   a, #((8000000)>>8) 
   and   a, #((8000000)>>16)
   and   a, #((8000000)>>24)
   and   a, #((5000))     
   and   a, #((5000)>>8) 
   and   a, #((0x0B))   

I confuseit
 
When I use program PMS150 OTP, how to calibration IHRC?
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1299 on: March 20, 2021, 09:00:43 am »
Hi everyone:
I compile calib-and-fuse-demo.c.

When I use program PMS150 OTP, how to calibration IHRC?

Hi,

easypdkprog will automatically detect the "magic AND sequence" and insert calibration code during programing. You have to do nothing special. Just write it using easy easypdkprog.

Output will look like this

easypdkprog --icname=PMS150C write calib-and-fuse-demo.ihx
Writing IC... done.
Calibrating IC (@5.00V IHRC SYSCLK=8000000Hz)... calibration result: 7946104Hz (0x84)  done.


JS

Please make sure that you use the LATEST version of easypdkprog (1.3 as of writing this) => https://github.com/free-pdk/easy-pdk-programmer-software/releases
« Last Edit: March 20, 2021, 09:02:26 am by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf