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

0 Members and 1 Guest are viewing this topic.

Offline piotr_go

  • Contributor
  • Posts: 13
  • Country: pl
    • My Projects
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #550 on: March 19, 2019, 08:06:51 pm »
What's the difference beetween PFS154 and PFS173 in write?

A5A5A5A7
1 bit
15 bit word
15 bit word
15 bit word
15 bit word
13 bit address
...
...

?
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #551 on: March 19, 2019, 10:51:01 pm »
What's the difference beetween PFS154 and PFS173 in write?

A5A5A5A7
1 bit
15 bit word
15 bit word
15 bit word
15 bit word
13 bit address
...
...

?

The difference is only 4x15 bit (PFS173) instead of 4x14 bit (PFS154). Address is 13 bit for both. Slow clocks after address is 4 cycles for both on my programmer (on original WRITER it used 8 slow clocks for PFS173).
In High-Voltage phase VDD is 5.6V and VPP 8.0V for write. Erase uses VDD 2.0V or 3.0V and VPP 9.0V in high voltage phase.

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

Offline piotr_go

  • Contributor
  • Posts: 13
  • Country: pl
    • My Projects
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #552 on: March 20, 2019, 10:43:33 am »
Now it's working.
I had too high VDD.
It worked on pfs154 and pms150c but not pfs173.
 

Offline anxzhu

  • Newbie
  • Posts: 3
  • Country: cn
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #553 on: March 24, 2019, 02:55:19 am »
 :-+ :-+ :-+Firmware please
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #554 on: March 26, 2019, 12:05:32 am »
:-+ :-+ :-+Firmware please

Software / firmware will come soon.

OTP support is working now.

The following ICs are fully tested and supported by easypdkprog right now:

./easypdkprog list
Supported ICs:
 PMS150C  (0xA16): OTP  : 1024 (13 bit), RAM:  64 bytes
 PFS154   (0xAA1): FLASH: 2048 (14 bit), RAM: 128 bytes
 PMS154B  (0xE06): OTP  : 2048 (14 bit), RAM: 128 bytes
 PMS154C  (0xE06): OTP  : 2048 (14 bit), RAM: 128 bytes
 PFS173   (0xEA2): FLASH: 3072 (15 bit), RAM: 256 bytes


(more to come)

Calibration is 80% done, automatic search, insertion, execution and removing (with NOP) of calibration function is working already.

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

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1896
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #555 on: March 26, 2019, 05:56:56 am »
Thumbs up JS   :-+ :-+ :-+
ASiDesigner, Stands for Application specific intelligent devices
I'm a Digital Expert from 8-bits to 64-bits
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #556 on: March 29, 2019, 02:20:42 pm »
Hi,

I got distracted a bit  :) after I saw a youtube video from bigclive.com where he found another small gadget which most likely contains a PADAUK IC (he mentioned it in his video).

Video:

Item: https://www.ebay.com/itm/182936210709


I went and bought some. After they arrived I removed the IC with hot air and placed it in Easy PDK programmer:

Surprise surprise...

./easypdkprog probe
TYPE:OTP RSP:0x285A0 VPP=4.50 VDD=2.00
IC is supported: PMS150C ICID:0xA16

 
OK, it is a PMC150C !!!

Next step:

./easypdkprog -n PMS150C read test.bin -b
Reading IC... done.


Great! But wait... dump looks a bit strange:

./hexdump test.bin
0000000 29 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000010 ff 1f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000020 32 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000030 25 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000040 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000050 24 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000060 b1 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000070 40 17 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000080 c2 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000090 90 0d 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000a0 02 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...
00007a0 ff 1f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00007b0 ff 1f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00007c0 ff 1f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00007d0 ff 1f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00007e0 ff 1f ff 1f ff 1f ff 1f ff 1f ff 1f ca 01 ff 1f
00007f0 24 07 cc 1f ff 1f ff 1f ff 0f ff 1f 5a 01 fc 02


It looks like some sort of security prevents us from reading the complete content.
However the read seems to work good since we see the complete reserved area at the end.

==> Let's have a look at the "last word" (FUSE), it is 0x02FC

Let's have a look at the IC datasheet / IDE include files / ...

in PMS150C.INC we can find:
   .Assembly   OPTION   0   Security   Enable   Disable
   .Assembly   OPTION   2   LVR   4.0V   3.5V   3.0V   2.75V   2.5V   1.8V   2.2V   2.0V
   .Assembly   OPTION   7   Drive      Low   Normal
   .Assembly   OPTION   10   Bootup_Time   Slow   X   X   Fast
   .Assembly   OPTION_LOW   1, 8, 12 ~ 15
   .Assembly   OPTION_DEFAULT   0x02FC



==> 0x2FC is the default with security enabled

