EEVblog #1144 - Padauk Programmer Reverse Engineering

[homeworkboy]

Thank JS.
Attached file, it 's Padaud calibration procoess Waveform.

where find it's asm at easy-pdk-programmer-software?

Hong

[LovelyA72]

One more update regarding Padauk's IDE.
If you don't allow Padauk IDE to access the internet or use an old version after a specific date, the IDE will throw all sorts of artificial(fake) errors to prevent you from using it.

That's not really nice I'll say...

Also, Kent should really review his English in Padauk's IDE...

[vitohong]

I use  ide 0.89 vs 0.91 .
0.84 didn't  internet.
0.91 have to use internet.
Then I want to know free PDK how to calibrate ihrc

[LovelyA72]

Then I want to know free PDK how to calibrate ihrc

I think these are all you'll need. Not as simple as ".ADJUST_IC SYSCLK=IHRC/2;" but you get more control over the calibration process.
If you check sysclock.h and auto_sysclock.h you'll get more information.

Code: [Select]

unsigned char _sdcc_external_startup(void)
{
    // example, edit to suit
    AUTO_INIT_SYSCLOCK();
    AUTO_CALIBRATE_SYSCLOCK(TARGET_VDD_MV);
    return 0;                                 //perform normal initialization
}

[homeworkboy]

thanks,
I find "fpdkiccalib.c"

  { .sopc=0x1442, .smsk=0xFFFF, .copc=0x1709, .cocf=CO_AC_NOP},                                //search: AND A, 'B'            /   calib: MOV A, 0x09                /   after-calib: NOP
    { .sopc=0x1447, .smsk=0xFFFF, .copc=0x0091, .cocf=CO_AC_NOP},                                //search: AND A, 'G'            /   calib: MOV IO(0x11), A  (PAC)     /   after-calib: NOP
    { .sopc=0x1400, .smsk=0xFF00, .copc=0x0F8D, .cocf=CO_AC_NOP|CO_VAL_CAL_TYP},                 //search: AND A, *   (CAL_TYP)  /   calib: SET1 IO(0x0D).4  (PADIER.4)/   after-calib: NOP
    { .sopc=0x1400, .smsk=0xFF00, .copc=0x1784, .cocf=CO_AC_NOP|CO_VAL_MVOL_00},                 //search: AND A, *   (MVOL_00)  /   calib: MOV A, 0x84                /   after-calib: NOP
    { .sopc=0x1400, .smsk=0xFF00, .copc=0x0080, .cocf=CO_BC_SETREG1|CO_AC_NOP|CO_VAL_MVOL_08},   //search: AND A, *   (MVOL_08)  /   calib: MOV IO(0x00), A  (SETREG1) /   after-calib: NOP
    { .sopc=0x1400, .smsk=0xFF00, .copc=0x17A3, .cocf=CO_AC_NOP|CO_VAL_CAL_REG0},                //search: AND A, *   (CALREG0)  /   calib: MOV A, 0xA3                /   after-calib: NOP
    { .sopc=0x1400, .smsk=0xFF00, .copc=0x0080, .cocf=CO_BC_SETREG2|CO_AC_NOP|CO_VAL_CAL_REG1},  //search: AND A, *   (CALREG1)  /   calib: MOV IO(0x1E), A  (SETREG2) /   after-calib: NOP
    { .sopc=0x1400, .smsk=0xFF00, .copc=0x17FF, .cocf=CO_AC_SETIMM|CO_VAL_CAL_REG2},             //search: AND A, *   (CALREG2)  /   calib: MOV A, 0xFF                /   after-calib: MOV A, <val>
    { .sopc=0x1400, .smsk=0xFFFF, .copc=0x0F70, .cocf=CO_AC_NOP},                                //search: AND A, 0              /   calib: SET1 IO(0x10).3  (PA.3)    /   after-calib: NOP
    { .sopc=0x1400, .smsk=0xFFFF, .copc=0x0080, .cocf=CO_BC_SETREG0},                            //search: AND A, 0              /   calib: MOV IO(0x00), A  (SETREG0) /   after-calib: stay
    { .sopc=0x1400, .smsk=0xFFFF, .copc=0x0C90, .cocf=CO_AC_NOP},                                //search: AND A, 0              /   calib: T0SN IO(0x10).4  (PA.4)    /   after-calib: NOP
    { .sopc=0x1400, .smsk=0xFFFF, .copc=0x1001, .cocf=CO_AC_NOP},                                //search: AND A, 0              /   calib: ADD A, 0x01                /   after-calib: NOP
    { .sopc=0x1400, .smsk=0xFFFF, .copc=0x0E70, .cocf=CO_AC_NOP},                                //search: AND A, 0              /   calib: SET0 IO(0x10).3  (PA.3)    /   after-calib: NOP
    { .sopc=0x1400, .smsk=0xFFFF, .copc=0x1808, .cocf=CO_BC_FIXUP|CO_AC_NOP},                    //search: AND A, 0              /   calib: GOTO 0x008       <FIXUP>   /   after-calib: NOP