However the Option_Help for Security reads like this
  Enable  : "Security 7/8 words Enable"
  Disable : "Security Disable"


Hmmm... "Security 7/8 words Enable", looks exactly like our dump.
==> 7 out of 8 words are security enabled (will read all 0 when reading the IC)

So what now? Is this the end?

Of course not!

- as we can see, the first instruction is 0x1829 which translates to "GOTO 0x29".
  (IDE always creates a JUMP to FPPA0 function as first instruction for PMC150)
- after this jump some space is unused (multi core PADAUK devices insert the startup jump for the other cores there)
- at 0x20 the interrupt service routine starts (fixed location for PMC150)
- at the end of the IC code memory we can see a lot of 0x1FFF, so most likely this space is unused as well


==> What if:
- we overwrite the first instruction with all 0 (NOP)
- place a jump to the near end of code memory at instruction 1
- write a special small program near the end of code memory which uses LDSPTL/LDSPTH to read code memory and send it out via GPIO


After some fiddeling and dry runs with fresh IC I got the following:

./easypdkprog -n PMS150C write dump_150c_ovl.hex --noblankchk --noverify
Writing IC... done.


Then I started the IC and got data from it:

./hexdump cardoorlight_dumped.bin
0000000 00 00 d0 1b ff 1f ff 1f ff 1f ff 1f ff 1f ff 1f
0000010 ff 1f ff 1f ff 1f ff 1f ff 1f ff 1f ff 1f ff 1f
0000020 32 00 45 0d 1b 18 45 0e 20 09 62 02 23 09 82 02
0000030 25 09 e2 02 22 09 f5 17 d0 05 58 17 d1 05 d0 00
0000040 33 00 3b 00 64 17 e6 05 e6 07 00 0c 3a 00 66 09
0000050 24 18 30 00 3a 17 82 00 f6 1f 99 00 fe 1f ff 12
0000060 b1 18 d1 0f 40 17 8b 00 1c 17 83 00 06 17 c6 05
0000070 40 17 c1 05 8b 00 c0 09 c7 05 81 0a 01 08 06 09
0000080 c2 07 c4 05 c3 07 c5 05 01 17 c2 05 83 09 03 17
0000090 90 0d 48 18 d0 0f 90 0d 59 18 02 09 90 0d 59 18
00000a0 02 04 90 0d 57 18 03 08 90 0c 4b 18 58 18 42 09
...


:) :) :)

What do we learn from this?

=> do not leave empty space in IC when you want to prevent a readout.

=> IDE provides a simple method for this (mentioned in user manual):
  .Fill_Space     RESET;
or
  .Fill_Space     NOP;

=> I will add an option for Easy PDK programmer to set unused space to 0 (NOP)

=> and WTF is 7/8 security???


Best part: This product is a cheap source for 2x PCB + battery holder + housing + battery + magnet (pcb magnet sensor + 3x led for own projects) :)


Have fun,

JS

Easy PDK programmer and more: https://free-pdk.github.io
 
The following users thanked this post: oPossum, firewalker, thm_w, Andrew McNamara, notanick

Offline lucas.hartmann

  • Contributor
  • Posts: 16
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #557 on: March 29, 2019, 02:48:45 pm »
Even if all empty space was filled, maybe you can side channel attack the programming cycle. I remember that previously you guys had only a few bits programming due to limited power supply...

Try writing 0 to one bit at a time and record the programming current.

I am assuming programming a previously 1 bit takes more energy than a previously 0 bit. If it works then there is no more code protection viable for these IC.

Enviado de meu Moto MAXX usando o Tapatalk

 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #558 on: March 29, 2019, 05:11:12 pm »
Even if all empty space was filled, maybe you can side channel attack the programming cycle. I remember that previously you guys had only a few bits programming due to limited power supply...
Try writing 0 to one bit at a time and record the programming current.
I am assuming programming a previously 1 bit takes more energy than a previously 0 bit.

This was plan B..., however plan A worked like a charm.
The difference between writing 0=>0 and 1=>0 is clearly visible on oscilloscope. But on VDD and not on VPP like you would assume.
That's why ADC is connected to both VPP and VDD in Easy PDK programmer  ;).

If it works then there is no more code protection viable for these IC.
This is a *cheap* IC, not a security IC. It also costs next to nothing sending PADAUK IC to the usual suspects for IC extraction.
JS
« Last Edit: March 29, 2019, 05:13:32 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 
The following users thanked this post: hidden

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #559 on: April 01, 2019, 10:26:24 am »
Calibration seems to work nice  :) :) :)

$ make flash run
sdcc -lpdk14 -mpdk14 -c hellopfs154.c -o hellopfs154.rel
sdcc -lpdk14 -mpdk14 --out-fmt-ihx hellopfs154.rel -o hellopfs154.hex

easypdkprog --icname=PFS154 write hellopfs154.hex
Erasing IC... done.
Writing IC... done.
Calibrating IC (@4.00V IHRC SYSCLK=8000000Hz)... calibration result: 7995368Hz (0x81)  done.

easypdkprog start
Running IC (4.00V)... IC started, press [Esc] to stop.
Hello World!
Hello World!
Hello World!
Hello World!
Hello World!

IC stopped


Above you see: compilation with SDCC, writing + calibration with Easy PDK programmer, executing the program while IC is still in Easy PDK programmer socket, UART with autobaud receives from /sends to IC.


I also found out something new: OTP area inside of flash based PADAUK ICs
(I think it is still flash but a flag tells IC to not erase this section(s) anymore)
==> Dangerous! I did not find any way to change this values back. So once it is declared as OTP and written it stays there!

Both flash based ICs from PADAUK (PFS154 / PFS173) seem to have a default small OTP area (factory tuning data is stored inside).
It also looks like a 3rd value holds flags to (re)define more parts of IC as OTP:
- PFS154: @0x7E0 - 0x7EF  standard OTP area
- PFS173: @0xBE0 - 0xBEF  standard OTP area

@0x7E0 / 0xBE0 = <unused OTP, can be used for user data storage>
@0x7E1 / 0xBE1 = <unused OTP, can be used for user data storage>
...
@0x7EC / 0xBEC = <unused OTP, can be used for user data storage>
@0x7ED / 0xBED = factory IHRCR tuning value
@0x7EE / 0xBEE = factory BGTR tuning value
@0x7EF / 0xBEF = not 100% analyzed: value / bit mask setting OTP state for flash pages, when is all 0 then complete IC can not be erased / written? anymore



JS
« Last Edit: April 01, 2019, 10:31:33 am by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 
The following users thanked this post: oPossum

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #560 on: April 02, 2019, 09:15:43 am »
Hi,

I'm hunting unknown opcodes (PDK15 is mentioning NMOV A, M / NMOV M, A / SWAP M  in documentation but IDE has a bug not implementing them).

In order to do this I wrote a simple fuzzer (nothing sophisticated, just a start).

Code: [Select]
volatile unsigned char mem, ta, ra, rf, rsp;

...

  ra=0;
  rf=0;
  rsp=0;
  for(ta=0;;ta++)
  {
    putchar('T'); printhex(ta); putchar('-');

    __asm
      mov a, #0
      mov __flag, a
      mov a, _ta
   
      .dw 0x0064         //instruction opcode
   
      mov _ra, a
      mov a, __flag
      mov _rf, a
      mov a, __sp
      mov _rsp, a
    __endasm;

    putchar('a');printhex(ra); putchar('-'); 
    putchar('f');printhex(rf); putchar('-');
    putchar('s');printhex(rsp); putchar('-');
    putchar('m');printhex(mem);.
    putchar('\n');
    for(unsigned long int i=10000; i>0; i--); // Wait approx. 20ms
  }
 
...


Basically it is a loop loading different values to the A register then executing the opcode and then it outputs changes to A, flags, stack pointer or memory (only monitoring RAM address 0)

I made a quick test with PFS154 and found the following:

- every opcode I tried executed and the processor was still running afterwards (no lockups on unused instructions)

- most unknown instructions seem to execute as NOP (more tests needed)