Yes, It 's magic code than Padauk. 

Hong

[gir]

Calibration worked perfectly, thanks for the explanation.

Next, and hopefully last 2 issues: my Timer16 interrupt is triggered twice in a row, and sometimes is offset. I attached a screenshot; the blue channel goes high whenever the IVR is active. And there are always two peaks next to each other. Also, it looks like it is "jittering" a lot: the interrupt is triggered early/late by the exact duration of a double-trigger (the double-double-peak on the left is "persistent phosphor" from two runs in a row...if that makes sense).

I am wondering what those two issues could be caused by and how to prevent them. The datasheet mentions that the T16 interrupt happens whenever the bit _changes_, but that should also be at regular intervals, not directly after the IVR was exited.


PS:

  and a, #( 4194304 )      ;4MHz = 4194304Hz

AFAIK, MHz is defined as 10^6, not as 2^20. so 4MHz should be 4000000Hz.

[homeworkboy]

Hi gir:
I run your test file.
It's fine

Hong

[js_12345678_55AA]

Calibration worked perfectly, thanks for the explanation.

  and a, #( 4194304 )      ;4MHz = 4194304Hz

AFAIK, MHz is defined as 10^6, not as 2^20. so 4MHz should be 4000000Hz.

I know that... I gave this example since you asked for fractional MHz frequency value like 4.096MHz. I just forgot to update the comment ;-)

Next, and hopefully last 2 issues: my Timer16 interrupt is triggered twice in a row, and sometimes is offset. I attached a screenshot; the blue channel goes high whenever the IVR is active. And there are always two peaks next to each other. Also, it looks like it is "jittering" a lot: the interrupt is triggered early/late by the exact duration of a double-trigger (the double-double-peak on the left is "persistent phosphor" from two runs in a row...if that makes sense).

I am wondering what those two issues could be caused by and how to prevent them. The datasheet mentions that the T16 interrupt happens whenever the bit _changes_, but that should also be at regular intervals, not directly after the IVR was exited.

I observed a similiar behaviour some time ago and it all came down to the "stopexe" instruction.

I never had the time to fully investigate on this. I never got rid of the jitter.
My solution back then was to set SYSCLK to ILRC and not using stopexe at all.

I guess another interrupt might be triggered when the IC wakes up again. Maybe your "lazy" interrupt which does not check for the interrupt source causes the double execution.


JS

PS: Since stopexe makes use of ILRC (32 ILRC clocks when using faste wakeup) you should tune IHRC and ILRC (have a look in calib-and-fuse-demo.c inside of the examples folder from easypdk programmer). In general, if you want to tune ILRC you have to setup CLKMD for ILRC and add another tuning sequence (this time type=2). So if you want to tune ILRC and IHRC then you set ILRC as sysclk, add ILRC tuning sequence then directly afterwards set IHRC as sysclk and add IHRC tuning sequence.