- one new undocumented opcode was found for PFS154:  :)
Opcode 0x0064:
Code: [Select]
T00-a00-fF1-s10-m00
T01-aFF-fF6-s10-m00
T02-aFE-fF6-s10-m00
T03-aFD-fF6-s10-m00
T04-aFC-fF6-s10-m00
T05-aFB-fF6-s10-m00
T06-aFA-fF6-s10-m00
T07-aF9-fF6-s10-m00
T08-aF8-fF6-s10-m00
T09-aF7-fF6-s10-m00
T0A-aF6-fF6-s10-m00
T0B-aF5-fF6-s10-m00
T0C-aF4-fF6-s10-m00
T0D-aF3-fF6-s10-m00
T0E-aF2-fF6-s10-m00
T0F-aF1-fF6-s10-m00
T10-aF0-fF2-s10-m00
T11-aEF-fF6-s10-m00
T12-aEE-fF6-s10-m00
T13-aED-fF6-s10-m00
T14-aEC-fF6-s10-m00
T15-aEB-fF6-s10-m00
T16-aEA-fF6-s10-m00
T17-aE9-fF6-s10-m00
T18-aE8-fF6-s10-m00
T19-aE7-fF6-s10-m00
T1A-aE6-fF6-s10-m00
T1B-aE5-fF6-s10-m00
T1C-aE4-fF6-s10-m00
T1D-aE3-fF6-s10-m00
T1E-aE2-fF6-s10-m00
T1F-aE1-fF6-s10-m00
T20-aE0-fF2-s10-m00
T21-aDF-fF6-s10-m00
T22-aDE-fF6-s10-m00
T23-aDD-fF6-s10-m00
T24-aDC-fF6-s10-m00
T25-aDB-fF6-s10-m00
T26-aDA-fF6-s10-m00
T27-aD9-fF6-s10-m00
T28-aD8-fF6-s10-m00
T29-aD7-fF6-s10-m00
T2A-aD6-fF6-s10-m00
T2B-aD5-fF6-s10-m00
T2C-aD4-fF6-s10-m00
T2D-aD3-fF6-s10-m00
T2E-aD2-fF6-s10-m00
T2F-aD1-fF6-s10-m00
T30-aD0-fF2-s10-m00
T31-aCF-fF6-s10-m00
T32-aCE-fF6-s10-m00
T33-aCD-fF6-s10-m00
T34-aCC-fF6-s10-m00
T35-aCB-fF6-s10-m00
T36-aCA-fF6-s10-m00
T37-aC9-fF6-s10-m00
T38-aC8-fF6-s10-m00
T39-aC7-fF6-s10-m00
T3A-aC6-fF6-s10-m00
T3B-aC5-fF6-s10-m00
T3C-aC4-fF6-s10-m00
T3D-aC3-fF6-s10-m00
T3E-aC2-fF6-s10-m00
T3F-aC1-fF6-s10-m00
T40-aC0-fF2-s10-m00
T41-aBF-fF6-s10-m00
T42-aBE-fF6-s10-m00
T43-aBD-fF6-s10-m00
T44-aBC-fF6-s10-m00
T45-aBB-fF6-s10-m00
T46-aBA-fF6-s10-m00
T47-aB9-fF6-s10-m00
T48-aB8-fF6-s10-m00
T49-aB7-fF6-s10-m00
T4A-aB6-fF6-s10-m00
T4B-aB5-fF6-s10-m00
T4C-aB4-fF6-s10-m00
T4D-aB3-fF6-s10-m00
T4E-aB2-fF6-s10-m00
T4F-aB1-fF6-s10-m00
T50-aB0-fF2-s10-m00
T51-aAF-fF6-s10-m00
T52-aAE-fF6-s10-m00
T53-aAD-fF6-s10-m00
T54-aAC-fF6-s10-m00
T55-aAB-fF6-s10-m00
T56-aAA-fF6-s10-m00
T57-aA9-fF6-s10-m00
T58-aA8-fF6-s10-m00
T59-aA7-fF6-s10-m00
T5A-aA6-fF6-s10-m00
T5B-aA5-fF6-s10-m00
T5C-aA4-fF6-s10-m00
T5D-aA3-fF6-s10-m00
T5E-aA2-fF6-s10-m00
T5F-aA1-fF6-s10-m00
T60-aA0-fF2-s10-m00
T61-a9F-fF6-s10-m00
T62-a9E-fF6-s10-m00
T63-a9D-fF6-s10-m00
T64-a9C-fF6-s10-m00
T65-a9B-fF6-s10-m00
T66-a9A-fF6-s10-m00
T67-a99-fF6-s10-m00
T68-a98-fF6-s10-m00
T69-a97-fF6-s10-m00
T6A-a96-fF6-s10-m00
T6B-a95-fF6-s10-m00
T6C-a94-fF6-s10-m00
T6D-a93-fF6-s10-m00
T6E-a92-fF6-s10-m00
T6F-a91-fF6-s10-m00
T70-a90-fF2-s10-m00
T71-a8F-fF6-s10-m00
T72-a8E-fF6-s10-m00
T73-a8D-fF6-s10-m00
T74-a8C-fF6-s10-m00
T75-a8B-fF6-s10-m00
T76-a8A-fF6-s10-m00
T77-a89-fF6-s10-m00
T78-a88-fF6-s10-m00
T79-a87-fF6-s10-m00
T7A-a86-fF6-s10-m00
T7B-a85-fF6-s10-m00
T7C-a84-fF6-s10-m00
T7D-a83-fF6-s10-m00
T7E-a82-fF6-s10-m00
T7F-a81-fF6-s10-m00
T80-a80-fFA-s10-m00
T81-a7F-fF6-s10-m00
T82-a7E-fF6-s10-m00
T83-a7D-fF6-s10-m00
T84-a7C-fF6-s10-m00
T85-a7B-fF6-s10-m00
T86-a7A-fF6-s10-m00
T87-a79-fF6-s10-m00
T88-a78-fF6-s10-m00
T89-a77-fF6-s10-m00
T8A-a76-fF6-s10-m00
T8B-a75-fF6-s10-m00
T8C-a74-fF6-s10-m00
T8D-a73-fF6-s10-m00
T8E-a72-fF6-s10-m00
T8F-a71-fF6-s10-m00
T90-a70-fF2-s10-m00
T91-a6F-fF6-s10-m00
T92-a6E-fF6-s10-m00
T93-a6D-fF6-s10-m00
T94-a6C-fF6-s10-m00
T95-a6B-fF6-s10-m00
T96-a6A-fF6-s10-m00
T97-a69-fF6-s10-m00
T98-a68-fF6-s10-m00
T99-a67-fF6-s10-m00
T9A-a66-fF6-s10-m00
T9B-a65-fF6-s10-m00
T9C-a64-fF6-s10-m00
T9D-a63-fF6-s10-m00
T9E-a62-fF6-s10-m00
T9F-a61-fF6-s10-m00
TA0-a60-fF2-s10-m00
TA1-a5F-fF6-s10-m00
TA2-a5E-fF6-s10-m00
TA3-a5D-fF6-s10-m00
TA4-a5C-fF6-s10-m00
TA5-a5B-fF6-s10-m00
TA6-a5A-fF6-s10-m00
TA7-a59-fF6-s10-m00
TA8-a58-fF6-s10-m00
TA9-a57-fF6-s10-m00
TAA-a56-fF6-s10-m00
TAB-a55-fF6-s10-m00
TAC-a54-fF6-s10-m00
TAD-a53-fF6-s10-m00
TAE-a52-fF6-s10-m00
TAF-a51-fF6-s10-m00
TB0-a50-fF2-s10-m00
TB1-a4F-fF6-s10-m00
TB2-a4E-fF6-s10-m00
TB3-a4D-fF6-s10-m00
TB4-a4C-fF6-s10-m00
TB5-a4B-fF6-s10-m00
TB6-a4A-fF6-s10-m00
TB7-a49-fF6-s10-m00
TB8-a48-fF6-s10-m00
TB9-a47-fF6-s10-m00
TBA-a46-fF6-s10-m00
TBB-a45-fF6-s10-m00
TBC-a44-fF6-s10-m00
TBD-a43-fF6-s10-m00
TBE-a42-fF6-s10-m00
TBF-a41-fF6-s10-m00
TC0-a40-fF2-s10-m00
TC1-a3F-fF6-s10-m00
TC2-a3E-fF6-s10-m00
TC3-a3D-fF6-s10-m00
TC4-a3C-fF6-s10-m00
TC5-a3B-fF6-s10-m00
TC6-a3A-fF6-s10-m00
TC7-a39-fF6-s10-m00
TC8-a38-fF6-s10-m00
TC9-a37-fF6-s10-m00
TCA-a36-fF6-s10-m00
TCB-a35-fF6-s10-m00
TCC-a34-fF6-s10-m00
TCD-a33-fF6-s10-m00
TCE-a32-fF6-s10-m00
TCF-a31-fF6-s10-m00
TD0-a30-fF2-s10-m00
TD1-a2F-fF6-s10-m00
TD2-a2E-fF6-s10-m00
TD3-a2D-fF6-s10-m00
TD4-a2C-fF6-s10-m00
TD5-a2B-fF6-s10-m00
TD6-a2A-fF6-s10-m00
TD7-a29-fF6-s10-m00
TD8-a28-fF6-s10-m00
TD9-a27-fF6-s10-m00
TDA-a26-fF6-s10-m00
TDB-a25-fF6-s10-m00
TDC-a24-fF6-s10-m00
TDD-a23-fF6-s10-m00
TDE-a22-fF6-s10-m00
TDF-a21-fF6-s10-m00
TE0-a20-fF2-s10-m00
TE1-a1F-fF6-s10-m00
TE2-a1E-fF6-s10-m00
TE3-a1D-fF6-s10-m00
TE4-a1C-fF6-s10-m00
TE5-a1B-fF6-s10-m00
TE6-a1A-fF6-s10-m00
TE7-a19-fF6-s10-m00
TE8-a18-fF6-s10-m00
TE9-a17-fF6-s10-m00
TEA-a16-fF6-s10-m00
TEB-a15-fF6-s10-m00
TEC-a14-fF6-s10-m00
TED-a13-fF6-s10-m00
TEE-a12-fF6-s10-m00
TEF-a11-fF6-s10-m00
TF0-a10-fF2-s10-m00
TF1-a0F-fF6-s10-m00
TF2-a0E-fF6-s10-m00
TF3-a0D-fF6-s10-m00
TF4-a0C-fF6-s10-m00
TF5-a0B-fF6-s10-m00
TF6-a0A-fF6-s10-m00
TF7-a09-fF6-s10-m00
TF8-a08-fF6-s10-m00
TF9-a07-fF6-s10-m00
TFA-a06-fF6-s10-m00
TFB-a05-fF6-s10-m00
TFC-a04-fF6-s10-m00
TFD-a03-fF6-s10-m00
TFE-a02-fF6-s10-m00
TFF-a01-fF6-s10-m00