Edit2: Just found in the manual:
http://www.padauk.com.tw/upload/doc/PMS15A,PMS150C%20datasheet%20V108_EN_20200724.pdf
chapter 9.2.2 Interrupt:
(1)  When using the interrupt function, the procedure should be:
Step1: Set INTEN register, enable the interrupt control bit
Step2: Clear INTRQ register
Step3: In the main program, using ENGINT to enable CPU interrupt function
Step4: Wait for interrupt. When interrupt occurs, enter to Interrupt Service Routine
Step5: After the Interrupt Service Routine being executed, return to the main program
(2)  INTEN and INTRQ have no initial values. Please set required value before enabling interrupt function.

Edit: @homeworkboy / vitohong

Hi gir:
I run your test file.
It's fine
Hong

The problem is related to PMS150C. Do you say you can run it on PMS150C with stopexe and without jitter? Maybe your resolution of the logic analyzer is not high enough.

[js_12345678_55AA]

thanks,
I find "fpdkiccalib.c"
...
Yes, It 's magic code than Padauk. 

Thanks. But you can not compare full source code with comments ("fpdkiccalib.c") to NO-CODE-AT-ALL (Padauk).

The code in fpdkiccalib.c is not very difficult to understand you just need to spend some minutes in the file. In case you have specific questions feel free to ask.
Unlike some other "magicians" I will fully reveal what other would call "magic". 

JS

[gir]

Just a status update: I'm still working on my interrupt routine. removing stopexe from the main loop made the ISR trigger constantly (reducing the delay loop variable increases the interrupt frequency), so there's definitely something wrong with my understanding of how the ISR triggers. I tried to add the following check whether the right interrupt was triggered, but that prevented the routine from running at all.

        t1sn    intrq, #(1<<2)  ; if intrq.t16 is triggered, skip next
        reti  ; or alternatively, 'goto isr_end'