It reads as follows:
T00-a00-fF1-s10-m00
 Test input A = 0x00
 output a = 0x00
 output flags = 0xF1 (ZF)
 output stack = 0x10 (no change to stack)
 output mem0 = 0x00 (no change to memory address 0)

T01-aFF-fF6-s10-m00
 Test input A = 0x01
 output a = 0xFF
 output flags = 0xF6 (AC / CF)
 output stack = 0x10 (no change to stack)
 output mem0 = 0x00 (no change to memory address 0)

T10-aF0-fF2-s10-m00
 Test input A = 0x10
 output a = 0xF0
 output flags = 0xF2 (CF)
 output stack = 0x10 (no change to stack)
 output mem0 = 0x00 (no change to memory address 0)


This is clearly a NEG A instruction  (A=NEG A), it just behaves different from standard NEG A instruction in setting flags. Maybe a BCD capable NEG?



I'm waiting for the PDK15 assembler from SDCC to be ready to compile for PFS173 so we can hunt for the missing instructions there.

Have fun,

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

Offline spth

  • Regular Contributor
  • *
  • Posts: 163
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #561 on: April 03, 2019, 07:17:25 pm »
I'm waiting for the PDK15 assembler from SDCC to be ready to compile for PFS173 so we can hunt for the missing instructions there.