Using the ISR below, I checked which bits are set in intrq (it's 68 pulses, so bit 6 (timer2) and bit 4 (timer16)):

interrupt:
        push    af
        mov a, intrq
isr_number_loop:
        set1 pa, #6
        nop
        nop
        nop
        nop
        nop
        nop
        set0 pa, #6
        nop
        nop
        nop
        nop
        nop
        nop
        dzsn a
        goto isr_number_loop

        mov a, #0x3f
delayloop:
        dzsn a
        goto delayloop

isr_end:
        mov a, #0       ; clear all interrupts
        mov intrq, a    ; clear all interrupts
        pop     af
        reti


I don't expect you to fix that for me, js, just writing down my thoughts here.

Bonus link: a small software startup from Redmond has started using the pms150c: https://github.com/microsoft/jacdac-padauk (uses the proprietary IDE, though :/ )

[js_12345678_55AA]

Hi,

The IRQ logic is outlined in detail in the data sheet.

TM2 sets INTRQ regardless of enabling or disabling TM2 interrupt.

However the interrupt is only triggered when INTEN is enabled for TM2.


I try to explain it in short:

All the specific "peripherals" (TM16, TM2, ...) will do their stuff and set their INTRQ.

Then there is an AND logic with INTEN  and in case INTRQ.TM2 AND INTEN.TM2 is both 1 then interrupt will be triggered.

When you leave the interrupt and it happens that  INTRQ.TM2 AND INTEN.TM2 are still both 1 then the interrupt is triggered immediately again (the normal program will get no chance to execute anything).

In case you spend to much time in interrupt this also could cause the next INTRQ to be set already which could lead to constant interrupt triggering (when you clear INTRQ at begin of IRQ) or missed interrupt (when you clear INTRQ at end of interrupt).


So let's check the effective frequency and timing of your TM16:

   ;timer16 setup
   mov   a, #(( 0<<0 | 1<<3 | 4<<5 ))   ; ovf@bit8, clk/4, ihrc
   mov   t16m, a

* IHRC/4 = 4 MHz   =>  4 MHz / 512 = 7812 Hz
* SYSCLK = 4 MHz

=> The interrupt has max 512 cycles to execute.

Calculation of cycles consumed from your interrupt:
- int vector @0x10 contains a jump (2 cycles) to your interrupt code
- pushaf (2 cycles)
- mov a, intrq (1 cycle)

LOOP (in your case executed 68 times)
- set1,nop,nop,...,set0,nop,nop (14 cycles)
- dzsn (1 cycle)
- goto (2 cycles)

- mov (1 cycle)
- mov (1 cycle)
- popaf (1 cycle)
- reti (2 cycles)

= 2+2+1+68*(14+1+2)+1+1+1+2 = 1166 cycles   <== this is way more than the 512 cycles you have, means that 2  TM16 interrupts been missed already

This might be the reason that you observe the strange looking interrupt behavior.

JS

EDIT: In case you share a bit more of your final requirement then there might be even better / easier ways to achieve this. For the purpose shown in your example you just could use TM2 alone, generating an IRQ whenever one PWM cycle is over, in IRQ count a variable up to 4 and then change the PWM output value.

[KaeTo]

Hello,

I build the pdk programmer a few times, but 2 of the programmer do not work. I can interface the STMs but cant programm or probe the padauk uCs. I run the easypdkprogtest from github and got as an result
vdd: 13.65   vpp: 13.55    (vref= 3.29)

Thanks JS, I managed to flash the Dev branch to the ARM and now it's working, But still only probing is working any Idea what might goes wrong?

Now you have to check your hardware variant. On the picture I saw that C1 is not populated and also Y1 is missing. A cap on the 15V rail is essential since VCC/VDD draw some power during programing. The crystal is used to get better tuning results after the CPU is flashed, without it the drift might be much higher or you create a very special clock path using the HSI48 with sync to USB frames (then programmer can not be used stand alone - a feature planned for future use, just like WRITER).

Also, since you changed the opamp, it might be possible that the output voltages differ. You can use the "easypdkprogtest" program to check that the output voltage is correct:

DO THIS WITHOUT A MCU CONNECTED TO THE PROGRAMMER

make easypdkprogtest

./easypdkprogtest
vdd: 5.01   vpp: 4.98    (vref= 3.30)

Please check that VDD and VPP are 5V and VREF is 3.3V. Also measure them on your PCB.

In case VDD and VPP voltages are incorrect you need to tune the DAC reference values for your specific hardware (in fpdk.c you need to change FPDK_VDD_DAC_MAX_MV / FPDK_VPP_DAC_MAX_MV).


JS

I found this post here so I assume that something is wrong with my programmer. What can I do or check next? (As Tools I have an lab bench power supply, an oscilloscop and a multimeter)

[js_12345678_55AA]

Hello,

I build the pdk programmer a few times, but 2 of the programmer do not work. I can interface the STMs but cant programm or probe the padauk uCs. I run the easypdkprogtest from github and got as an result
vdd: 13.65   vpp: 13.55    (vref= 3.29)

Thanks JS, I managed to flash the Dev branch to the ARM and now it's working, But still only probing is working any Idea what might goes wrong?

Now you have to check your hardware variant. On the picture I saw that C1 is not populated and also Y1 is missing. A cap on the 15V rail is essential since VCC/VDD draw some power during programing. The crystal is used to get better tuning results after the CPU is flashed, without it the drift might be much higher or you create a very special clock path using the HSI48 with sync to USB frames (then programmer can not be used stand alone - a feature planned for future use, just like WRITER).

Also, since you changed the opamp, it might be possible that the output voltages differ. You can use the "easypdkprogtest" program to check that the output voltage is correct:

DO THIS WITHOUT A MCU CONNECTED TO THE PROGRAMMER

make easypdkprogtest

./easypdkprogtest
vdd: 5.01   vpp: 4.98    (vref= 3.30)

Please check that VDD and VPP are 5V and VREF is 3.3V. Also measure them on your PCB.

In case VDD and VPP voltages are incorrect you need to tune the DAC reference values for your specific hardware (in fpdk.c you need to change FPDK_VDD_DAC_MAX_MV / FPDK_VPP_DAC_MAX_MV).


JS

I found this post here so I assume that something is wrong with my programmer. What can I do or check next? (As Tools I have an lab bench power supply, an oscilloscop and a multimeter)

Your VDD is much to high (Should be 5V). Check the resistor R6, most likely you used the wrong value there.

JS

[KaeTo]

I already checked R6. It has the correct value and is also solderd correctly.

[js_12345678_55AA]

I already checked R6. It has the correct value and is also solderd correctly.

In this case most likely the opamp U3 is damaged.

While running easypdkprogtest measure with your multimeter in DC voltage mode (one lead connected to GND):

U3:

pin8: 14.9V
pin4: -2.6V

pin3: 2.5V
pin2: 2.5V
pin1: 5V

pin5: 1.18V
pin6: 1.18V
pin7: 5V


What are your values?

JS

[KaeTo]

I already checked R6. It has the correct value and is also solderd correctly.

In this case most likely the opamp U3 is damaged.

While running easypdkprogtest measure with your multimeter in DC voltage mode (one lead connected to GND):

U3:

pin8: 14.9V
pin4: -2.6V

pin3: 2.5V
pin2: 2.5V
pin1: 5V

pin5: 1.18V
pin6: 1.18V
pin7: 5V


What are your values?

JS

My values are:

U3:

pin8: 15.0V
pin4: 4.5V

pin3: 3.8V
pin2: 6.2V
pin1: 13.7V

pin5: 3.8V
pin6: 3.82V
pin7: 13.6V

[js_12345678_55AA]

I already checked R6. It has the correct value and is also solderd correctly.

In this case most likely the opamp U3 is damaged.

While running easypdkprogtest measure with your multimeter in DC voltage mode (one lead connected to GND):

U3:

pin8: 14.9V
pin4: -2.6V

pin3: 2.5V
pin2: 2.5V
pin1: 5V

pin5: 1.18V
pin6: 1.18V
pin7: 5V


What are your values?

JS

My values are:

U3:

pin8: 15.0V
pin4: 4.5V

pin3: 3.8V
pin2: 6.2V
pin1: 13.7V

pin5: 3.8V
pin6: 3.82V
pin7: 13.6V

pin4: 4.5V <=== this should be a negative voltage !

==> check C14 / D2 / D3 / C3   - most likely the diodes are not soldered properly or in wrong orientation.

JS

[KaeTo]

pin4: 4.5V <=== this should be a negative voltage !

==> check C14 / D2 / D3 / C3   - most likely the diodes are not soldered properly or in wrong orientation.

JS

Than kyou verry, very much. I found the problem only with your help. On one PCB I placed one diode in the wrong direction and on the other PCB there was a bad solder joint with the diode. Now both PCB are working fine

[homeworkboy]

Hi:
I compile pdk13 asm at PMS150

flow:
sdaspdk13 -losx sram.asm
sdldpdk  -i -m -x -u  sram
packihx sram.ihx > sram.hex

at sram.lst

      00004E 50 1C                   73   call push0
      000050 2A 18                   74    goto loop
It's correct.

but ihex
call  push0 -> call 0x28
goto loop   -> call 0x30

"sdlpdk -i -m -x -u sram"
Is the parameter setting wrong?

[js_12345678_55AA]

Hi:
I compile pdk13 asm at PMS150

flow:
sdaspdk13 -losx sram.asm
sdldpdk  -i -m -x -u  sram
packihx sram.ihx > sram.hex

at sram.lst

      00004E 50 1C                   73   call push0
      000050 2A 18                   74    goto loop
It's correct.

but ihex
call  push0 -> call 0x28
goto loop   -> call 0x30

"sdlpdk -i -m -x -u sram"
Is the parameter setting wrong?

Looks like you get confused by the SDCC assembler .LST format. SDCC uses/shows byte positions as addresses. When you disassemble the .IHX file with dispdk it shows the real code word positions like they are encoded in PDK opcodes.

1 PDK codeword (13-16 bit) = 2 bytes (2x 8 bit)

This means

SDCC .LST file : "00004E 50 1C                   73   call push0"

==> 0x50 / 2 = 0x28

REAL OPCODE / Disassembly: "call 0x28"

So everything is good.

JS


EDIT: I just spotted that your ".org 0x050" overwrites the already placed opcode for "goto loop" at 0x050 and your interrupt at 0x052. Maybe that's why your program is not working and you suspect the assembler for doing wrong things.

Please keep in mind SDCC .org directive is also BYTE based which means you have to multiply your real opcode positions by 2. In fact org 0x001, 0x003, 0x005, ... are INAVLID and can not be used at all.

[homeworkboy]

Hi JS:
I got it , thank you.

Hong

[js_12345678_55AA]

Some interesting development.

I added support for PMS150G (in development branch).

Looks like PMS150G / PMS15B has now an additional security feature: "instruction word scrambling".
This scrambling will shuffle the bits of an instruction word around (like a substitution cipher).

First I thought somebody made a mistake and wired the codemem data bus incorrectly and this is what is needed to fix the issue.
But later I found that only 32 instructions are scrambled, followed by 32 clear instructions, followed by 32 scrambled instructions, followed by 32 clear instructions, ...
So this was done on purpose.
This 1/2 security perfectly matches the already established 7/8 security.   
Also the bit pattern for bits without shifting is 55AA  (PADAUK must be really in love with that number).

@PADAUK: Thanks for this hardware challenge, but you can increase difficulty a bit...

The scramble pattern for PMS150G is: "0123f5b78da6c9e4"

(The pattern uses the hex digit to specify the bit pos where to get it from. e.g. "01234567890ABCDEF" will produce the same output as the input; "FEDCBA9876543210" will reverse a 16 bit value)

The implementation of the scrambler / descrambler is part of easypdkprog (development branch). Any read or write operation will transparently handle scrambling / descrambling. It's like there is no scrambling ;-)

JS

[homeworkboy]

HI JS:
how to find ""0123f5b78da6c9e4".
It look random data.

[js_12345678_55AA]

HI JS:
how to find ""0123f5b78da6c9e4".
It look random data.

Just like you reverse any substitution cipher: https://en.wikipedia.org/wiki/Substitution_cipher
via a known plaintext attack: https://en.wikipedia.org/wiki/Known-plaintext_attack

1. you use WRITER to write a program which contains values with only one bit set: 0x0001 0x0002 0x0004 0x0008 ... 0x0800 0x1000
2. you read back the data using easypdkprog
3. you see the mapping of every bit:

scrambled(read via easypdkprog) => original (in PDK file)

*not part of 13 bit command*
0x8000 => 0x8000  (0b1000000000000000 => 0b1000000000000000) => "0"  (numeric value of bit position in original)
0x4000 => 0x4000  (0b0100000000000000 => 0b0100000000000000) => "1"
0x2000 => 0x2000  (0b0010000000000000 => 0b0010000000000000) => "2"
*13 bit command*
0x1000 => 0x1000  (0b0001000000000000 => 0b0001000000000000) => "3"
0x0800 => 0x0001  (0b0000100000000000 => 0b0000000000000001) => "f"
0x0400 => 0x0020  (0b0000010000000000 => 0b0000000000100000) => "5"
...
0x0002 => 0x0002  (0b0000000000000010 => 0b0000000000000010) => "e"
0x0001 => 0x0800  (0b0000000000000001 => 0b0000100000000000) => "4"
 
==> "0123f5...e4"

It's like SUDOKU for advanced  .

JS

[homeworkboy]

HI JS:
I feel what Padauk is doing is a wild-goose chase