The issues you reported are now fixed in the pdk branch.

Due to the upcoming 3.9.0 release, SDCC is currently in code freeze, so applying the fixes to trunk needs to be discussed on the developer list first, but I'm optimistic about them going in before RC1.

Philipp
 

Offline spth

  • Regular Contributor
  • *
  • Posts: 163
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #562 on: April 05, 2019, 08:07:33 pm »
Just a quick update on the state of Padauk support in the Small Device C Compiler:

pdk13: In development. Still in an early stage, but simple programs should mostly work. Currently to be found in the pdk branch only, won't make it into the 3.9.0 release in April.
pdk14: Stable (i.e. regression tests pass). Will be in SDCC 3.9.0.
pdk15: In development, but improving rapidly (>90% of regression tests pass). Will be in SDCC 3.9.0.
pdk16: Work has not yet begun (except for some preliminary evaluations).

We have a working simulator of the PMS132B and PMS134 (cores only so far, no peripherals) that is used for the regression testing.

The pdk branch (necesary for those that wnat to have a look at pdk13 support) can be found at
https://sourceforge.net/p/sdcc/code/HEAD/tree/branches/pdk/
It also has some new features for pdk14 and pdk15 that are not yet in SDCC trunk.

For SDCC trunk, snapshots (including binaries) can be found at:
http://sdcc.sourceforge.net/snap.php

For those that want to use an IDE, I'd recommend Code::Blocks, since it has some SDCC support out-of-the-box.

Philipp

P.S.:

Plan for 2019:
* SDCC 3.9.0 release in April.
* Support PMC153 core in simulator
* Make the pdk15 backend stable
* Make the pdk13 backend work well for simple programs
* Support timers and interrupts in simulator
* Various small improvements to the generated code (in code generation, register allocation, peephole optimization)
* Another SDCC release near the end of the year.

Long-term plan:
* Various optimizations (in particular to reduce RAM usage and code size)
* Make the pdk13 backend stable
* Support pdk16 (assembler, linker, simulator, compiler)
 
The following users thanked this post: electronic_eel, js_12345678_55AA, notanick, piotr_go

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #563 on: April 06, 2019, 09:04:33 pm »
Hi,

finally... I found the time to prepare the first release of the Easy PDK programmer software:

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

The firmware for the programmer is included as compiled BIN file right now. I just need a bit more time to clean it up and make it usable with a complete FOSS tool chain.
UPDATE: The firmware is included as compiled BIN file and with full source code.

Have fun,

JS


Update: I created a compiled executable for Windows user and attached it to the release: https://github.com/free-pdk/easy-pdk-programmer-software/releases/tag/1.0 
« Last Edit: April 08, 2019, 11:38:40 am by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 
The following users thanked this post: electronic_eel, LA7SJA, gir, icraftcrafts, notanick, hidden

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1896
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #564 on: April 07, 2019, 05:38:10 am »
Thanks JS :-+ :-+ :-+
ASiDesigner, Stands for Application specific intelligent devices
I'm a Digital Expert from 8-bits to 64-bits
 

Offline spth

  • Regular Contributor
  • *
  • Posts: 163
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #565 on: April 08, 2019, 08:36:28 pm »
Dear SDCC users,

Today the first Release Candidate (RC1) for SDCC 3.9.0 has been created.
As always it has been put online in our SourceForge File section.
https://sourceforge.net/projects/sdcc/files/

If you have the time, please verify it and report back with the positive
or negative results.

There have been various improvements, both features and bug fixes
since SDCC 3.8.0. The full ChangeLog is at
https://sourceforge.net/p/sdcc/code/HEAD/tree/tags/sdcc-3.9.0-pre1/sdcc/ChangeLog.

The following is a list of particularly noticeable new features.

* Support for struct / union assignment.
* Optimizations in the stm8 backend relevant to soft float increase Whetstone score by two thirds.
* Improvements in rematerialization in the stm8 backend improve code generation for struct, union and arrays.
* New stack allocator reduces stack space usage for the stm8, z80, z180, gbz80, r2k, r3ka, tlcs90 backends.
* New ez80_z80 backend for eZ80 in Z80 mode.
* Removed deprecated sdcclib utility.
* New pdk14 backend for Padauk µC with 14-bit wide program memory.
* New in-development pdk15 backend for Padauk µC with 15-bit wide program memory.

Philipp Klaus Krause
SDCC 3.9.0 Release Manager

P.S.: There currently is a survey on use of various SDCC backends:

https://terminplaner4.dfn.de/xudoK5vzYi3oIX6O

If you would like to see support in SDCC for a device not yet supported or if you use the mcs51 backend for a device that has support for dual dptr, please state so (and which device it is) in a comment.
« Last Edit: April 09, 2019, 05:51:26 am by spth »
 
The following users thanked this post: notanick, piotr_go

Offline spth

  • Regular Contributor
  • *
  • Posts: 163
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #566 on: April 16, 2019, 06:52:42 am »
SDCC 3.9.0 has been released yesterday; I also submitted the news to Slashdot (https://slashdot.org/submission/9526188/small-device-c-compiler-390-released).

Current state of Padauk support:
* pdk14 is stable (included in release)
* pdk15 will soon be stable (included in release, very few remaining regression failures)
* pdk13 is experimental (currently in pdk branch only, but will probably be merged to trunk soon)

pdk13 probably won't be considered stable anytime soon (it would need to pass regression tests, but we'd need better optimizations to reduce memory usage first, as currently, the test framework won't fit into the limited memory of 1 KW / 64 B).
pdk16 support is still far away (there are still open questions about how to properly support this multicore architecture in SDCC).

Philipp
 
The following users thanked this post: notanick

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #567 on: April 17, 2019, 01:57:13 pm »
Hi,

I compiled list of IC types which can be physically piugged in Easy PDK Programmer directly by just using a SOP socket:

PMS15A-S08

PMC131-S16A
PMS131-S16A
PMC131-S14
PMS131-S14

PMS132-S16A
PMS132B-S16A
PMS132-S14
PMS132B-S14

PMS133-S16A
PMS134-S16A
PMS133-S16B
PMS134-S16B
PMS133-S14
PMS134-S14

PMC150-S08
PMS150-S08

PMS150C-S08 (supported)

PMS152-S16
PMS152-S14
PMS152-M10
PMS152-S08

PMC153-S14
PMS153-S14
PMC153-S08
PMS153-S08

PMS154B-S16 (supported)
PMS154B-S14 (supported)
PMS154B-M10 (supported)
PMS154B-S08 (supported)

PMS154C-S16 (supported)
PMS154C-S14 (supported)
PMS154C-M10 (supported)
PMS154C-S08 (supported)

PFS154-S16 (supported)
PFS154-S14 (supported)
PFS154-M10 (supported)
PFS154-S08 (supported)

PMS171B-S16
PMS171B-S14
PMS171B-M10
PMS171B-S08

PFS173-S16 (supported)
PFS173-S14 (supported)
PFS173-M10 (supported)
PFS173-S08 (supported)

PMC251-S14


All other types / variants will need the use of jumper wires between Easy PDK programmer and socket or an explicit adapter pcb.

Which types from the list above do you think are most interesting to support or what other types + adapter you would consider useful?

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

Offline electronic_eel

  • Regular Contributor
  • *
  • Posts: 201
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #568 on: April 17, 2019, 07:41:04 pm »
I already created adapter pcbs for PMS150C-U06 and PFS154-U06 as I'm mostly interested in the SOT23-6 packages. I took the gerbers of your programmer pcb and added my adapters to it with a gerber panelizer. I planned to publish the Kicad sources & Gerbers on github when I received the pcbs and had a chance to test them. But I haven't received them yet, they are still in transit.

I attached a picture of the pcb panel.

It is intended to work like this:
The pins of my SOT23-6 adapters have the same pitch as the programmer pcb. So one adapter pcb is not enough as the pins would interfere.
So you solder pin headers to the lower adapter pcb (the one with just one white break-line) and put them into the programmer.
You solder pin headers to the outer rows of it and then one of the top adapter pcbs on top.

I created one for PMS150C-U06 and one for PFS154-U06. The one with the three white break-lines is intended as universal or manual adapter pcb. The white lines indicate breaks in the connections. So you can cross the outer two white lines with your own small jumper wires or similar to create the wanted connections.

If someone wants the files untested, I could also publish them now.
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1896
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #569 on: April 18, 2019, 05:29:37 am »
Thanks JS, I think the ones that have ADC is the first obvious choices, tough you have already PFS173 in the list, but I would go for 12 bit ADC versions too.
ASiDesigner, Stands for Application specific intelligent devices
I'm a Digital Expert from 8-bits to 64-bits
 

Offline spth

  • Regular Contributor
  • *
  • Posts: 163
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #570 on: April 19, 2019, 05:59:39 am »

Which types from the list above do you think are most interesting to support or what other types + adapter you would consider useful?

JS

From an SDCC perspective, I'd currently consider the following the most interesting:

* PMS15A - since it is the very low-end device (and we now have a pdk13 backend supporting it - in current trunk and snapshots, but not the 3.9.0 release)

* PMS153 - this is the pdk13 type we have an emulator for, which was used for the (very little) testing done on the pdk13 backend.
* PMS132B - this is the pdk14 type we have an emulator for, which is also used for testing the pdk14 backend.
* PMS134 - this is the pdk15 type we have an emulator for, which is also used for testing the pdk15 backend.

* PFS172 - this will be the second flash pdk14 type; it is to be released this quarter.
* PFS232 - this will be the first dual-core flash device.

Currently, the emulators only emulator the core, but AFAIK, Nicolas is working on adding timer / interrupt support.
 

Offline gir

  • Contributor
  • Posts: 16
  • Country: at
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #571 on: April 19, 2019, 02:52:07 pm »
I"m personally interested in the PMS-150C-U06 and PMS-15A-U06.

Thanks to all of you -- wonderful feat of reverse engineering you all accomplished there!
 
The following users thanked this post: icraftcrafts

Offline cnlohr

  • Newbie
  • Posts: 4
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #572 on: April 30, 2019, 04:18:07 pm »
Oh man, this is amazing.  I was worried I was going to have to do a bunch of RE, but looks like you guys got it all figured out!  I am probably going to start getting involved with the PFS173 since I think it might be possible to run ColorChord on it.  Also, I may port some of your guys flashing code to the ESP8266 for drag-n-drop browser flashing.

Mostly just wanted to stop in and say this is amazing work on everyone's part. I can't wait for Padauk to take the uC world by storm since it looks like Microchip has been less and less proactive. (I was expecting the ATTiny202's etc... to come in smaller packages.  SOICs are just TOO BIG.)
 

Offline cnlohr

  • Newbie
  • Posts: 4
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #573 on: May 08, 2019, 12:38:42 am »
First of all AMAZING WORK EVERYONE WOW

1) I cannot use GPL-code in this application if I do a port to the '8266, since portions of it will need to be open and other portions not, so I am going to need to re-work things :(.  Would you guys consider using MIT/X11 or NewBSD licenses?
2) Any idea how sensitive the voltages are, for instance what the optimal values are for VPP and VDD at different stages?  Do we ever /need/ to set VPP higher than 8.3V?
3) Why didn't you guys go STM32F042 I didn't see anyone mentioning it?  The crystal-less operation makes things really convenient and cheap.  Also, I have a hid mode ser up for it if you were interested, so you wouldn't need any special udev rules and Windows operation would be trivial :). I'm still shooting for an ESP8266 version, but, would you be interested in a stm32f042 port if I feel the urge?
4) Is there a re-host for the fpdk_ic_table stuff.
5) Going forward, is sdcc-pdk going to continue to be maintained within github directly?  I'm honestly having a hard time getting it to work in emscripten but I'll keep poking at it.
6) I would be interested in directly contributing to the free-pdk group and just cleaning things up documentation wise as I see it.

I'm still shooting for ColorChord on my PFS173, but, the no-multiply-unit thing is really killing me.

 

Offline electronic_eel

  • Regular Contributor
  • *
  • Posts: 201
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #574 on: May 08, 2019, 07:35:57 am »
do a port to the '8266
I wonder what the usecase for that is? For example for me it would be much more work to integrate the esp into my network than just to plug in a usb cable.

2) Any idea how sensitive the voltages are, for instance what the optimal values are for VPP and VDD at different stages?  Do we ever /need/ to set VPP higher than 8.3V?
VPP must go to 10.8. There are some reports of problems when not getting the voltages right in this thread.

3) Why didn't you guys go STM32F042 I didn't see anyone mentioning it?  The crystal-less operation makes things really convenient and cheap.
The ´72 is very similar, also does crystal-less. But the ´42 is not as common and more expensive.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf